Résoudre les problèmes AD FS dans Microsoft Entra ID et Office 365

2025-01-15

Cet article décrit la résolution des problèmes d’authentification pour les utilisateurs fédérés dans Microsoft Entra ID ou Office 365.

Numéro de base de connaissances d’origine : 3079872

Symptômes

Les utilisateurs fédérés ne peuvent pas se connecter à Office 365 ou Microsoft Azure, même si les utilisateurs cloud gérés uniquement qui ont un suffixe UPN domainxx.onmicrosoft.com peuvent se connecter sans problème.
La redirection vers les Services de fédération Active Directory (AD FS) ou STS ne se produit pas pour un utilisateur fédéré. Ou une erreur « Page ne peut pas être affichée » est déclenchée.
Vous recevez un avertissement lié au certificat sur un navigateur lorsque vous essayez de vous authentifier auprès d’AD FS. Ce qui indique que la validation de certificat échoue ou que le certificat n’est pas approuvé.
Erreur ou erreurs « Méthode d’authentification inconnue » indiquant qu’elle AuthnContext n’est pas prise en charge. En outre, les erreurs au niveau AD FS ou STS lorsque vous êtes redirigé à partir d’Office 365.
AD FS lève une erreur « Accès refusé ».
AD FS génère une erreur indiquant qu’il existe un problème d’accès au site ; qui inclut un numéro d’ID de référence.
L’utilisateur est invité à plusieurs reprises à entrer des informations d’identification au niveau AD FS.
Les utilisateurs fédérés ne peuvent pas s’authentifier à partir d’un réseau externe ou lorsqu’ils utilisent une application qui prend l’itinéraire réseau externe (Outlook, par exemple).
Les utilisateurs fédérés ne peuvent pas se connecter une fois qu’un certificat de signature de jeton est modifié sur AD FS.
Une erreur « Désolé, mais nous avons des difficultés à vous connecter » est déclenchée lorsqu’un utilisateur fédéré se connecte à Office 365 dans Microsoft Azure. Cette erreur inclut des codes d’erreur tels que 8004786C, 80041034, 80041317, 80043431, 80048163, 80045C06, 8004789A ou une requête BAD.

Résolution de problèmes de flux de travail

Accédez à Microsoft Office Famille, puis entrez le nom d'utilisateur fédéré (quelqu'un@exemple.com). Après avoir appuyé sur Tab pour supprimer le focus de la zone de connexion, vérifiez si l’état de la page passe à redirection , puis vous êtes redirigé vers votre service de fédération Active Directory (AD FS) pour la connexion.

Note

Les modules Azure AD et MSOnline PowerShell seront dépréciés à partir du 30 mars 2024. Pour en savoir plus, lisez la mise à jour sur l'obsolescence. Passé cette date, la prise en charge de ces modules est limitée à une assistance de migration vers le SDK et les correctifs de sécurité Microsoft Graph PowerShell. Les modules déconseillés continueront de fonctionner jusqu’au 30 mars 2025.

Nous vous recommandons de migrer vers Microsoft Graph PowerShell pour interagir avec Microsoft Entra ID (anciennement Azure AD). Pour explorer les questions courantes sur la migration, reportez-vous au FAQ sur la migration. Remarque : Les versions 1.0.x de MSOnline peuvent connaître une interruption après le 30 juin 2024.

Lorsque la redirection se produit, la page suivante s’affiche :
1. Si aucune redirection ne se produit et que vous êtes invité à entrer un mot de passe sur la même page, ce qui signifie que Microsoft Entra ID ou Office 365 ne reconnaît pas l’utilisateur ou le domaine de l’utilisateur à fédérer. Pour vérifier s’il existe une approbation de fédération entre Microsoft Entra ID ou Office 365 et votre serveur AD FS, exécutez l’applet Get-MgDomain de commande et vérifiez AuthenticationType.
2. Si la redirection se produit mais que vous n’êtes pas redirigé vers votre serveur AD FS pour vous connecter, vérifiez si le nom du service AD FS est résolu à la bonne adresse IP et s’il peut se connecter à cette adresse IP sur le port TCP 443.
  
  Si le domaine est affiché en tant que fédéré, obtenez des informations sur l’approbation de fédération en exécutant les commandes suivantes :
