Les autorisations inter-forêts ont longtemps été l’un des aspects les plus difficiles d’une migration Exchange hybride. S’assurer que les permissions des boîtes mails sont préservées peut être une problématique majeure.

Initialement, les migrations Exchange hybrides ne prenaient en charge aucune autorisations de boîte mail inter-forêts. Puis, après quelques années, Microsoft a permis à ceux qui avaient les autorisations d’accès total de travailler entre les organisations Exchange.

Récemment, Microsoft a amélioré la gestion des autorisations inter-forêts pour les déploiements Exchange hybride. Vous trouverez dans cet article les scénarios possible permettant de maintenir les différentes autorisations de délégation en hybride.

Autorisations d’accès complet et automapping

Lorsque les autorisations d’accès complet sont attribuées avant le déplacement, tout continue de fonctionner. Cependant, la configuration des autorisations d’accès complet après la migration d’une boîte aux lettres ne permet pas de maintenir l’automapping.

Le problème ne vient pas des permissions, elles sont là, et elles fonctionnent. Le problème est lié aux attributs de l’automapping. Deux attributs Active Directory doivent être mis à jour pour qu’il fonctionne :

• La boîte mail autorisée : msExchDelegateListLink
• L’utilisateur auquel des autorisations sont accordées : msExchDelegateListBL

AAD Connect synchronisera ensuite tous les attributs appropriés dans Azure AD et l’automapping fonctionnera comme prévu.

L’autorisation Send-As

L’autorisation Send-As permet à un utilisateur d’envoyer des messages depuis l’adresse e-mail principale d’un autre utilisateur.

Si les autorisations Send-as sont configurées avant la migration de tous les comptes, elles fonctionneront. Le problème est le même que pour le full access ,l’ajout d’autorisations Send-as après la migration de l’une des boîtes mail vers Office 365 ne fonctionnera pas car les autorisations Active Directory réelles ne sont pas synchronisées.

La solution consiste à ajouter manuellement les autorisations sur l’objet cloud et l’objet local.

Cette solution de contournement n’est pas supportée par Microsoft à ce jour. Ils travaillent sur une solution plus gérable, mais sans communiquer de date.

L’autorisation Send-on-Behalf-of

Send-on-behalf est comme Send-as sauf que le destinataire voit que le message a été envoyé par une autre personne.

Si la configuration est effectuée avant la migration des comptes, les autorisations sont conservées. Send-on-behalf ne peut cependant pas être configuré à travers les organisations.

Le problème ici est que l’attribut PublicDelegates AD n’a pas été synchronisé par Azure AD Connect. Microsoft a résolu ce problème avec la dernière version d’Azure AD Connect, déployée en avril 2018. Une fois votre serveur Azure AD Connect mis à jour, les autorisations Send-on-behalf fonctionneront.

Accès délégué

L’accès délégué désigne une combinaison de droits accordés par un utilisateur à un autre. L’accès délégué est accordé depuis Outlook.

La configuration de l’accès délégué dans les déploiements hybrides Exchange dépend de la version d’Exchange que vous avez en local.

En résumé

Nous sommes encore loin des autorisations de boîtes mail inter-forêts transparentes qui fonctionnent dans les déploiements Exchange hybrides. Comme vous pouvez le voir, cela peut demander un effort considérable pour définir ces autorisations, en fonction des autorisations et de la situation dans laquelle vous souhaitez les installer.

Il est important de noter que Microsoft ne prend toujours pas en charge la modification des attributs Exchange via des outils autres que Exchange Admin Center ou Exchange Management Shell. Cela signifie que plusieurs des correctifs mentionnés ci-dessus sont “non supportés”.

Il est donc recommandé pour le moment de conserver les permissions inter-forêts pour un petit nombre de boîtes mail si cela est possible.