Intégration identité et annuaire : où commencent et s'arrêtent Entra ID, LDAP et le SSO

L'échec le plus silencieux d'un intranet se loge dans sa liste d'utilisateurs. Au lancement, on importe un tableur transmis par les RH et tout le monde est satisfait pendant un mois ; six mois plus tard, trois personnes parties y figurent encore, cinq arrivées manquent, et plus personne ne fait confiance à l'organigramme. Ce n'est pas un problème de contenu mais de source de vérité : la réalité des effectifs vit dans un autre système.

Se connecter à l'annuaire d'entreprise règle cela. Mais « intégration annuaire » ne désigne pas une seule chose : ce sont deux métiers que l'on confond régulièrement.

Le SSO authentifie, l'annuaire alimente

Tracer cette ligne d'emblée simplifie toutes les décisions suivantes.

Le SSO (SAML ou OIDC) relève de l'authentification. Les personnes se connectent avec leur compte d'entreprise, ne conservent pas de mot de passe propre à l'intranet, et perdent l'accès dès que ce compte est fermé. La question à laquelle le SSO répond est : « Cette personne est-elle bien celle qu'elle prétend être ? »

Le rapprochement d'annuaire relève de l'alimentation en données. Il lit qui est employé, dans quel service, avec quel intitulé de poste, et l'écrit sur les profils de l'intranet. Sa question est différente : « De qui l'effectif se compose-t-il aujourd'hui ? »

L'un ne remplace pas l'autre. En déployant seulement le SSO, les connexions s'améliorent tandis que l'annuaire continue de vieillir — car une personne qui ne s'est jamais connectée n'apparaît pas du tout. En déployant seulement le rapprochement, l'annuaire reste à jour mais chacun porte encore un mot de passe distinct. Les installations matures font tourner les deux.

Côté Entra ID

Du côté de Microsoft Entra ID (anciennement Azure AD), la mise en place commence par un enregistrement d'application. L'intranet se connecte à l'annuaire sous sa propre identité via cet enregistrement ; le compte personnel de personne n'est utilisé.

Trois valeurs sont nécessaires : l'identifiant d'annuaire (locataire), l'identifiant d'application (client) et un secret client. Plus une autorisation : pour lire les effectifs, l'application reçoit User.Read.All, et cet octroi passe par le consentement administrateur. Lorsque cette étape est oubliée, le test de connexion obtient bien un jeton mais la liste d'utilisateurs revient vide — raison pour laquelle un test sérieux ne doit pas s'arrêter au jeton : il doit réellement interroger le point d'accès des utilisateurs.

Notez aussi que le secret client expire. À son échéance, l'intégration s'arrête sans bruit ; un rappel dans l'agenda coûte moins cher que de chercher six mois plus tard pourquoi la synchronisation ne fonctionne plus.

Côté LDAP / Active Directory

Lorsqu'un Active Directory classique existe en interne, la connexion passe par LDAP. Les besoins y sont différents : l'adresse du serveur, un compte disposant de droits de lecture (bind DN) et le point de départ de la recherche (base DN).

Deux détails déterminent la plupart des déploiements. Le premier est la connexion chiffrée : sans LDAPS ni StartTLS, des identifiants d'entreprise circulent en clair sur le réseau. Le second est le filtrage des comptes désactivés : dans Active Directory, les enregistrements des personnes parties ne sont généralement pas supprimés mais désactivés. Cet état tient dans un bit de l'attribut userAccountControl ; absent du filtre, chaque départ arrive dans l'intranet comme « salarié actif » — reproduisant exactement le problème que l'on voulait résoudre, cette fois automatiquement.

Prévisualiser, puis appliquer

Le scénario le plus redouté dans ce type d'intégration est une mauvaise configuration qui abîme l'effectif en bloc. La réponse tient à une discipline simple : l'écart est montré d'abord, l'application demande une validation séparée.

En pratique, le déroulé est le suivant : le test de connexion passe, le système compare les enregistrements de l'annuaire aux profils de l'intranet et produit une liste d'écarts — combien ont été rapprochés, de qui le service a changé, qui ne figure plus dans l'annuaire. Un administrateur lit cette liste, puis l'applique.

Il faut aussi connaître les limites dès le départ. Dans Wepilot, le rapprochement ne crée ni comptes ni services ; il met à jour des profils existants. La raison est la prudence : des centaines de comptes créés à cause d'un filtre erroné se rattrapent bien plus difficilement que des champs de profil écrits par la même erreur. Le cycle de vie entièrement automatisé des comptes — arrivées, mobilités, départs via SCIM — est un autre sujet, hors du périmètre de cette intégration.

Où résident les secrets ?

Ce que porte cette intégration n'est pas un réglage ordinaire mais un accès à votre annuaire. Le secret client et le mot de passe LDAP ne doivent jamais atteindre le navigateur.

Le bon schéma consiste à conserver ces enregistrements dans une table dépourvue de toute politique de lecture, et à ne renvoyer à l'écran d'administration que l'information « un secret est-il défini ou non ». Un administrateur peut remplir le champ, mais ne peut pas relire ce qu'il a écrit auparavant. Cela diffère du fait de masquer un champ dans l'interface : la contrainte se situe au niveau de la base de données, et aucune requête venue d'un navigateur ne la contourne. Nous avons décrit d'autres endroits où s'applique ce principe dans l'article sur la protection des données.

Par où commencer ?

Notre ordre est net : mettez d'abord en place le rapprochement d'annuaire, passez ensuite au SSO. La raison est pratique — un annuaire juste produit dès le premier jour un bénéfice visible par tous, tandis que le SSO exige une coordination avec l'équipe identité et une fenêtre de test.

La mesure est simple elle aussi : le nombre d'enregistrements non rapprochés, le nombre de personnes présentes dans l'annuaire mais absentes de l'intranet, et le temps écoulé depuis la dernière synchronisation réussie. Si ces trois indicateurs ne tendent pas vers zéro, l'intégration est installée mais n'est pas exploitée. Nous traitons ce type de responsabilité de processus dans l'article sur l'exploitation.