Microsoft Entra ID : annuaire, identité hybride et invités

Le badge que délivre la capitainerie

Un port à conteneurs ne distribue pas de clés. Il distribue des badges.

Le grutier, l'agent des douanes, le chauffeur du transporteur, le mécanicien du prestataire de maintenance : aucun ne possède de serrure sur le site. Chacun présente un badge délivré par la capitainerie, et chaque portique décide seul de le laisser passer.

Le badge n'ouvre rien par lui-même. Il prouve une identité. Ce que son porteur a le droit de faire une fois le portique franchi est une autre question, réglée par un autre document.

C'est exactement le contrat d'une infrastructure cloud, et c'est le point que beaucoup de projets ratent au démarrage. On loue un quai dans un port qu'on ne possède pas, on ne contrôle plus le grillage, et le seul endroit où l'on décide encore de tout, c'est le registre des badges.

Dans un centre de données classique, le périmètre est le réseau. Dans un port loué, le périmètre est l'annuaire. Tout ce qui suit dans cette série suppose que celui-ci est correctement posé.

Locataire, annuaire, abonnement

La capitainerie tient deux registres distincts. Celui des personnes habilitées à circuler, et celui des concessions : quel lot est loué par qui, et facturé à qui. Les deux se croisent en permanence, mais ce ne sont pas les mêmes objets.

Azure fonctionne de la même façon, avec trois mots qu'on emploie souvent l'un pour l'autre.

Le locataire est une instance de Microsoft Entra ID, dédiée à une organisation. C'est une frontière d'identité : deux locataires ne partagent rien par défaut.

L'annuaire est son contenu. Utilisateurs, groupes, appareils, applications enregistrées, principaux de service, identités managées. C'est ce que le locataire connaît.

L'abonnement est une frontière de facturation et un conteneur de ressources. Il fait confiance à exactement un locataire pour authentifier ceux qui viennent y travailler.

Un locataire porte autant d'abonnements que nécessaire. Un abonnement ne dépend que d'un locataire à la fois. On peut le transférer vers un autre, mais les attributions de rôles Azure ne suivent pas le déménagement : elles sont à refaire.

# Quel annuaire authentifie chacun de mes abonnements ?
az account list --query "[].{abonnement:name, locataire:tenantId, defaut:isDefault}" -o table

Le schéma dit une chose utile : l'annuaire est en amont de tout le reste. Une hiérarchie de groupes d'administration soigneusement dessinée n'a aucune valeur si les comptes qui la parcourent viennent d'un annuaire que personne ne tient.

Le locataire est l'objet le plus difficile à changer de toute une infrastructure Azure. On le choisit une fois, avant les abonnements, et on vit avec pendant des années.

Entra ID n'est pas un contrôleur de domaine

Le port a un système de badges. L'ancien entrepôt racheté l'an dernier a un trousseau de clés mécaniques, un tableau de consignes affiché au mur et un cahier de présence. Les deux gèrent de l'accès. Ils ne font pas le même métier, et aucun des deux ne remplace l'autre sans casse.

Un annuaire d'entreprise classique, du type services de domaine Active Directory, a été conçu pour un réseau géré. Il s'organise en forêts, domaines et unités d'organisation. Il parle LDAP, Kerberos et NTLM. Il joint des machines à un domaine, leur applique des stratégies de groupe, et suppose une connectivité interne.

Microsoft Entra ID a été conçu pour l'inverse : un service multilocataire, joignable depuis Internet, interrogé en HTTP. Son annuaire est plat. Il parle OAuth 2.0, OpenID Connect, SAML et WS-Federation pour l'authentification, SCIM pour l'approvisionnement de comptes, et s'administre par l'API Microsoft Graph.

Trois absences surprennent au premier contact. Pas de stratégie de groupe : la configuration des postes passe par une solution de gestion d'appareils. Pas de LDAP natif : une application ancienne qui ne sait faire qu'une requête LDAP ne se branchera pas dessus. Pas d'unités d'organisation au sens habituel : les unités administratives d'Entra ID servent à déléguer l'administration sur un sous-ensemble d'objets, pas à appliquer une politique technique.

En contrepartie, Entra ID apporte des objets qui n'ont pas d'équivalent dans un annuaire interne. Le principal de service, qui est l'identité d'une application dans le locataire. L'identité managée, qui est un principal de service dont Azure gère lui-même le cycle de vie et les secrets. Et l'identité d'appareil, avec ses trois états : enregistré pour un appareil personnel, joint à Entra pour un appareil d'entreprise né dans le cloud, joint hybride pour une machine déjà membre du domaine interne.

Le basculement mental tient en une phrase. On n'administre plus des machines présentes sur un réseau, on administre des identités qui appellent des API depuis n'importe où.