```
Get-MgDomainFederationConfiguration -DomainId <domain_id>
```
  Note
  
  < > domain_id est un espace réservé pour le nom de votre domaine. Par exemple, contoso.com.
  
  Vérifiez l’URI, l’URL et le certificat du partenaire de fédération configuré par Office 365 ou l’ID Microsoft Entra.
Une fois que vous êtes redirigé vers AD FS, le navigateur peut lever une erreur liée à l’approbation de certificat, et pour certains clients et appareils, il peut ne pas vous permettre d’établir une session SSL (Secure Sockets Layer) avec AD FS. Pour résoudre ce problème, effectuez les étapes suivantes :
1. Assurez-vous que le certificat de communication du service AD FS présenté au client est le même que celui configuré sur AD FS.
  
  Dans l’idéal, le certificat de communication du service AD FS doit être identique au certificat SSL présenté au client lorsqu’il tente d’établir un tunnel SSL avec le service AD FS.
  
  Dans AD FS 2.0 :
  - Lier le certificat au premier site par défaut IIS>.
  - Utilisez le module AD FS pour ajouter le même certificat que le certificat de communication de service.
  Dans AD FS 2012 R2 :
  - Utilisez le composant logiciel enfichable AD FS ou la commande Add-adfscertificate pour ajouter un certificat de communication de service.
  - Utilisez la Set-adfssslcertificate commande pour définir le même certificat pour la liaison SSL.
2. Vérifiez que le certificat de communication du service AD FS est approuvé par le client.
3. Si les clients non compatibles SNI tentent d’établir une session SSL avec AD FS ou WAP 2-12 R2, la tentative peut échouer. Dans ce cas, envisagez d’ajouter une entrée de secours sur les serveurs AD FS ou WAP pour prendre en charge les clients non-SNI. Pour plus d’informations, consultez Comment prendre en charge les clients non compatibles SNI avec le proxy d’application web et AD FS 2012 R2.

Vous pouvez rencontrer une erreur « Méthode d’authentification inconnue » ou des erreurs indiquant qu’elle AuthnContext n’est pas prise en charge au niveau AD FS ou STS lorsque vous êtes redirigé à partir d’Office 365. Il est le plus courant lors de la redirection vers AD FS ou STS à l’aide d’un paramètre qui applique une méthode d’authentification. Pour appliquer une méthode d’authentification, utilisez l’une des méthodes suivantes :

Pour WS-Federation, utilisez une chaîne de requête WAUTH pour forcer une méthode d’authentification préférée.

Pour SAML2.0, utilisez les éléments suivants :

<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>

Lorsque la méthode d’authentification appliquée est envoyée avec une valeur incorrecte ou si cette méthode d’authentification n’est pas prise en charge sur AD FS ou STS, vous recevez un message d’erreur avant d’être authentifié.

Le tableau suivant présente les URI de type d’authentification reconnus par AD FS pour l’authentification passive WS-Federation.

Méthode d’authentification souhaitée	URI wauth
Authentification par nom d’utilisateur et mot de passe	urn:oasis:names:tc:SAML:1.0:am:password
Authentification du client SSL	urn:ietf:rfc:2246
Authentification intégrée à Windows	urn:federation:authentication:windows

Classes de contexte d’authentification SAML prises en charge

Méthode d'authentification	URI de la classe de contexte d’authentification
Nom d'utilisateur et mot de passe	urn:oasis:names:tc:SAML:2.0:ac:classes:Password
Transport protégé par mot de passe	urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Client de sécurité de la couche de transport (TLS)	urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
Certificat X.509	urn:oasis:names:tc:SAML:2.0:ac:classes:X509
Authentification Windows intégrée	urn:federation:authentication:windows
Kerberos	urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos

Pour vous assurer que la méthode d’authentification est prise en charge au niveau AD FS, vérifiez ce qui suit.

AD FS 2.0

Sous /adfs/ls/web.config, vérifiez que l’entrée pour le type d’authentification est présente.

<microsoft.identityServer.web>
<localAuthenticationTypes>
 < add name="Forms" page="FormsSignIn.aspx" />  
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>

AD FS 2.0 : Modification du type d’authentification local

