Où ?

un objet ou un groupe d’objets d’Active Directory comme l’organisation dans son ensemble, une OU ou un simple utilisateur.

En résumé, RBAC permet de tout déléguer sur n’importe quel objet, à n’importe qui. Pour illustrer cette flexibilité, voici un exemple qui pourrait être délégué à un utilisateur au moyen de RBAC:

• Henri peut modifier les quotas des boîtes aux lettres sur l’ensemble des boîtes de l’organisation,

• Henri peut gérer les règles de rétention de toute l’OU Europe,

• Henri a la pleine maîtrise des boîtes aux lettres de l’OU France,

• Henri est l’administrateur du serveur Exchange MBX dont le nom est MBXPARIS.

Bien entendu, pour que les utilisateurs disposant de droits sur des objets Exchange puissent exercer ces droits, ils doivent avoir accès à l’organisation. Sous Exchange 2007 et les versions antérieures, il fallait avoir un accès à un serveur, soit physiquement, soit au travers d’une session terminal server, ou encore au moyen d’une MMC, ce qui rendait parfois incompatible les droits nécessaires pour le moyen d’accès en comparaison des droits que l’on voulait déléguer pour la gestion des objets. Exchange 2010 utilise Remote PowerShell qui apparaît avec PowerShell V2. Le principe est de pouvoir lancer à partir d’un poste de travail, des commandes PowerShell sans pour autant les exécuter physiquement sur un serveur Exchange et sans avoir besoin d’installer sur le poste de travail, ni les cmdlet d’Exchange, ni la MMC d’Exchange 2010. Quand un utilisateur ouvre une session PowerShell sur son poste de travail (notez que PowerShell V2 est disponible par défaut sous Windows 7), il va uniquement récupérer au moyen de son authentification, les commandes PowerShell qu’il a le droit d’exécuter. Si nous reprenons l’exemple d’Henri, lorsqu’il ouvrira une session PowerShell sur son poste de travail, il pourra par exemple, exécuter les commandes « Set-Mailbox » et « Set-MailboxServer » puisqu’il peut gérer les boîtes aux lettres de l’OU France et le serveur de MBXPARIS. Mais il ne verra jamais, entre autre, la commande « Set-TransportServer » puisque cette commande permet de gérer les serveurs HUB Exchange 2010 ce qui n’est pas le cas du serveur MBXPARIS. Il ne verra pas non plus la commande « New-SharingPolicy » qui permet de gérer la politique de partage des calendriers au niveau global de l’organisation puisqu’Henri n’a aucun droit de changer les paramètres Exchange de l’organisation. Arrêtons ici la liste de l’ensemble des commandes interdites à Henri puisque je vous le rappelle, il y a plus de 600 cmdlets apportées par Exchange 2010.

J’espère que cette rapide explication de RBAC vous permet de cerner la puissance du concept d’administration offerte par Exchange 2010, car le sujet est complexe ce qui le rend difficile expliquer en quelques dizaines de lignes.

En conclusion de ce chapitre nous pouvons dire que RBAC est vraiment très puissant, mais c’est à manier avec précaution et surtout après en avoir bien compris le fonctionnement. Quand vous vous lancez dans la création d’un modèle d’administration basé sur vos propres rôles, je ne peux que vous conseiller de les valider sur un environnement de tests.

Conclusion

Ainsi s’achève cette troisième et dernière partie consacrée aux nouveautés d’Exchange 2010. Vous avez pu le constater, Exchange 2010 est vraiment une version importante dans la vie de ce logiciel. Elle apporte de réelles nouveautés fonctionnelles fortement demandées par les entreprises comme la possibilité de créer un site de secours tout en maîtrisant les coûts ou encore de sécuriser les échanges de messages avec RMS. Mais, présenter la sortie d’une nouvelle version d’Exchange sans évoquer les nouveaux clients serait un oubli impardonnable. C’est ce que nous ferons dans le prochain numéro où nous vous parlerons d’OWA 2010 et Outlook 2010.