Authentification unique transparente Microsoft Entra : analyse technique approfondie

Cet article vous donne des détails techniques sur le fonctionnement de la fonctionnalité d’authentification unique transparente (Seamless SSO) de Microsoft Entra.

Fonctionnement de l’authentification unique transparente (SSO)

Cette section est composée de trois parties :

  1. Configuration de la fonctionnalité d’authentification unique transparente.
  2. Fonctionnement d’une transaction de connexion mono-utilisateur dans un navigateur web avec l’authentification unique transparente.
  3. Fonctionnement d’une transaction de connexion d’un seul utilisateur sur un client natif avec SSO transparent.

Comment la configuration s’opère-t-elle ?

L'authentification unique transparente est activée à l'aide de Microsoft Entra Connect, comme indiqué ici. Voici ce qu’il se passe pendant l’activation de la fonctionnalité :

  • Un compte d'ordinateur (AZUREADSSOACC) est créé dans votre Active Directory (AD) sur site dans chaque forêt AD que vous synchronisez avec Microsoft Entra ID (à l'aide de Microsoft Entra Connect).
  • Qui plus est, un certain nombre de noms principaux de service (SPN) Kerberos sont créés pour être utilisés lors du processus de connexion à Microsoft Entra.
  • La clé de déchiffrement Kerberos du compte informatique est partagée en toute sécurité avec Microsoft Entra ID. S’il existe plusieurs forêts Active Directory, chaque compte d’ordinateur a sa propre clé de déchiffrement Kerberos unique.

Importante

Pour des raisons de sécurité, le compte d’ordinateur AZUREADSSOACC doit être fortement protégé. Seuls des administrateurs de domaine doivent être en mesure de gérer le compte d’ordinateur. Vérifiez que la délégation Kerberos sur le compte d’ordinateur est désactivée et qu’aucun autre compte dans Active Directory ne dispose d’autorisations de délégation sur le compte d’ordinateur AZUREADSSOACC. Stockez le compte d’ordinateur dans une unité d’organisation (UO) où il sera protégé contre les suppressions accidentelles et à laquelle seuls des administrateurs de domaine ont accès. La clé de déchiffrement Kerberos sur le compte d’ordinateur doit également être traitée comme sensible. Il est fortement recommandé que vous substituiez la clé de déchiffrement Kerberos du AZUREADSSOACC compte d’ordinateur au moins tous les 30 jours.

Importante

L’authentification unique transparente prend en charge les types de chiffrement Kerberos suivants : AES256_HMAC_SHA1, AES128_HMAC_SHA1et RC4_HMAC_MD5. Pour renforcer la sécurité, Microsoft recommande de configurer le compte AzureADSSOAcc$ pour utiliser AES256_HMAC_SHA1 ou un autre type de chiffrement basé sur AES au lieu de RC4. Le type de chiffrement configuré est stocké dans l’attribut msDS-SupportedEncryptionTypes du compte dans services de domaine Active Directory (AD DS).

À compter de la mise à jour de juillet 2026 Windows Server, le type de chiffrement Kerberos par défaut dans AD DS passe de RC4 à AES-256. Les organisations qui continuent d’utiliser RC4 peuvent rencontrer des problèmes d’authentification ou d’authentification unique transparente après l’application de cette mise à jour. Pour garantir un accès sans interruption de l’authentification unique, Microsoft recommande de migrer le compte AzureADSSOAcc$ vers AES-256 dès que possible.

Si le compte AzureADSSOAcc$ est actuellement configuré pour utiliser RC4_HMAC_MD5 et que vous envisagez de passer à un type de chiffrement basé sur AES, vous devez d’abord renouveler la clé de déchiffrement Kerberos du compte AzureADSSOAcc$, comme décrit dans la documentation de la FAQ. Le fait de ne pas renouveler la clé avant de modifier le type de chiffrement peut empêcher Seamless SSO de fonctionner correctement.

Une fois la configuration terminée, l’authentification unique transparente fonctionne de la même façon que n’importe quelle autre connexion utilisant l’authentification Windows intégrée (IWA).

