L’équipe informatique de Contoso souhaite permettre aux utilisateurs d’accéder aux ressources locales et Azure via une authentification unique (SSO). La fonctionnalité Microsoft Entra Seamless SSO fonctionne avec la synchronisation de hachage de mot de passe ou l’authentification par transmission directe (pass-through authentication).

De plus, lorsque Seamless SSO est activé, les utilisateurs n’ont presque jamais besoin de saisir leur nom d’utilisateur, et jamais leur mot de passe pour se connecter à Microsoft Entra ID. Cette fonctionnalité offre aux utilisateurs de Contoso un accès facile aux applications cloud sans nécessiter de composants locaux supplémentaires.

Scénarios pris en charge pour l’authentification par transmission directe

L’authentification par transmission directe de Microsoft Entra garantit que les services qui dépendent de Microsoft Entra ID valident toujours les mots de passe auprès d’une instance AD DS locale.

Vous pouvez configurer cette authentification via Microsoft Entra Connect, qui utilise un agent local écoutant les requêtes de validation de mot de passe externes. Cet agent peut être déployé sur un ou plusieurs serveurs pour assurer une haute disponibilité. Il n’est pas nécessaire de le déployer dans un réseau périmétrique, car toutes les communications sont uniquement sortantes.

Le serveur exécutant l’agent doit être joint au domaine AD DS où se trouvent les utilisateurs. Avant le déploiement, il est important de connaître les scénarios d’authentification pris en charge et ceux qui ne le sont pas.

Scénarios pris en charge :

• Connexions utilisateur à toutes les applications web compatibles avec Microsoft Entra ID.
• Connexions utilisateur aux applications Office prenant en charge l’authentification moderne.
• Connexions utilisateur à Microsoft Outlook via des protocoles hérités : Exchange ActiveSync, SMTP, POP, IMAP.
• Connexions utilisateur à Skype for Business avec authentification moderne (topologies en ligne et hybrides).
• Jointure de domaine Microsoft Entra pour les appareils Windows 10.
• Mots de passe d’application pour l’authentification multifacteur.

Scénarios non pris en charge :

• Connexions utilisateur aux applications Office héritées, sauf Outlook.
  Exemples : Office 2010 et Office 2013 sans authentification moderne.
• Accès au partage de calendrier et aux informations de disponibilité dans les environnements Exchange hybrides avec Office 2010.
• Connexions utilisateur à Skype for Business sans authentification moderne.
• Connexions utilisateur à Windows PowerShell version 1.0.
• Détection des identifiants compromis.
• Scénarios nécessitant Microsoft Entra Domain Services (nécessite la synchronisation de hachage de mot de passe).
• Scénarios nécessitant Microsoft Entra Connect Health (non intégré à l’authentification par transmission directe).
• Apple DEP avec l’assistant de configuration iOS : l’authentification moderne n’est pas prise en charge, donc l’inscription échoue.
  Solution alternative : utiliser l’application Intune Company Portal.

Fonctionnement de l’authentification par transmission directe

Avant le déploiement, il est utile de comprendre son fonctionnement et sa différence avec AD FS. Ce n’est pas une version simplifiée d’AD FS : les deux utilisent l’infrastructure locale, mais de manière différente.

L’authentification par transmission directe utilise un agent d’authentification, installé par Microsoft Entra Connect.

Étapes du processus :

1. L’agent s’enregistre dans le locataire Microsoft Entra ID de Microsoft 365.
2. Microsoft Entra ID lui attribue un certificat d’identité numérique unique (clé publique/privée) pour une communication sécurisée.
3. L’agent se connecte à Microsoft Entra ID via le port 443 (HTTPS) avec authentification mutuelle.
4. Microsoft Entra ID donne à l’agent accès à une file d’attente Azure Service Bus.
5. L’agent récupère les requêtes de validation de mot de passe depuis cette file.

Exemple :

Quand un utilisateur tente de se connecter à Outlook Web App :

1. Il est redirigé vers la page de connexion Microsoft Entra.
2. L’utilisateur saisit son nom d’utilisateur et mot de passe.
3. Microsoft Entra ID place ces identifiants dans une file d’attente.
4. Le service STS chiffre les identifiants avec la clé publique de l’agent.
5. L’agent récupère les identifiants chiffrés et les déchiffre avec sa clé privée.
6. L’agent valide les identifiants via AD DS local (via les API Windows).
7. AD DS retourne une réponse : succès, échec, mot de passe expiré, utilisateur verrouillé.
8. L’agent transmet la réponse à Microsoft Entra ID.
9. Microsoft Entra ID agit en conséquence : connexion, demande MFA, etc.

📘 Lecture complémentaire

• Microsoft Entra Seamless Single Sign-On
• Connexion utilisateur avec Microsoft Entra Pass-through Authentication

📍 Unité suivante : Activer la connexion Microsoft Entra pour les machines virtuelles Windows dans Azure