AD FS 2012 R2

Sous Gestion AD FS, sélectionnez Stratégies d’authentification dans le composant logiciel enfichable AD FS.
Dans la section Authentification principale, sélectionnez Modifier à côté de Paramètres globaux. Vous pouvez également cliquer avec le bouton droit sur Stratégies d’authentification, puis sélectionner Modifier l’authentification principale globale. Ou, dans le volet Actions, sélectionnez Modifier l’authentification principale globale.
Dans la fenêtre Modifier la stratégie d’authentification globale, sous l’onglet Principal , vous pouvez configurer les paramètres dans le cadre de la stratégie d’authentification globale. Par exemple, pour l’authentification principale, vous pouvez sélectionner les méthodes d’authentification disponibles sous Extranet et Intranet.

Vérifiez que la case à cocher de la méthode d’authentification requise est activée.

Si vous accédez à votre ad FS et entrez vos informations d’identification, mais que vous ne pouvez pas être authentifié, recherchez les problèmes suivants.
1. Problème de réplication Active Directory
  
  Si la réplication AD est interrompue, les modifications apportées à l’utilisateur ou au groupe peuvent ne pas être synchronisées entre les contrôleurs de domaine. Entre les contrôleurs de domaine, il peut y avoir une incompatibilité de mot de passe, d'UPN, d'appartenance au groupe ou d'adresse proxy, ce qui affecte la réponse du service AD FS en matière d'authentification et de revendications. Vous devez commencer à examiner les contrôleurs de domaine sur le même site que AD FS. L’exécution d’une ou d’une repadmin /showrepsDCdiag /v commande doit révéler s’il existe un problème sur les contrôleurs de domaine que AD FS est le plus susceptible de contacter.
  
  Vous pouvez également collecter un résumé de réplication AD pour vous assurer que les modifications AD sont répliquées correctement sur tous les contrôleurs de domaine. La repadmin /showrepl * /csv > showrepl.csv sortie est utile pour vérifier l’état de réplication. Pour plus d’informations, consultez Résolution des problèmes de réplication Active Directory.
2. Compte verrouillé ou désactivé dans Active Directory
  
  Lorsqu’un utilisateur final est authentifié via AD FS, il ne reçoit pas de message d’erreur indiquant que le compte est verrouillé ou désactivé. À partir de l’audit AD FS et ouverture de session, vous devez être en mesure de déterminer si l’authentification a échoué en raison d’un mot de passe incorrect, si le compte est désactivé ou verrouillé, etc.
  
  Pour activer l’audit AD FS et l’audit d'ouverture de session sur les serveurs AD FS, procédez comme suit :
  1. Utilisez la stratégie locale ou de domaine pour activer la réussite et l’échec des stratégies suivantes :
    - Auditer l’événement d’ouverture de session, situé dans Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy
    - Auditer l’accès aux objets, situé dans Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy
  2. Désactivez la stratégie suivante :
    
    Audit : forcer les paramètres de sous-catégorie de la stratégie d’audit (Windows Vista ou version ultérieure) à prendre le pas sur les paramètres de catégorie de la stratégie d’audit
    
    Cette stratégie se trouve dans Computer configuration\Windows Settings\Security setting\Local Policy\Security Option.
    
    Si vous souhaitez le configurer à l’aide de l’audit avancé, consultez Configuration des ordinateurs pour la résolution des problèmes AD FS 2.0.
  3. Configurez AD FS pour l’audit :
    1. Ouvrez le composant enfichable de gestion AD FS 2.0.
    2. Dans le volet Actions, sélectionnez Modifier les propriétés du service de fédération.
    3. Dans la boîte de dialogue Propriétés du service de fédération, sélectionnez l’onglet Événements.
    4. Cochez les cases Audits des succès et Audits des échecs.
    5. Exécutez GPupdate /force sur le serveur.