Le troisième larron : les services de domaine managés

Il arrive qu'un vieux hangar du terminal ait besoin de ses serrures mécaniques et qu'on ne puisse pas les remplacer. L'exploitant du port propose alors un service : il installe et entretient un jeu de serrures compatibles, alimenté automatiquement à partir du registre des badges. Le locataire du hangar n'a ni le plan des serrures, ni le droit d'en changer le modèle.

Microsoft Entra Domain Services rend précisément ce service. C'est un domaine managé, déployé dans un réseau virtuel, qui expose LDAP, Kerberos, NTLM, la jonction au domaine et la stratégie de groupe, sans qu'on ait à installer ni maintenir de contrôleurs de domaine. Son contenu provient d'une synchronisation depuis l'annuaire Entra ID.

Le cas d'usage est étroit et précis : héberger dans Azure une application ancienne qui exige ces protocoles, sans reprendre son code et sans exploiter soi-même des contrôleurs de domaine sur machines virtuelles.

Le point que le service ne dit pas assez fort : sa synchronisation va dans un seul sens. Ce qui est créé dans le domaine managé ne remonte ni vers Entra ID, ni vers l'annuaire interne. Pas d'extension de schéma non plus, ni de privilèges d'administration du domaine ou de l'entreprise.

Le choisir par défaut, parce qu'il porte le mot « domaine » et que cela rassure, est une erreur fréquente.

Les services de domaine managés sont une béquille de compatibilité pour des applications qu'on ne réécrit pas. Ce n'est ni le socle d'identité d'une organisation, ni un contrôleur de domaine dont on aurait simplement économisé le serveur.

L'identité hybride

La société de manutention qui opère le quai a son propre fichier du personnel, tenu depuis vingt ans, avec ses habilitations, ses visites médicales et ses départs. Le port ne va pas le recopier à la main. Il négocie une passerelle : les mêmes personnes, un seul badge, et une décision claire sur qui vérifie l'identité au moment du passage.

C'est toute la question de l'identité hybride, et elle se traite en deux temps qu'il ne faut jamais confondre. D'abord synchroniser les objets. Ensuite décider où l'authentification se joue.

Synchroniser les objets

Deux outils font le travail, avec des philosophies différentes.

Microsoft Entra Connect Sync s'installe sur un serveur Windows sur site. C'est l'outil complet : règles de transformation, filtrage fin, écriture différée de certains attributs vers l'annuaire interne. Sa configuration vit sur ce serveur, avec ce que cela implique de sauvegarde et de mise à niveau.

Microsoft Entra Cloud Sync repose sur un agent d'approvisionnement léger, dont la configuration est tenue côté cloud. On en déploie plusieurs pour la disponibilité, il sait traiter des forêts qui ne se voient pas entre elles, et il demande beaucoup moins d'exploitation. En échange, il ne couvre pas tous les scénarios de transformation avancée.

Le choix n'est pas doctrinal : on regarde la liste des cas que Cloud Sync ne couvre pas encore, et on prend Connect Sync uniquement si l'un d'eux est réellement nécessaire.

Où l'authentification se joue

Synchroniser un compte ne dit rien de la façon dont son mot de passe sera vérifié. Trois méthodes existent, et elles n'engagent pas du tout les mêmes dépendances.

La synchronisation de hachage de mot de passe transmet à Entra ID une empreinte dérivée du condensat stocké dans l'annuaire interne. Entra ID valide seul, sans appeler le site. C'est la méthode la plus simple à exploiter, et la seule qui permette à Microsoft de comparer les identifiants observés à ceux qui circulent dans les fuites publiques.

L'authentification directe délègue la vérification à des agents installés sur site. Ces agents n'ouvrent aucun port entrant : ils établissent des connexions sortantes et attendent les demandes. Le mot de passe n'est pas dérivé vers le cloud. En contrepartie, la disponibilité de la connexion dépend de celle des agents, d'où la règle d'en déployer plusieurs.

La fédération redirige l'utilisateur vers un service d'authentification hébergé sur site. C'est la seule voie quand la vérification doit se faire avec un dispositif que le cloud ne prend pas en charge, ou quand une contrainte de conformité impose que le contrôle reste physiquement à l'intérieur. C'est aussi, de loin, celle qui demande le plus d'infrastructure à publier, à maintenir et à surveiller.

La recommandation de Microsoft est nette : partir de la synchronisation de hachage, et n'en dévier que sur une exigence identifiée. Deuxième conseil, moins connu : garder cette méthode activée même quand on utilise l'une des deux autres. Le jour où le lien vers le site tombe, on bascule l'authentification vers le cloud au lieu de regarder l'organisation entière rester à la porte.

