Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/06900.jsonl.gz/533

Noms uniques et historique des échanges
Microsoft a annoncé dans MC365786 (30 avril) qu’il commencera à déployer cette modification sur les tenants à la fin du mois de mai.
Le 13 avril, le groupe de développement Exchange a annoncé un changement qui a pris une petite partie de l’histoire du produit. Microsoft souhaite modifier le format des attributs Name et DistinguishedName pour les boîtes aux lettres afin de les rendre plus uniques et prévoit d’utiliser l’identificateur d’objet d’annuaire externe à la place.
Lorsque Microsoft a lancé Exchange 4.0 en 1996, les normes X.400 et X.500 exerçaient encore une énorme influence sur le monde du courrier électronique. Pour cette raison, les développeurs ont utilisé des conventions d’affectation de noms de type X.500 dans les Exchange Directory Store (DS), le précurseur de ce qui est devenu Active Directory lorsque Windows 2000 a été lancé en 1999 et Azure Active Directory plus tard. Les objets X.500 utilisent des noms uniques comme identificateurs uniques. Pour créer un nom unique X.500, vous concaténez des attributs pour former un chemin d’accès à l’entrée nommée. Les objets à extension messagerie Exchange Online ont toujours ces valeurs dans la propriété LegacyDn, où vous trouverez quelque chose comme ceci :
Exchange Online a sa propre forme de noms uniques, qui servent toujours d’identificateurs uniques pour les objets. Voici un exemple :
La partie CN (nom commun) provient du nom de la boîte aux lettres. Les entités d’unité d’organisation identifient le client Microsoft 365 et Exchange Online, tandis que les entités de contrôleur de domaine attribuent le chemin d’accès au contrôleur de domaine Outlook.com auquel Exchange Online s’est connecté lors de la création de la boîte aux lettres.
Rendre la synchronisation plus sympa
Ce que Microsoft dit maintenant, c’est que le format utilisé pour les noms uniques Exchange Online doit changer. Ils ont rencontré des situations où des conflits se sont produits lorsque des objets se synchronisent d’Azure Active Directory vers Exchange Online. Lorsqu’ils ont réfléchi à la façon dont les conflits se sont produits, ils ont décidé qu’une meilleure source d’unicité était nécessaire.
Microsoft propose de modifier la génération de la propriété Name pour les objets à extension messagerie à partir de sa base actuelle (MailNickName ou Alias) pour utiliser l’identificateur d’objet d’annuaire externe pointant vers le compte Azure AD propriétaire de l’objet. Explorons ce que cela signifie.
Utilisation d’identificateurs uniques
Tous les objets Azure AD ont des identificateurs uniques (GUID). Lorsque vous créez un compte Microsoft 365 avec une licence Exchange Online, Exchange Online prend la propriété MailNickName du compte et l’utilise pour le nom de boîte aux lettres et les propriétés d’alias. Par exemple, si vous créez un nouveau compte avec un nom d’utilisateur de <email-pii>, parmi les propriétés du compte Azure AD figurent :
- GivenName: Sue
- Nom de famille: Pickett
- MailNickName: Sue.P.Pickett
- Courrier : <email-pii>
- UserPrincipalName : <email-pii>
- ObjectId: b67c8bd7-a8d3-4358-b42f-cd51821f7ba3
Lorsqu’Exchange Online crée une boîte aux lettres, il prend la valeur MailNickName et l’utilise pour créer l’alias, le nom et le nom unique de la boîte aux lettres. Les deux premières propriétés ont la même valeur que MailNickName, tandis que le nom unique devient :
En outre, Exchange Online écrit l’ObjectId du compte Azure AD dans la propriété ExternalDirectoryObjectId de la boîte aux lettres. Vous pouvez utiliser cette valeur pour rechercher une boîte aux lettres, comme dans :\
La modification proposée par Microsoft signifie qu’Exchange Online utilisera l’identificateur de compte Azure AD pour le nom de boîte aux lettres et comme partie CN du nom unique. Par conséquent, nous nous retrouvons avec:
Étant donné qu’un identificateur de compte Azure AD est unique dans Microsoft 365, les propriétés de la boîte aux lettres Exchange seront également uniques et résoudront les problèmes de synchronisation. En fait, vous pouvez écrire l’identificateur de compte dans la propriété Name d’une boîte aux lettres aujourd’hui si vous le souhaitez :
Lorsque vous mettez à jour la propriété Name, Exchange met à jour le nom unique de la boîte aux lettres afin que la partie CN du nom corresponde à la valeur attribuée à la propriété Name.
Noms uniques et Exchange Online
Les noms uniques existent uniquement dans Exchange Online. Aucune trace d’entre eux n’existe dans les propriétés d’objet Azure AD, car le lien entre Azure AD et Exchange Online se fait via l’identificateur d’objet d’annuaire externe. Cette propriété existe pour tous les objets Exchange Online qui ont un objet correspondant dans Azure AD :
- Boîtes aux lettres (tous les types – utilisateur, partagé, salle, groupe).
- Listes de distribution (mais pas les listes de distribution dynamiques ou les listes d’espace).
- Contacts de messagerie.
- Utilisateurs de messagerie.
Microsoft indique que la modification s’appliquera uniquement aux nouveaux objets à extension messagerie. Ils ne prévoient pas de mettre à jour rétrospectivement les anciens objets avec le nouveau schéma de nommage. Lorsque le nouveau schéma de dénomination sera déployé, Microsoft indique qu’il arrêtera la capacité des administrateurs à mettre à jour la propriété Nom de la boîte aux lettres à l’aide de cmdlets telles que Set-Mailbox et Set-User, ce qui semble logique.
Une pause pour réfléchir
Peu de temps après que Microsoft ait publié son blog, ils ont ajouté une mise à jour disant que, sur la base des commentaires, ils retarderont le changement et donneront un nouveau calendrier à la fin du mois d’avril. Je pense que c’est raisonnable. Bien que je ne m’inquiète pas de l’utilisation d’identificateurs d’objet dans les noms uniques, la propriété Name est un peu différente car Exchange Online l’expose plus souvent. Par exemple, si vous regardez qui gère un groupe de distribution, cette sortie ne semble pas correcte :
Et la liste des boîtes aux lettres utilisateur avec Get-Recipient semble étrange :
Alors que la vérification de qui dispose de l’autorisation Envoyer en tant que pour une boîte aux lettres partagée devient plus une corvée :
Les interfaces utilisateur Exchange et Microsoft 365 masquent le basculement car elles peuvent prendre les GUID et les résoudre en valeurs « jolies » comme les noms d’affichage (Figure 1).
Tout problème potentiel se posera dans les scripts d’administration qui utilisent les propriétés Name ou DistinguishedName et s’attendent à ce que les valeurs renvoyées par Exchange Online suivent un certain format. Les scripts (comme celui-ci pour signaler les listes de distribution et leurs gestionnaires) qui résolvent les valeurs pour récupérer les noms complets ne sont pas affectés par la modification.
Comme toute modification proposée pour quelque chose qui est utilisé depuis très longtemps, il y a forcément des cas extrêmes qui se présentent et doivent être résolus. Je pense que les développeurs Exchange sont sur la bonne voie pour rechercher des ancres uniques pour la synchronisation. J’espère juste qu’ils pourront y arriver sans causer trop de bouleversements pour les clients.