3. Le nom du principal du service (SPN) est inscrit de manière incorrecte
  
  Il peut y avoir des SPN en double ou un SPN inscrit sous un compte autre que le compte de service AD FS. Pour une configuration de ferme de serveurs AD FS, assurez-vous que SPN HOST/AD FS servicename est ajouté sous le compte de service qui exécute le service AD FS. Pour une configuration autonome AD FS, où le service s’exécute sous service réseau, le SPN doit se trouver sous le compte d’ordinateur serveur qui héberge AD FS.
  
  Assurez-vous qu’il n’existe pas de spN dupliqués pour le service AD FS, car cela peut entraîner des échecs d’authentification intermittents avec AD FS. Pour répertorier les SPN, exécutez SETSPN -L <ServiceAccount>.
  
  Exécutez SETSPN -A HOST/AD FSservicename ServiceAccount pour ajouter le SPN.
  
  Exécutez SETSPN -X -F pour rechercher les SPN dupliqués.
4. UPN dupliqués dans Active Directory
  
  Un utilisateur peut être en mesure de s’authentifier via AD FS lorsqu’il utilise SAMAccountName, mais ne peut pas s’authentifier lors de l’utilisation de l’UPN. Dans ce scénario, Active Directory peut contenir deux utilisateurs qui ont le même UPN. Il est possible de se retrouver avec deux utilisateurs qui ont le même UPN lorsque les utilisateurs sont ajoutés et modifiés par le biais de scripts (ADSIedit, par exemple).
  
  Lorsque l’UPN est utilisé pour l’authentification dans ce scénario, l’utilisateur est authentifié auprès de l’utilisateur en double. Par conséquent, les informations d’identification fournies ne sont pas validées.
  
  Vous pouvez utiliser des requêtes comme celles-ci pour vérifier s’il existe plusieurs objets dans AD qui ont les mêmes valeurs pour un attribut :
```
Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN
```
  Assurez-vous que l'UPN de l'utilisateur en double est renommé, afin que la demande d'authentification avec l'UPN soit validée contre les objets corrects.
5. Dans un scénario, où vous utilisez votre adresse e-mail comme ID de connexion dans Office 365 et que vous entrez la même adresse e-mail lorsque vous êtes redirigé vers AD FS pour l’authentification, l’authentification peut échouer avec une erreur « NO_SUCH_USER » dans les journaux d’audit. Pour permettre à AD FS de rechercher un utilisateur pour l’authentification à l’aide d’un attribut autre que UPN ou SAMaccountname, vous devez configurer AD FS pour prendre en charge un autre ID de connexion. Pour plus d’informations, consultez Configuration d’un ID secondaire de connexion.
  
  Sur AD FS 2012 R2
  1. Installez update 2919355.
  2. Mettez à jour la configuration AD FS en exécutant l’applet de commande PowerShell suivante sur n’importe lequel des serveurs de fédération de votre batterie de serveurs (si vous disposez d’une batterie de serveurs WID, vous devez exécuter cette commande sur le serveur AD FS principal de votre batterie de serveurs) :
```
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID <attribute> -LookupForests <forest domain>
```
    Note
    
    AlternateLoginID est le nom LDAP de l’attribut que vous souhaitez utiliser pour la connexion. LookupForests est la liste des entrées DNS de forêts auxquelles appartiennent vos utilisateurs.
    
    Pour activer la fonctionnalité d’ID de connexion secondaire, vous devez configurer les paramètres AlternateLoginID et LookupForests avec une valeur non null valide.
6. Le compte de service AD FS n'a pas d'accès en lecture au jeton AD FS qui contient la clé privée du certificat. Pour ajouter cette autorisation, procédez comme suit :
  1. Lorsque vous ajoutez un nouveau certificat de signature de jeton, vous recevez l’avertissement suivant :
    
    Vérifiez que la clé privée du certificat choisi est accessible au compte de service de ce service de fédération sur chaque serveur de la batterie de serveurs.
  2. Sélectionnez Démarrer, sélectionnez Exécuter, tapez mmc.exe, puis appuyez sur Entrée.
  3. Sélectionnez Fichier, puis sélectionnez Ajouter/Supprimer le composant logiciel enfichable.
  4. Double-cliquez sur Certificats.
  5. Sélectionnez le compte d’ordinateur en question, puis sélectionnez Suivant.
  6. Sélectionnez Ordinateur local, puis sélectionnez Terminer.
  7. Développez Certificats (ordinateur local), développez Persona l, puis sélectionnez Certificats.
  8. Cliquez avec le bouton droit sur votre nouveau certificat de signature de jeton, sélectionnez Toutes les tâches, puis sélectionnez Gérer les clés privées.
  9. Ajoutez l’accès en lecture pour votre compte de service AD FS 2.0, puis sélectionnez OK.
  10. Fermez la MMC Certificats.