Fonctionnement des connexions dans un navigateur web avec l’authentification unique transparente

Le flux de connexion dans un navigateur web est le suivant :

  1. Un utilisateur tente d’accéder à une application web (par exemple, Outlook Web App - https://outlook.office365.com/owa/) à partir d’un appareil d’entreprise joint à un domaine du réseau de l’entreprise.

  2. Si l’utilisateur n’est pas encore connecté, l’utilisateur est redirigé vers la page de connexion Microsoft Entra.

  3. L'utilisateur saisit son nom d'utilisateur sur la page de connexion Microsoft Entra.

    Remarque

    Pour certaines applications, les étapes 2 et 3 ne sont pas nécessaires.

  4. En utilisant JavaScript en arrière-plan, Microsoft Entra ID défie le navigateur, via une réponse 401 non autorisée, de fournir un ticket Kerberos.

  5. Le navigateur, à son tour, demande un ticket à Active Directory pour le compte d'ordinateur AZUREADSSOACC (qui représente Microsoft Entra ID).

  6. Active Directory localise le compte d’ordinateur et retourne un ticket Kerberos au navigateur chiffré avec le secret du compte d’ordinateur.

  7. Le navigateur transmet le ticket Kerberos qu'il a acquis depuis Active Directory vers Microsoft Entra ID.

  8. Microsoft Entra ID déchiffre le ticket Kerberos, qui inclut l'identité de l'utilisateur connecté à l'appareil d'entreprise, à l'aide de la clé précédemment partagée.

  9. Après l’évaluation, l’ID Microsoft Entra retourne un jeton à l’application ou demande à l’utilisateur d’effectuer des preuves supplémentaires, telles que l’authentification multifacteur.

  10. Si l’utilisateur parvient à se connecter, il peut accéder à l’application.

Le schéma suivant illustre tous les composants et les étapes impliquées dans ce processus.

Authentification unique transparente : flux des applications web

La SSO sans friction est opportuniste. Cela signifie qu’en cas d’échec, l’expérience de connexion revient à son comportement normal. Dans ce cas, l’utilisateur doit entrer son mot de passe pour se connecter.

Comment fonctionne la connexion sur un client natif avec l’authentification unique transparente ?

Le flux de connexion sur un client natif est le suivant :

  1. Un utilisateur tente d’accéder à une application native (par exemple, le client Outlook) à partir d’un appareil d’entreprise joint à un domaine du réseau de l’entreprise.
  2. Si l’utilisateur n’est pas déjà connecté, l’application native récupère le nom d’utilisateur de l’utilisateur à partir de la session Windows de l’appareil.
  3. L'application envoie le nom d'utilisateur à Microsoft Entra ID et récupère le point de terminaison WS-Trust MEX de votre locataire. Ce point de terminaison WS-Trust est utilisé exclusivement par la fonctionnalité d’authentification unique transparente et n’est pas une implémentation générale du protocole WS-Trust sur l’ID Microsoft Entra.
  4. L’application interroge ensuite le point de terminaison WS-Trust MEX pour savoir si le point de terminaison d’authentification intégrée est disponible. Le point de terminaison d'authentification intégré est exclusivement utilisé par la fonctionnalité SSO transparente.
  5. Si l’étape 4 réussit, un challenge Kerberos est émis.
  6. Si l'application parvient à récupérer le ticket Kerberos, elle le transmet au point de terminaison d'authentification intégré Microsoft Entra.
  7. Microsoft Entra ID déchiffre le ticket Kerberos et le valide.
  8. Microsoft Entra ID connecte l'utilisateur et émet un jeton SAML à l'application.
  9. L’application soumet ensuite le jeton SAML au point de terminaison du jeton Microsoft Entra ID OAuth2.
  10. Microsoft Entra ID valide le jeton SAML et émet un jeton d’accès, un jeton d’actualisation pour la ressource spécifiée et un jeton d’ID à l’application.
  11. L’utilisateur peut alors accéder aux ressources de l’application.

Le schéma suivant illustre tous les composants et les étapes impliquées dans ce processus.

Authentification unique transparente : flux des applications natives

Étapes suivantes

  • Last updated on