Translate

samedi 21 juillet 2012

[TUTORIEL]: Partage entre Organisations Exchange (partie 2: coexistence "riche")

Rappel de la première partie.


Nous avons vu comment:
  1. Créer des Availability Address Spaces
  2. "Une méthode" pour interconnecter deux organisations Exchange (une 2010 SP2 et une 2007 SP3)
  3. Observé que l'affichage des informations de disponibilité était fonctionnelle
Maintenant, nous allons aller un peu plus loin et explorer le partage du *contenu* des boîtes aux lettres au travers des habituelles permissions Mapi/Cdo d'Outlook.

Partie 2: Mise en oeuvre d'une coexistence riche au travers de délégations inter-organisationnelles. 

2.1) Quel est le problème, au fond ?

C'est très simple... Lorsque nous donnons des permissions sur un dossier (type "Boite de réception" ou "Calendrier"), Outlook utilise la référence de sécurité de l'objet de notre délégué, à savoir son "SID" (Security IDentifier).

Or, le SID est typiquement mis sur un objet de securité, type un objet 'user' ou 'inetOrgPerson' ou bien sûr un groupe, lorsqu'il s'agit d'un groupe de sécurité.

Dans l'état actuel des choses, mon délégué (John Doe) est actuellement hébergé chez PARTNER Inc. (représentant un département historique du Groupe et qui doit "converger" dans le Système d'Information Corp). Bref, c'est actuellement un ... contact. Et donc, il n'est pas un objet de sécurité.

Si l'on essaye d'assigner des droits à un contact depuis Outlook, ce dernier nous dira de manière très sympathique

Alors gambergeons un peu. Cela nous rappelle un scénario OCS/Lync que l'on appelle "Central Forest". C'est une variante du "Resource Forest" où les objets représentant les comptes OCS/Lync sont des contacts. Ces contact ont vocation à représenter les objets dans l'annuaire Active Directory et répliqués dans la base OCS/Lync. En ce qui concerne la securité et l'authentification ils sont cependant reliés à un compte utilisateur d'une forêt que l'on identifie comme "Forêt utilisateur". La relation est faite avec l'attribut 'msRTCSIP-OriginatorSid' dans lequel on copie le SID de l'utilisateur.

Et si Exchange pouvait faire pareil? On connait bien le 'msExchMasterAccountSid' qui est utilisé dans un cas de forêt de ressources où typiquement il existe un compte utilisateur désactivé portant les attributs Exchange représentant la configuration de la boite aux lettres (server, base de donnée, alias, etc...).

2.2) OK, et...?

Sur cette base, on sait qu'il existe un moyen d'associer une boîte aux lettres d'une forêt 'R' (comme Ressource :)) à une compte d'une forêt 'U' (comme Utilisateur). Mais dans le cas d'une coexistence entre organisations, cela ne suffit pas... et encore moins sur des objets de type 'Contact'.

Lorsque l'on regarde les types d'objets connus dans Exchange 2007 et Exchange 2010, on voit qu'il existe un type nommé "Across-Forest Contact". Késako? Simplement un type spécialisé de contacts AD/Exchange autorisant l'utilisation de certains attributs, ceci à des fins de partage inter-Organisations:
  • targetAddress: son utilité ne change pas, et permet toujours la localisation des Web Services pour utilisation des Free/Busy
  • mAPIRecipient: permet à Exchange/Outlook de voir le contact comme un objet sur lequel on a la capacité d'accéder en tant que délégué (utilisé quand un quelqu'un de l'Org A veut se connecter à la boîte aux lettres de quelqu'un de l'Org B)
  • msExchMasterAccountSid: référence le SID d'un utilisateur de l'organisation voisine (utilisé quand un quelqu'un de l'Org A veut donner des permissions à quelqu'un de l'Org B)
  • msExchOriginatingForest: référence la Forêt AD d'origine, et permet donc au referral de notre Organisation d'aller chercher un Referral dans l'autre Forêt/Organisation et donc de se connecter en MAPI !!! Ta-da!
Voici donc les quatre attributs critiques. Il en reste deux, qui permettent à Exchange de détecter que notre contact est un "Cross-Forest Contact" et de réagir en conséquence:
  • msExchRecipientDisplayType: type de l'objet
  • msExchRecipientTypeDetails: type détaillé

2.3) Création d'un Cross-Forest MailContact

