J’ai eu l’occasion de vous parler de nombreuses sorties de produits au cours de différents articles du magazine Exchange, mais c’est la première fois que cette présentation nécessite de couper l’article en trois parties.
Nous arrivons donc à la fin de la description des nouvelles fonctionnalités d’Exchange 2010.
La gestion d’une messagerie est propre à chaque entreprise. Certaines souhaitent donner la pleine maîtrise de l’ensemble à un nombre restreint d’administrateurs, que cette messagerie soit centralisée ou non. D’autres souhaitent déléguer l’administration des serveurs délocalisés à des personnes travaillant sur ces sites. D’autres enfin, préfèrent partager les rôles entre différents niveaux d’administrateurs comme la gestion de la configuration à une équipe centrale et la gestion des boîtes aux lettres aux correspondants locaux.
Pour cela, les précédentes versions d’Exchange disposaient de différents rôles qui pouvaient être délégués à des utilisateurs ou groupes. Cependant, du fait de l’impossibilité de modifier les propriétés de ces rôles, il était parfois difficile de créer sous Exchange, un modèle d’administration pouvant répondre aux demandes des entreprises.
Exchange 2010 essaye de répondre à cette demande au travers d’RBAC.
Si l’on souhaite résumer RBAC en trois mots, ce serait, dans un environnement Exchange 2010 : Qui, Quoi, Où ?
Qui ? La réponse à cette question est la liste des utilisateurs ou administrateurs qui ont le droit d’effectuer des actions sur les objets Exchange ou Active Directory.
Quoi ? Auparavant, l’assignation des droits d’administration se faisait par ACL sur les objets Active Directory. Il faut dont, lorsque l’on donne des droits à un utilisateur ou groupe, placer des ACL sur l’ensemble des objets qu’ils peuvent gérer. Pour chaque objet, il faut préciser l’action qui peut être effectuée. Ceci peut devenir rapidement fastidieux en fonction de la complexité du modèle d’administration que vous souhaitez mettre en œuvre.
Le principe de RBAC est de regrouper les commandes PowerShell disponibles sous forme de rôles. Etant donné que plus de 600 commandes PowerShell sont mises à disposition par Exchange 2010, un certain nombre de rôles est disponible suite à l’installation du produit. Plus de 60 rôles appelés « Management Role » sont pré-créés qui sont eux mêmes regroupés en « Role Group ». Il existe par défaut, dix « Role Group » :
• Organization Management : permet de gérer l’ensemble de l’organisation Exchange 2010,
• View-Only Organization Management : ce « Role Group » permet de visualiser les propriétés de n’importe quel objet de l’organisation,
• Recipent Management : permet de gérer les utilisateurs de la messagerie,
• UM Management : quand une personne hérite de ce « Role Group », elle aura le droit de gérer l’ensemble des objets liés au rôle UM. Il sera par exemple, possible de déléguer ce rôle aux personnes en charge de la téléphonie de l’entreprise,
• Discovery Management: Exchange 2010 permet à certains administrateurs, de pouvoir chercher des informations dans toutes les boîtes aux lettres, ceci pour des raisons d’audits légaux. Vous comprendrez aisément que ce rôle sensible n’est pas confié à n’importe qui,
• Server Management : permet de gérer les serveurs Exchange. Il ne permet pas de gérer les utilisateurs ou les objets généraux liés à l’organisation de messagerie,
• Help Desk : les personnes à qui ce rôle est affecté, peuvent modifier certains paramètres des utilisateurs de la messagerie,
• Public Folder Management : comme son nom l’indique, en héritant de ce rôle, il sera possible de gérer les dossiers publics,
• Delegated Setup : ce rôle permet de déployer des serveurs Exchange qui seront préalablement provisionnés par les Administrateurs Exchange. Ceci permet de déléguer l’installation des serveurs à une équipe technique dédiée. Si nous prenons par exemple le « Role Group » « UM Management », il est composé de trois « Management Role » :
• « UM Mailbox Role » qui donne le droit de gérer les paramètres liés à UM au niveau des boîtes aux lettres des utilisateurs,
• « UM Prompts Role » qui permet de gérer les annonces d’accueils de la partie UM d’Exchange 2010,
• « Unified Messaging Role » permet lui de gérer les serveurs UM d’Exchange 2010.
Vous pouvez donc assigner le « Role Group » « UM Management » à une personne qui sera en charge de l’ensemble de la gestion de la partie UM d’Exchange 2010. Mais si vous souhaitez qu’une personne ne puisse que gérer les paramètres UM liés aux boîtes aux lettres, au lieu de lui assigner ce « Role Group », vous pourrez lui assigner uniquement le « Management Role » « UM Mailobox Role ».
Au travers de cet exemple, vous pouvez imaginer toute la granularité et la finesse qu’offre Exchange 2010 au niveau de l’administration, sachant qu’il est possible d’aller jusqu’à autoriser un utilisateur à ne lancer qu’une seule commande PowerShell.
Afin d’éviter de devoir modifier les rôles mis à disposition par défaut, il est possible de créer des copies de ces rôles pour ensuite les modifier et les affecter aux administrateurs ou utilisateurs. C’est en tout cas, ce que je vous conseille de faire à chaque fois car si vous modifiez maladroitement un rôle existant, cela peut devenir difficile de revenir à l’état initial et du coup, vous vous retrouveriez avec un système qui pourrait ne plus rien à voir avec celui d’origine.
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.
