Introduction
L’isolation des carnets d’adresses répond à une problématique de toutes entreprises soucieuses de mutualiser ses investissements et mettre en place des séparations fonctionnelles entre ses différentes entités voir entre différentes filiales.
Le but du jeu est donc de paramétrer vos infrastructures Exchange pour faire en sorte que chaque entité dispose d’une visibilité limitée à son carnet d’adresse. De la sorte, une seule organisation Exchange sera a prévoir ainsi qu’une seule foret Active Directory. Cet environnement s’approchant des problématiques hébergeur est également traitée dans la solution HMC de Microsoft.
Dans cet article nous allons passer en revue les principes de bases et les opérations que vous aurez à réaliser pour mettre en place une telle infrastructure.
Supporté ou non supporté ?
Les fonctionnalités d’isolation de carnets d’adresse sont dans la version 2007 d’Exchange supporté par Microsoft. Cependant certains paramétrages ne le sont pas. La solution supportée est une isolation intégrale des entités hébergées, plus techniquement c’est la non utilisation de la liste d’adresse par défaut et ce pour tout le monde. La solution non supportée serait par exemple la mise en place au sein d’une même forêt Active Directory et d’une seule organisation de deux entités disposant de leurs carnets d’adresses propres avec pour une entité, la possibilité de visualiser la liste d’adresse par défaut (GAL).
Planification de votre environnement Active Directory
A des fins de simplicité, nous vous recommandons de mettre en place une forêt munie d’un seul domaine pour réaliser ces opérations. La simple utilisation des unités organisationnelles suffira à isoler vos adresses Exchange. Le principal intérêt également de cette solution mono domaine est l’utilisation de ressources matérielles limitées. Bien sur la solution multi domaines qui consiste à mettre en place un domaine par entités est possible mais va générer des coûts de matériels qui pourront sembler pour certain, contraire à l’idée de mutualisation des ressources. Pire, vous pouvez prévoir une forêt pour chaque entité mais la .. nous nous égarons…
Partitionnement de la liste d’adresse par défaut.
La principale difficulté consiste dans la séparation des adresses de messagerie. Pour ce faire, il faudra impérativement procéder à la création d’un groupe global d’utilisateur pour chaque organisation qui sera contenu dans son OU. Une fois cela effectué, vous devrez supprimer les droits par défaut existants permettant de visualiser tout les objets au sein de l’Active Directory pour les utilisateurs authentifiés et pour le groupe tout le monde. Si vous êtes l’hébergeur vous aurez besoins par contre de conserver ces droits et donc de les réassigner pour un groupe de sécurité que vous aurez au préalablement créer.
Gérer les problématiques de recherche OWA
Une autre problématique dont vous aurez à vous souciez est la recherche OWA qui ne prend pas en compte les limitations de droits. Pour ce faire, il faudra positionner un attribut (msExcQueryBaseDN) sur chaque liste d’adresse et chaque utilisateur afin de restreindre les résultats de recherche.
Gérer les carnets d’adresse hors connexion.
Les carnets d’adresses hors ligne générés par le serveur Exchange contient par défaut la liste d’adresse globale. Si vous ne faites rien, les clients Outlook en mode cache récupéreront la liste complète de tout les utilisateurs. Rappelons que le carnet d’adresse est associé à une base de données Exchange (MDB). Si vous envisagez de stocker au sein d’une même base de données des utilisateurs de différentes organisation il faudra limiter le carnet d’adresse en utilisant l’attribut msExchUseOAB de façon à orienter le client Outlook sur un carnet d’adresse spécifique à télécharger.
Permettre les requêtes LDAP anonymes sur votre forêt Active Directory
La ségrégation des carnets d’adresse va nécessiter de mettre en place un paramètre qui va s’appliquer sur l’ensemble de la forêt et qui va autoriser les requêtes LDAP en mode anonyme. Ce paramètre (dsHeuristic) n’est pas positionné par défaut sur Windows 2003. Attention cette option n’est pas supportée par les serveurs Windows 2000 contrôleur de domaine.
Utilisation des Suffixe UPN.
Lors de précédentes réalisation que j’ai pu réaliser, l’utilisation des UPN pour chaque entité permet de faciliter la construction des listes d’adresse basées sur des critères de recherches. D’autre part, la mise en place de suffixes UPN permet aux utilisateurs de se connecter en utilisant leurs adresses email ce qui simplifie les processus de connexion en évitant de préciser le domaine NetBIOS et le FQDN du domaine hébergeur.
Conclusion
Comme nous avons pu le voir les principes de base existent et sont totalement supportés par Microsoft. Cependant, il est tout à fait évidement que ce type d’opération doit avant toutes choses être maquetté et testé de façon exhaustive avant d’être porté en production. D’autre part, la mise en place d’une solution « isolée » et mutualisée d’Exchange 2007 demande de prévoir une organisation en terme d’OU de l’Active Directory de façon à permettre cette dernière, rendant parfois difficile voir impossible l’adaptation d’un environnement d’ors et déjà en production.
Laurent Teruin