Dans un scénario réel, il serait de la résponsabilité d'ILM 2007 SP1 ou de FIM 2010 / FIM 2012 R2 d'effectuer cette besogne. Il suffit pour cela de cocher la case idoine dans la partie synchron inter-forêt (Enable cross-forest delegation for Exchange Server 2007/Exchange Server 2010).

Ici, nous allons le faire à la main, pour cela un petit script suffit. Il a pour doux nom de 'Enable-CrossForestMailContact.ps'. Il s'agit d'un script qui va ajouter les attributs nécessaires sur un objet 'MailContact' déjà existant. Voici l'usage:
On spécifie ici l'identité du contact, l'utilisateur lié, un contrôleur de domaine d'origine et la forêt d'origine. Le script sera en charge d'aller chercher le reste. Une fois terminé, l'objet MailContact modifié et apparaît en lecture seule. Normal? Il semblerait que oui puisque ce type d'objet n'est censé être touché/modifié que dans un contexte de synchronisation d'annuaires, et donc via des interfact LDAP/ADSI et non via Exchange...

Il sera nécessaire de faire les modifications dans les deux sens afin de 1) pouvoir donner les délégations et 2) de voir le contact de l'autre côté comme un contact fédéré.

2.4) Résultats

N'oubliez pas mettre à jour votre (ou vos) OABs.
  • Get-OfflineAddressBook | Update-OfflineAddressBook
  • puis un fois la génération terminée: Get-ClientAccessServer | Update-FileDistributionService -Type OAB
Il ne reste plus qu'à démarrer vos clients Outlook, puis de récupérer l'OAB à jour.

Côté "John Doe" (Org B), je peux désormais donner l'accès à mon Calendrier à "Benoit Boudeville" en mode Editeur... Je peux même passer par l'assistant de délégation classique.

Une fois ces actions effectuées, mon client côté Exchange 2010 (Benoit Boudeville) doit aussi mettre à jour son OAB, s'il existait un accès à un Calendrier partagé (anciennement en Free/Busy seuls donc), il change automatiquement en accès complet, comme si "John Doe" avait magiquement été migré sur Exchange 2010 !!!
Et l'on voit bien que l'accès se fait directement en MAPI (ici vers le serveur Exchange 2007):
Il va sans dire que cela fonctionne pour tous les dossiers que l'on peut déléguer via Outlook, cela devrait aussi fonctionner pour des accès de type "Full Mailbox Access".

A vour de jouer !!! :)

5 commentaires:

  1. Bonjour, merci pour ce tuto .
    Une question : ou trouve t'on ce script 'Enable-CrossForestMailContact.ps1' ?
    Merci encore

    RépondreSupprimer
  2. Hello Mr (ou Mme) Anonyme :)
    Sur mon SkyDrive ==> http://sdrv.ms/PmMSy6 ==> dans le répertoire PowerShell/Admin.

    RépondreSupprimer
  3. Bonjour,

    Merci pour tous ces tutos très intéressants sur le partage entre les organisations Exchange.

    J'ai une question sur l'utilisation du Script, voici mon cas
    J'ai deux domaines (domaine1.local et domaine2.fr)
    Les Noms SMTP des deux domaines sont donc domaine1.fr et domaine2.fr, je n'ai donc pas de soucis pour le domaine2.fr mais pour le premier domaine.
    Une relation d'approbation existe entre les deux forêts. Un Utilisateur X@domaine2.fr contient dans ses contact l'utilisateur Y@domaine1.fr
    Quelles sont les informations à renseigner en paramètre du script, mon idée est la suivante mais j'aimerais confirmation :
    -Identity Y@domaine.fr
    -LinkedMasterAccount DOMAINE1.LOCAL\Y
    -LinkedDomainController srv-ad.domaine1.local
    -OriginatingForest domaine1.local

    Merci d'avance.

    RépondreSupprimer
  4. Bonjour Dimitri,
    Oui l'usage est correct. Cela fait longtemps que je n'ai pas mis quelques scripts à jour. Je vais faire ça en rentrant de week-end. Regardez donc dans quelques jours.

    RépondreSupprimer
    Réponses
    1. Bonjour Benoit,

      Merci pour votre réponse très rapide.
      Très bien je regarderais dans quelques jours, je n'ai pas encore eu le temps de tester de mon coté mais cela ne serais tarder.

      Bonne continuation.

      Supprimer