7. L’option Protection étendue pour l’authentification Windows est activée pour le répertoire virtuel AD FS ou LS. Cela peut entraîner des problèmes avec des navigateurs spécifiques. Parfois, vous pouvez voir AD FS demander à plusieurs reprises des informations d’identification et il peut être lié au paramètre de protection étendu activé pour l’authentification Windows pour l’application AD FS ou LS dans IIS.
  
  Lorsque la protection étendue pour l’authentification est activée, les demandes d’authentification sont liées aux noms de principal de service (SPN) du serveur auquel le client tente de se connecter et au canal TLS (Transport Layer Security) externe sur lequel l’authentification Windows intégrée se produit. La protection étendue améliore la fonctionnalité d’authentification Windows existante pour atténuer les relais d’authentification ou les attaques « man in the middle ». Toutefois, certains navigateurs ne fonctionnent pas avec le paramètre de protection étendue ; Au lieu de cela, ils demandent à plusieurs reprises des informations d’identification, puis refusent l’accès. La désactivation de la protection étendue aide dans ce scénario.
  
  Pour plus d’informations, consultez AD FS 2.0 : Sollicité en continu pour les informations d’identification pendant l'utilisation du débogueur Web Fiddler.
  
  Pour AD FS 2012 R2
  
  Exécutez l’applet de commande suivante pour désactiver la protection étendue :
```
Set-ADFSProperties -ExtendedProtectionTokenCheck None
```
8. Les règles d’autorisation de délivrance dans la confiance RP peuvent refuser l'accès aux utilisateurs. Sur l’approbation de partie de confiance AD FS, vous pouvez configurer les règles d’autorisation d’émission qui contrôlent si un utilisateur authentifié doit être émis un jeton pour une partie de confiance. Les administrateurs peuvent utiliser les revendications émises pour décider s’il faut refuser l’accès à un utilisateur membre d’un groupe qui est traité comme revendication.
  
  Si certains utilisateurs fédérés ne peuvent pas s’authentifier via AD FS, vous pouvez vérifier les règles d’autorisation d’émission pour le rp Office 365 et voir si la règle Autoriser l’accès à tous les utilisateurs est configurée.
  
  Si cette règle n’est pas configurée, parcourez les règles d’autorisation personnalisées pour vérifier si la condition dans cette règle évalue « true » pour l’utilisateur concerné. Pour plus d’informations, consultez les ressources suivantes :
  Si vous pouvez vous authentifier à partir d’un intranet lorsque vous accédez directement au serveur AD FS, mais que vous ne pouvez pas vous authentifier lorsque vous accédez à AD FS via un proxy AD FS, vérifiez les problèmes suivants :
  - Problème de synchronisation de temps sur le serveur AD FS et le proxy AD FS
    
    Assurez-vous que l’heure sur le serveur AD FS et l’heure sur le proxy sont synchronisées. Lorsque l’heure sur le serveur AD FS est désactivée de plus de cinq minutes à partir de l’heure sur les contrôleurs de domaine, les échecs d’authentification se produisent. Lorsque l’heure sur le proxy AD FS n’est pas synchronisée avec AD FS, la confiance envers le proxy est affectée et compromise. Par conséquent, une demande qui transite par le proxy AD FS échoue.
  - Vérifiez si l’approbation du proxy AD FS avec le service AD FS fonctionne correctement. Réexécutez la configuration du proxy si vous pensez que l’approbation du proxy est interrompue.
Après que votre AD FS émet un jeton, Microsoft Entra ID ou Office 365 génère une erreur. Dans ce cas, recherchez les problèmes suivants :
- Les revendications faites par AD FS dans le jeton doivent correspondre aux attributs respectifs de l'utilisateur dans Microsoft Entra ID. Dans le jeton de l’ID Microsoft Entra ou d’Office 365, les revendications suivantes sont requises.
  
  WSFED :
  UPN : la valeur de cette revendication doit correspondre à l'UPN des utilisateurs dans Microsoft Entra ID.
  ImmutableID : la valeur de cette revendication doit correspondre à sourceAnchor ou ImmutableID de l'utilisateur dans Microsoft Entra ID.
  
  Pour obtenir la valeur de l’attribut Utilisateur dans l’ID Microsoft Entra, exécutez la ligne de commande suivante :