Une précision qui évite un malentendu fréquent : l'authentification unique transparente pour les postes joints au domaine interne fonctionne avec les deux premières méthodes. Choisir la synchronisation de hachage ne veut pas dire condamner les utilisateurs à ressaisir leur mot de passe toute la journée.

La question n'est pas de savoir quelle méthode est la meilleure. Elle est de savoir où l'on accepte que l'authentification s'arrête, et combien de temps, quand le site tombe.

Les identités externes

Le port fait entrer deux populations qui ne sont pas du personnel. Le chauffeur du transporteur partenaire, dont l'employeur garantit déjà l'identité et à qui l'on remet un badge visiteur limité. Et le grand public, pour la partie ouverte du site, qui se présente au guichet, décline son état civil et repart avec un titre d'accès de quelques heures.

Entra ID distingue ces deux cas, et les mélanger est une erreur structurante.

La collaboration entre organisations consiste à inviter une personne extérieure. Un objet invité est créé dans l'annuaire, mais l'identifiant reste chez elle : elle s'authentifie auprès de son propre locataire, d'un compte Microsoft, d'un fournisseur social fédéré, ou par code à usage unique envoyé par courriel. Aucun mot de passe supplémentaire à gérer, aucun compte à désactiver le jour de son départ de chez le partenaire.

Le point fort de ce modèle est ailleurs : une fois l'invité présent dans l'annuaire, il entre dans les groupes, dans les stratégies d'accès conditionnel et dans les revues d'accès, comme n'importe quel autre compte. Les paramètres d'accès entre locataires permettent en outre de dire quels partenaires sont acceptés, sur quelles applications, et si l'on fait confiance à l'authentification multifacteur déjà réalisée chez eux.

# Qui sont les invités présents dans l'annuaire ?
az ad user list --filter "userType eq 'Guest'" \
  --query "[].{nom:displayName, identifiant:userPrincipalName}" -o table

Les identités clients répondent à un autre besoin : des consommateurs, en volume, qui s'inscrivent seuls, sur des écrans aux couleurs de l'entreprise, parfois avec un fournisseur d'identité social. Cela se traite dans un locataire externe séparé, jamais dans l'annuaire de l'entreprise. Microsoft Entra External ID est l'offre actuelle pour ce scénario, et Azure AD B2C en est le service historique, vers lequel on n'oriente plus les nouveaux projets.

Un client n'a rien à faire dans l'annuaire d'entreprise. La règle paraît évidente écrite noir sur blanc, et pourtant c'est un raccourci fréquent dans les premiers projets.

Ce que les niveaux de licence débloquent

Le badge d'accès de base ouvre le portail piéton. Le stationnement au quai, l'accès aux zones sous douane et l'habilitation temporaire se paient en supplément. Le port l'écrit dans son barème, et personne ne s'en offusque.

Entra ID fonctionne pareil, et le sujet mérite d'être dit sans détour, parce qu'il décide de la faisabilité d'une conception.

Le niveau gratuit, inclus avec un abonnement Azure, couvre la gestion des utilisateurs et des groupes, la synchronisation depuis un annuaire interne, l'authentification unique vers les applications intégrées, et les valeurs par défaut de sécurité qui imposent une authentification multifacteur à tout le monde, sans réglage possible.

Le niveau P1 ouvre l'accès conditionnel, c'est-à-dire la capacité de décider d'une connexion selon son contexte. Il apporte aussi l'appartenance dynamique de groupe, définie par une règle sur les attributs plutôt que par une liste tenue à la main.

user.department -eq "Manutention" and user.accountEnabled -eq true

Le niveau P2 ajoute l'évaluation du risque, sur le compte et sur la connexion, et les mécanismes d'élévation temporaire de privilèges. Les fonctions de gouvernance, gestion des droits d'accès, revues périodiques et flux de cycle de vie, sont regroupées dans une offre dédiée, Microsoft Entra ID Governance, dont une partie est incluse au niveau P2.

La conséquence pratique est simple. La plupart des recommandations de sécurité sur ce sujet supposent au minimum le niveau P1. Un projet qui prévoit un pilotage d'accès sérieux et budgète le niveau gratuit se retrouvera à réécrire sa conception à la première revue.

La facturation des utilisateurs externes suit un modèle distinct, fondé sur les utilisateurs actifs mensuels et non sur un poste attribué à l'année.

Le niveau de licence n'est pas une case administrative. Il détermine ce que la conception a le droit de supposer, et il se tranche avant le premier schéma d'architecture.

Scénario B : le 15 mars 2021, plus personne n'a de badge

Ce jour-là, l'authentification vers Azure Active Directory, nom que portait alors le service devenu Microsoft Entra ID, échoue pendant plusieurs heures pour un grand nombre de clients. Les services qui s'appuient sur cet annuaire deviennent inaccessibles.

