Résoudre des problèmes d’authentification unique transparente Microsoft Entra
Cet article fournit des informations sur la résolution des problèmes courants liés à l’authentification unique transparente (Seamless SSO) Microsoft Entra.
Problèmes connus
- Dans certains cas, l’activation de l’authentification unique transparente peut prendre jusqu’à 30 minutes.
- Si vous désactivez et réactivez l’authentification unique transparente sur votre client, les utilisateurs ne recevront pas l’expérience d’authentification unique jusqu'à ce que leurs tickets Kerberos, généralement valides pour 10 heures, expirent.
- Si l’authentification unique transparente réussit, l’utilisateur n’a pas la possibilité de choisir l’option Maintenir la connexion.
- Les clients Win32 de Microsoft 365 (Outlook, Word, Excel et autres) avec les versions 16.0.8730.xxxx et ultérieures sont pris en charge à l’aide d’un flux non interactif. Les autres versions ne sont pas prises en charge ; dans ces versions, les utilisateurs entrent leur nom d’utilisateur, mais pas les mots de passe, pour se connecter. En ce qui concerne OneDrive, vous devez activer la fonctionnalité de configuration silencieuse OneDrive pour une utilisation de l’authentification sans assistance.
- L’authentification unique transparente ne fonctionne pas en mode Navigation privée sur Firefox.
- L’authentification unique transparente ne fonctionne pas sur Internet Explorer quand le mode protégé amélioré est activé.
- Microsoft Edge (hérité) n’est plus pris en charge.
- L’authentification unique transparente ne fonctionne pas sur les navigateurs mobiles iOS et Android.
- Si un utilisateur fait partie de trop de groupes dans Active Directory, son ticket Kerberos sera probablement trop volumineux pour être traité, ce qui provoquera l’échec de l’authentification unique transparente. Les requêtes HTTPS Microsoft Entra peuvent comporter des en-têtes dont la taille ne dépasse pas 50 Ko ; les tickets Kerberos doivent être plus petits pour laisser la place à d’autres artefacts Microsoft Entra (en général, 2 à 5 Ko), comme les cookies. Nous vous recommandons de réduire les appartenances de l’utilisateur à des groupes, puis de réessayer.
- Si vous synchronisez 30 forêts Active Directory ou plus, vous ne pouvez pas activer l’authentification unique transparente via Microsoft Entra Connect. En guise de solution de contournement, vous pouvez activer manuellement la fonctionnalité pour votre locataire.
- L’ajout de l’URL du service Microsoft Entra (
https://autologon.microsoftazuread-sso.com) à la zone Sites de confiance, plutôt qu’à la zone Intranet local, empêche les utilisateurs de se connecter. - L’authentification unique transparente prend en charge les types de chiffrement AES256_HMAC_SHA1, AES128_HMAC_SHA1 et RC4_HMAC_MD5 pour Kerberos. Il est recommandé de définir le type de chiffrement du compte AzureADSSOAcc$ sur AES256_HMAC_SHA1 ou l’un des types AES plutôt que sur RC4 pour plus de sécurité. Le type de chiffrement est stocké dans l’attribut msDS-SupportedEncryptionTypes du compte de votre annuaire Active Directory. Si le type de chiffrement du compte AzureADSSOAcc$ a la valeur RC4_HMAC_MD5 et que vous voulez le remplacer par l’un des types de chiffrement AES, veillez d’abord à remplacer la clé de déchiffrement Kerberos du compte AzureADSSOAcc$, comme expliqué dans les questions fréquentes (FAQ), sous la question concernée, sans quoi l’authentification unique transparente ne se produira pas.
- Si vous avez plusieurs forêts dotées d’une approbation de forêt, l’activation de l’authentification unique (SSO) dans l’une de ces forêts active l’authentification unique dans toutes les forêts approuvées. Si vous activez l’authentification unique (SSO) dans une forêt où l’authentification unique est déjà activée, vous obtenez une erreur indiquant que l’authentification unique est déjà activée dans la forêt.
- La stratégie qui active l’authentification unique fluide a une limite de 25 600 caractères. Cette limite concerne tout ce qui est inclus dans la stratégie, notamment les noms de forêt sur lesquels vous souhaitez activer l’authentification unique fluide. Vous pouvez atteindre la limite de caractères si vous disposez d’un grand nombre de forêts dans votre environnement. Si vos forêts ont une relation de confiance entre elles, il suffit d’activer l’authentification unique fluide sur l’une des forêts. Imaginons par exemple contoso.com et fabrikam.com qui ont une relation de confiance. Vous pouvez activer l’authentification unique fluide uniquement sur contoso.com et elle est appliquée également sur fabrikam.com. De cette façon, vous pouvez réduire le nombre de forêts activées dans la stratégie et éviter d’atteindre la limite de caractères de la stratégie.
Vérifier l’état de la fonctionnalité
Assurez-vous que la fonctionnalité Authentification unique transparente est toujours activée sur votre client. Vous pouvez vérifier l’état en accédant au volet Gestion> hybride des identités>Microsoft Entra Connect>Synchronisation de connexion dans le [centre d’administration Microsoft Entra](https://portal.azure.com/).
Cliquez pour afficher toutes les forêts Active Directory dans lesquelles l’authentification unique transparente est activée.
Raisons des échecs de connexion dans le centre d’administration Microsoft Entra (licence Premium requise)
Si votre tenant dispose d’une licence Microsoft Entra ID P1 ou P2 associée, vous pouvez également consulter le rapport d’activité de connexion dans Microsoft Entra ID dans le Centre d’administration Microsoft Entra.
Accédez à Identité>Surveillance et intégrité>Connexions dans le [centre d’administration Microsoft Entra](https://portal.azure.com/), puis sélectionnez l’activité de connexion d’un utilisateur spécifique. Recherchez le champ Code d’erreur de connexion. Notez la valeur de ce champ et cherchez dans le tableau suivant la raison de l’échec et la solution à appliquer :
| Code d’erreur de connexion | Raison de l’échec de connexion | Résolution |
|---|---|---|
| 81001 | Le ticket Kerberos de l’utilisateur est trop volumineux. | Réduisez les appartenances à des groupes de l’utilisateur, puis réessayez. |
| 81002 | Impossible de valider le ticket Kerberos de l’utilisateur. | Consultez la liste de contrôle pour la résolution des problèmes. |
| 81003 | Impossible de valider le ticket Kerberos de l’utilisateur. | Consultez la liste de contrôle pour la résolution des problèmes. |
| 81004 | Échec de la tentative d’authentification Kerberos. | Consultez la liste de contrôle pour la résolution des problèmes. |
| 81008 | Impossible de valider le ticket Kerberos de l’utilisateur. | Consultez la liste de contrôle pour la résolution des problèmes. |
| 81009 | Impossible de valider le ticket Kerberos de l’utilisateur. | Consultez la liste de contrôle pour la résolution des problèmes. |
| 81010 | L’authentification unique transparente a échoué, car le ticket Kerberos de l’utilisateur est arrivé à expiration ou n’est pas valide. | L’utilisateur doit se connecter à partir d’un appareil joint à un domaine au sein de votre réseau d’entreprise. |
| 81011 | Impossible de trouver l’objet utilisateur à partir des informations contenues dans le ticket Kerberos de l’utilisateur. | Utilisez Microsoft Entra Connect pour synchroniser les informations de l’utilisateur dans Microsoft Entra ID. |
| 81012 | L’utilisateur qui tente de se connecter à Microsoft Entra ID est différent de l’utilisateur connecté à l’appareil. | L'utilisateur doit se connecter à partir d’un autre appareil. |
| 81013 | Impossible de trouver l’objet utilisateur à partir des informations contenues dans le ticket Kerberos de l’utilisateur. | Utilisez Microsoft Entra Connect pour synchroniser les informations de l’utilisateur dans Microsoft Entra ID. |
Liste de contrôle pour la résolution des problèmes
Utilisez la liste de contrôle suivante pour résoudre les problèmes d’authentification unique transparente :
- Vérifiez que la fonctionnalité d’authentification unique transparente est activée dans Microsoft Entra Connect. Si vous ne pouvez pas activer la fonctionnalité (par exemple, en raison d’un port bloqué), vérifiez que toutes les conditions préalables sont bien respectées.
- Si vous avez activé la jointure Microsoft Entra et l’authentification unique transparente sur votre tenant, vérifiez que le problème ne provient pas de la jointure Microsoft Entra. L’authentification unique à partir d’une jonction Microsoft Entra est prioritaire sur l’authentification unique fluide si l’appareil est inscrit auprès de Microsoft Entra ID et est joint au domaine. Avec l’authentification unique à partir de la jointure Microsoft Entra, l’utilisateur voit une vignette de connexion qui indique « Connecté à Windows ».
- Vérifiez que l’URL Microsoft Entra (
https://autologon.microsoftazuread-sso.com) fait partie des paramètres de la zone intranet de l’utilisateur. - Vérifiez que l’appareil d’entreprise est joint au domaine Active Directory. L’appareil n’a pas besoin d’être joint à Microsoft Entra pour que l’authentification unique transparente soit opérationnelle.
- Assurez-vous que l'utilisateur est connecté à l'appareil via un compte de domaine Active Directory.
- Vérifiez que le compte de l’utilisateur provient d’une forêt Active Directory dans laquelle l’authentification unique (SSO) transparente a été configurée.
- Vérifiez que l’appareil est connecté au réseau d’entreprise.
- Vérifiez que l’heure de l’appareil est synchronisée à la fois avec celle d’Active Directory et celle du contrôleur de domaine, et qu'elles ne comptent pas plus de cinq minutes d’écart.
- Vérifiez que le compte d’ordinateur
AZUREADSSOACCest présent et activé dans chaque forêt AD pour laquelle l’authentification unique fluide doit être activée. Si le compte d’ordinateur a été supprimé ou est manquant, vous pouvez utiliser des applets de commande PowerShell pour les recréer. - Affichez la liste des tickets Kerberos existants sur l’appareil à l’aide de la commande
klistdans une invite de commandes. Vérifiez que les tickets émis pour le compte d’ordinateurAZUREADSSOACCy figurent. En règle générale, la durée de validité des tickets Kerberos des utilisateurs est de 10 heures. L'instance Active Directory est peut-être paramétrée différemment. - Si vous avez désactivé puis réactivé l’authentification unique transparente sur votre locataire, les utilisateurs ne recevront pas l’expérience d’authentification unique tant que leurs tickets Kerberos n’auront pas expiré.
- Videz les tickets Kerberos existants de l’appareil à l’aide de la commande
klist purge, puis réessayez. - Pour déterminer si des problèmes liés à JavaScript existent, passez en revue les journaux d’activité de console du navigateur (sous Outils de développement).
- Examinez les journaux d’activité des contrôleurs de domaine.
Journaux d’activité des contrôleurs de domaine
Si vous activez l’audit des réussites sur votre contrôleur de domaine, chaque fois qu’un utilisateur se connecte à l’aide de l’authentification unique transparente, une entrée de sécurité est enregistrée dans le journal des événements. Vous trouverez ces événements de sécurité au moyen de la requête suivante. (Recherchez l'événement 4769 associé au compte d'ordinateur AzureADSSOAcc$ .)
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[EventData[Data[@Name='ServiceName'] and (Data='AZUREADSSOACC$')]]</Select>
</Query>
</QueryList>
Réinitialisation manuelle de la fonctionnalité
Si vous n’avez pas réussi à résoudre le problème, vous pouvez réinitialiser manuellement la fonctionnalité pour votre locataire. Procédez comme suit sur le serveur sur site où vous exécutez Microsoft Entra Connect.
Étape 1 : Importer le module PowerShell Authentification unique (SSO) transparente
- Commencez par télécharger et installer Azure AD PowerShell.
- Accédez au dossier
%programfiles%\Microsoft Azure Active Directory Connect. - Importez le module PowerShell Authentification unique (SSO) transparente à l’aide de la commande suivante :
Import-Module .\AzureADSSO.psd1.
Étape 2 : Obtenir la liste des forêts Azure Directory dans lesquelles l’authentification unique (SSO) transparente a été activée
- Exécutez PowerShell ISE en tant qu’administrateur. Dans PowerShell, appelez
New-AzureADSSOAuthenticationContext. Quand vous y êtes invité, entrez les informations d’identification d’Administrateur d’identité hybride de votre locataire. - Appelez
Get-AzureADSSOStatus. Cette commande vous fournit la liste des forêts Azure Directory (examinez la liste « Domaines ») dans lesquelles cette fonctionnalité a été activée.
Étape 3 : Désactiver l’authentification unique (Seamless SSO) pour chaque forêt Azure Directory dans laquelle vous avez configuré la fonctionnalité
Appelez
$creds = Get-Credential. Quand vous y êtes invité, entrez les informations d’identification d’administrateur de domaine pour la forêt Azure Directory souhaitée.Notes
Le nom d’utilisateur des informations d’identification de l’administrateur de domaine doit être entré au format de nom de compte SAM (contoso\johndoe ou contoso.com\johndoe). Nous utilisons la partie domaine du nom d’utilisateur pour localiser le contrôleur de domaine de l’administrateur de domaine à l’aide de DNS.
Notes
Le compte administrateur de domaine utilisé ne doit pas être membre du groupe Utilisateurs protégés. Sinon, l’opération échoue.
Appelez
Disable-AzureADSSOForest -OnPremCredentials $creds. Cette commande supprime le compte d’ordinateurAZUREADSSOACCdu contrôleur de domaine sur site pour cette forêt Azure Directory spécifique.Remarque
Si, pour une raison quelconque, vous ne pouvez pas accéder à votre AD localement, vous pouvez ignorer les étapes 3.1 et 3.2, et appeler
Disable-AzureADSSOForest -DomainFqdn <Domain name from the output list in step 2>à la place.Répétez les étapes précédentes pour chaque forêt Azure Directory dans laquelle vous avez configuré la fonctionnalité.
Étape 4 : Activer l’authentification unique (SSO) transparente pour chaque forêt Azure Directory
Appelez
Enable-AzureADSSOForest. Quand vous y êtes invité, entrez les informations d’identification d’administrateur de domaine pour la forêt Azure Directory souhaitée.Notes
Le nom d’utilisateur des informations d’identification de l’administrateur de domaine doit être entré au format de nom de compte SAM (contoso\johndoe ou contoso.com\johndoe). Nous utilisons la partie domaine du nom d’utilisateur pour localiser le contrôleur de domaine de l’administrateur de domaine à l’aide de DNS.
Notes
Le compte administrateur de domaine utilisé ne doit pas être membre du groupe Utilisateurs protégés. Sinon, l’opération échoue.
Répétez l'étape précédente pour chaque forêt Azure Directory dans laquelle vous souhaitez configurer la fonctionnalité.
Étape 5 : activer la fonctionnalité pour votre tenant
Pour activer la fonctionnalité pour votre locataire, appelez Enable-AzureADSSO -Enable $true.