```
Get-MgUser -UserId <user_id_string>
```
  SAML 2.0 :
  IDPEmail : la valeur de cette revendication doit correspondre au nom d'utilisateur principal des utilisateurs dans Microsoft Entra ID.
  NAMEID : la valeur de cette revendication doit correspondre au sourceAnchor ou ImmutableID de l'utilisateur dans Microsoft Entra ID.
  
  Pour plus d’informations, consultez Utiliser un fournisseur d’identité SAML 2.0 pour l’authentification unique.
  
  Exemples :
  Ce problème peut se produire lorsque l’UPN d’un utilisateur synchronisé est modifié dans AD, mais sans mettre à jour l’annuaire en ligne. Dans ce scénario, vous pouvez corriger l’UPN de l’utilisateur dans AD (pour correspondre au nom de connexion de l’utilisateur associé) ou exécuter l’applet de commande suivante pour modifier le nom d’ouverture de session de l’utilisateur associé dans l’annuaire en ligne :
```
Update-MgUser -UserId <user_id_string> -UserPrincipalName <DomainUPN-AD>
```
  Il se peut également que vous utilisiez AADsync pour synchroniser MAIL en tant qu’UPN et EMPID comme SourceAnchor, mais les règles de revendication de partie de confiance au niveau AD FS n’ont pas été mises à jour pour envoyer MAIL en tant qu’UPN et EMPID comme ImmutableID.
- Il existe une incompatibilité de certificat de signature de jeton entre AD FS et Office 365.
  
  C’est l’un des problèmes les plus courants. AD FS utilise le certificat de signature de jeton pour signer le jeton envoyé à l’utilisateur ou à l’application. L’approbation entre AD FS et Office 365 est une approbation fédérée basée sur ce certificat de signature de jeton (par exemple, Office 365 vérifie que le jeton reçu est signé à l’aide d’un certificat de signature de jeton du fournisseur de revendications [le service AD FS] qu’il approuve).
  
  Toutefois, si le certificat de signature de jeton sur ad FS est modifié en raison de la substitution automatique du certificat ou de l’intervention d’un administrateur (après ou avant l’expiration du certificat), les détails du nouveau certificat doivent être mis à jour sur le locataire Office 365 pour le domaine fédéré. Cela peut ne pas se produire automatiquement ; elle peut nécessiter l’intervention d’un administrateur. Lorsque le certificat de signature de jeton principal sur ad FS est différent de ce qu’Office 365 sait, le jeton émis par AD FS n’est pas approuvé par Office 365. Par conséquent, l’utilisateur fédéré n’est pas autorisé à se connecter.
  
  Office 365 ou Microsoft Entra ID tente de contacter le service AD FS, en supposant que le service est accessible sur le réseau public. Nous essayons d’interroger les métadonnées de fédération AD FS à intervalles réguliers pour extraire les modifications de configuration sur AD FS, principalement les informations de certificat de signature de jeton. Si ce processus ne fonctionne pas, l’administrateur général doit recevoir un avertissement sur le portail Office 365 sur l’expiration du certificat de signature de jeton et sur les actions requises pour la mettre à jour.
  
  Vous pouvez utiliser Get-MgDomainFederationConfiguration -DomainId <domain_id> pour vider la propriété de fédération sur AD FS et Office 365. Ici, vous pouvez comparer l’empreinte numérique TokenSigningCertificate pour vérifier si la configuration du locataire Office 365 pour votre domaine fédéré est synchronisée avec AD FS. Si vous trouvez une incompatibilité dans la configuration du certificat de signature de jeton, exécutez la commande suivante pour la mettre à jour :