Le rapport post-incident publié par Microsoft dans l'historique d'état d'Azure décrit une opération portant sur les clés de signature utilisées pour émettre et valider les jetons d'authentification. Une clé encore utilisée a été retirée. Les jetons signés avec elle ne pouvaient plus être validés, et les connexions échouaient.

Le détail à retenir n'est pas la mécanique de la rotation de clé, qui est un exercice de routine sur ce genre de service. C'est ce qui s'est passé autour.

Les machines virtuelles des clients tournaient. Les bases de données répondaient. Les applications déjà démarrées avec un jeton encore valide continuaient de fonctionner un moment. Et pourtant, l'accès au portail, l'ouverture de session sur les outils de travail et l'authentification des scripts d'exploitation ne passaient plus. Une infrastructure en parfait état de marche, rendue inutilisable par la seule brique qui décide de qui a le droit d'entrer.

Trois conséquences de conception en découlent, et elles valent bien au-delà de cet incident précis.

D'abord, l'identité est une dépendance de tout le reste, y compris de l'outillage avec lequel on répondrait à un incident. Une console d'administration, un tableau de bord de supervision ou un accès distant qui s'authentifient contre l'annuaire tombé ne sont plus des outils de crise.

Ensuite, les comptes d'accès de secours existent pour ce genre de moment. Quelques comptes réservés à l'urgence, exclus des stratégies d'accès conditionnel qui pourraient les bloquer, avec des identifiants longs conservés hors ligne, et une alerte déclenchée à chaque utilisation. Ils ne servent presque jamais, et le jour où ils servent, on ne les improvise pas.

Enfin, le choix de méthode d'authentification hybride décrit plus haut protège de la panne symétrique, celle où c'est le site interne qui tombe et non le cloud. Les deux directions de panne existent, et une seule des trois méthodes couvre la seconde par construction.

Quand la capitainerie ne délivre plus de badges, l'état des quais n'a plus d'importance. Aucune redondance applicative ne compense la défaillance de la brique qui authentifie, parce qu'elle est en amont de tout ce qui pourrait la compenser.

Points clés

• Le locataire est une frontière d'identité, l'abonnement une frontière de facturation. Un abonnement ne fait confiance qu'à un locataire, et le transfert vers un autre efface les attributions de rôles.
• Entra ID n'est pas un annuaire de domaine dans le cloud : pas de stratégie de groupe, pas de LDAP natif, pas d'unités d'organisation au sens habituel. Les services de domaine managés ne sont qu'une béquille de compatibilité pour des applications qu'on ne réécrit pas.
• Synchroniser les objets et décider où l'authentification se joue sont deux décisions séparées. La seconde détermine si une panne du site interne empêche ou non de se connecter au cloud.
• La synchronisation de hachage de mot de passe est le point de départ raisonnable, et reste utile en secours même quand une autre méthode est en place.
• L'accès conditionnel, l'évaluation du risque et l'élévation temporaire de privilèges supposent un niveau de licence payant. Ce choix se fait avant la conception, pas pendant la revue de sécurité.

Dans la série

Palier 1 : Ouvrir le port. Domaine : Identité.

• Précédent : Maîtriser la facture : budgets, réservations, dimensionnement
• Suivant : RBAC, accès conditionnel et PIM : donner le bon accès
• Vue d'ensemble : Concevoir sur Azure : par où commencer

Pour aller plus loin

• RBAC, accès conditionnel et PIM : donner le bon accès, pour la suite logique de ce billet : savoir qui est quelqu'un ne dit pas ce qu'il a le droit de faire.
• Sécuriser ses applications : Key Vault, identités managées, chiffrement, pour le prolongement côté applications, où l'identité managée remplace le secret écrit en dur.
• Authentification, MFA et SSO : prouver qui on est, pour les mécanismes d'authentification vus indépendamment d'un fournisseur.
• IAM et PAM : gérer identités et accès à privilèges, pour le cadre général dans lequel s'inscrivent les comptes d'accès de secours.
• Documentation Microsoft Entra ID, pour le tour d'horizon officiel du service et de ses objets.
• Choisir une méthode d'authentification hybride, qui détaille les critères de décision entre les trois méthodes.
• Vue d'ensemble de l'identité hybride, pour les outils de synchronisation et leurs différences de couverture.
• Microsoft Entra Domain Services, pour les limites exactes du domaine managé.
• Collaboration entre organisations avec Entra External ID, pour le fonctionnement des comptes invités et des paramètres d'accès entre locataires.
• Licences Microsoft Entra, à consulter directement plutôt que de se fier à une liste recopiée, les contenus des niveaux évoluant régulièrement.