```
Connect-MgGraph -scopes Domain.ReadWrite.All, Directory.ReadWrite.All
$tdo= Get-MgDomainFederationConfiguration -DomainID <domain_id>
Update-MgDomainFederationConfiguration -DomainId <domain_id> -InternalDomainFederationId $tdo.Id -SigningCertificate <certificate_token>
Disconnect-MgGraph
```
  Note
  
  < > domain_id est un espace réservé pour le nom de votre domaine. Par exemple, contoso.com.
  
  Pour plus d’informations, consultez Renouveler les certificats de fédération pour Microsoft 365 et Microsoft Entra ID.
- Les règles de transformation des demandes d'émission pour Office 365 RP ne sont pas configurées correctement.
  
  Dans un scénario où vous avez plusieurs TLD (domaines de niveau supérieur), vous pouvez rencontrer des problèmes d’ouverture de session si le commutateur Supportmultipledomain n’a pas été utilisé lors de la création et de la mise à jour de l’approbation rp.
  
  Nous vous recommandons d’utiliser Entra Connect pour gérer les fédérations et les règles de revendication. Cela a généralement configuré automatiquement ADFS et Entra de manière appropriée. Pour plus d’informations, consultez La prise en charge de plusieurs domaines pour Federating avec l’ID Microsoft Entra.
- Assurez-vous que le chiffrement des jetons n’est pas utilisé par AD FS ou STS lorsqu’un jeton est émis à Microsoft Entra ID ou à Office 365.
Il existe des informations d’identification mises en cache obsolètes dans le Gestionnaire d’informations d’identification Windows.

Parfois, lors de la connexion d’une station de travail au portail (ou lors de l’utilisation d’Outlook), lorsque l’utilisateur est invité à entrer des informations d’identification, les informations d’identification peuvent être enregistrées pour la cible (service Office 365 ou AD FS) dans le Gestionnaire d’informations d’identification Windows (Control Panel\User Accounts\Credential Manager). Cela permet d’empêcher une invite d’informations d’identification pendant un certain temps, mais cela peut entraîner un problème une fois que le mot de passe de l’utilisateur a changé et que le gestionnaire d’informations d’identification n’est pas mis à jour. Dans ce scénario, les informations d’identification obsolètes sont envoyées au service AD FS et c’est pourquoi l’authentification échoue. La suppression ou la mise à jour des informations d’identification mises en cache, dans le Gestionnaire d’informations d’identification Windows peut vous aider.
Assurez-vous que l’algorithme de hachage sécurisé configuré sur la confiance de la partie utilisatrice pour Office 365 est défini sur SHA1.

Lorsque l’approbation entre STS / AD FS et Microsoft Entra ID / Office 365 utilise le protocole SAML 2.0, l’algorithme de hachage sécurisé configuré pour la signature numérique doit être SHA1.
Si aucune des causes précédentes ne s’applique à votre situation, créez un cas de support auprès de Microsoft et demandez-lui de vérifier si le compte d’utilisateur apparaît de manière cohérente sous le locataire Office 365. Pour plus d’informations, consultez Un utilisateur fédéré est invité à plusieurs reprises à entrer des informations d’identification lors de la connexion à Office 365, Azure ou Intune.

Selon le service cloud (intégré à Microsoft Entra ID) auquel vous accédez, la demande d’authentification envoyée à AD FS peut varier. Par exemple : certaines requêtes peuvent inclure des paramètres supplémentaires tels que Wauth ou Wfresh, et ces paramètres peuvent entraîner un comportement différent au niveau AD FS.

Nous vous recommandons de conserver toujours les fichiers binaires AD FS pour inclure les correctifs pour les problèmes connus. Pour plus d’informations sur les dernières mises à jour, consultez le tableau suivant.

AD FS 2.0	AD FS 2012 R2
Description du correctif cumulatif 3 pour Services de fédération Active Directory (AD FS) 2.0 La mise à jour est disponible pour résoudre plusieurs problèmes après l’installation de la mise à jour de sécurité 2843638 sur un serveur AD FS	Correctif cumulatif de décembre 2014 pour Windows RT 8.1, Windows 8.1 et Windows Server 2012 R2

Référence

Pour plus d’informations sur les applets de commande Microsoft Graph, consultez les articles suivants :

Partager via

Résoudre les problèmes AD FS dans Microsoft Entra ID et Office 365

Symptômes

Résolution de problèmes de flux de travail

Référence

Commentaires

Ressources supplémentaires