AD FS-problemen in Microsoft Entra-id en Office 365 oplossen

2025-01-15

In dit artikel wordt beschreven hoe u problemen met de werkstroom kunt oplossen voor verificatieproblemen voor federatieve gebruikers in Microsoft Entra ID of Office 365.

Oorspronkelijk KB-nummer: 3079872

Symptomen

Federatieve gebruikers kunnen zich niet aanmelden bij Office 365 of Microsoft Azure, ook al kunnen beheerde cloudgebruikers met een domainxx.onmicrosoft.com UPN-achtervoegsel zich zonder problemen aanmelden.
Omleiding naar Active Directory Federation Services (AD FS) of STS vindt niet plaats voor een federatieve gebruiker. Ofwel wordt er een fout 'Pagina kan niet worden weergegeven' veroorzaakt.
U ontvangt een certificaatgerelateerde waarschuwing in een browser wanneer u probeert te verifiëren met AD FS. Dit geeft aan dat certificaatvalidatie mislukt of dat het certificaat niet wordt vertrouwd.
Fout 'Onbekende verificatiemethode' of fouten die aangeven dat AuthnContext dit niet wordt ondersteund. Ook fouten op AD FS- of STS-niveau wanneer u wordt omgeleid vanuit Office 365.
AD FS genereert een fout 'Toegang is geweigerd'.
AD FS genereert een fout die aangeeft dat er een probleem is met het openen van de site; dat een referentie-id-nummer bevat.
De gebruiker wordt herhaaldelijk gevraagd om referenties op AD FS-niveau.
Federatieve gebruikers kunnen zich niet verifiëren vanuit een extern netwerk of wanneer ze een toepassing gebruiken die de route van het externe netwerk gebruikt (bijvoorbeeld Outlook).
Federatieve gebruikers kunnen zich niet aanmelden nadat een certificaat voor token-ondertekening is gewijzigd op AD FS.
De fout 'Sorry, maar er zijn problemen met aanmelden' wordt geactiveerd wanneer een federatieve gebruiker zich aanmeldt bij Office 365 in Microsoft Azure. Deze fout bevat foutcodes zoals 8004786C, 80041034, 80041317, 80043431, 80048163, 80045C06, 8004789A of BAD request.

Problemen met werkstroom oplossen

Open Microsoft Office Home en voer vervolgens de aanmeldingsnaam van de federatieve gebruiker in (iemands@voorbeeld).com). Nadat u op Tab hebt geklikt om de focus uit het aanmeldingsvak te verwijderen, controleert u of de status van de pagina verandert in Omleiden en vervolgens wordt u omgeleid naar uw Active Directory Federation Service (AD FS) voor aanmelding.

Notitie

Azure AD- en MSOnline PowerShell-modules zijn vanaf 30 maart 2024 afgeschaft. Voor meer informatie, lees de depreciatie-update. Na deze datum is ondersteuning voor deze modules beperkt tot migratieondersteuning voor Microsoft Graph PowerShell SDK en beveiligingsoplossingen. De afgeschafte modules blijven functioneren tot en met 30 maart 2025.

Het is raadzaam om te migreren naar Microsoft Graph PowerShell om te communiceren met Microsoft Entra ID (voorheen Azure AD). Raadpleeg de veelgestelde vragen over migratie voor veelgestelde vragen over migratie. Opmerking: versies 1.0.x van MSOnline kunnen na 30 juni 2024 onderbrekingen ondervinden.

Wanneer omleiding plaatsvindt, ziet u de volgende pagina:
1. Als er geen omdirigering plaatsvindt en u wordt gevraagd om een wachtwoord op dezelfde pagina in te voeren, betekent dit dat Microsoft Entra ID of Office 365 de gebruiker of het domein van de gebruiker niet herkent voor federatie. Als u wilt controleren of er een federatieve vertrouwensrelatie is tussen Microsoft Entra ID of Office 365 en uw AD FS-server, voert u de Get-MgDomain cmdlet uit en controleert u het AuthenticationType.
2. Als omleiding plaatsvindt, maar u niet wordt omgeleid naar uw AD FS-server voor aanmelding, controleert u of de naam van de AD FS-service wordt omgezet in het juiste IP-adres en of deze verbinding kan maken met dat IP-adres op TCP-poort 443.
  
  Als het domein wordt weergegeven als Federatief, kunt u informatie over de federatieve vertrouwensrelatie verkrijgen door de volgende opdrachten uit te voeren:
```
Get-MgDomainFederationConfiguration -DomainId <domain_id>
```
  Notitie
  
  < > domain_id is een tijdelijke aanduiding voor de naam van uw domein. Bijvoorbeeld contoso.com.
  
  Controleer de URI, URL en het certificaat van de federatiepartner die is geconfigureerd door Office 365 of Microsoft Entra-id.
Nadat u bent omgeleid naar AD FS, kan de browser een certificaatvertrouwensfout veroorzaken en voor sommige clients en apparaten kunt u mogelijk geen SSL-sessie (Secure Sockets Layer) met AD FS instellen. Volg deze stappen om dit probleem op te lossen:
1. Zorg ervoor dat het certificaat voor ad FS-servicecommunicatie dat aan de client wordt gepresenteerd, hetzelfde is dat is geconfigureerd op AD FS.
  
  In het ideale geval moet het CERTIFICAAT voor ad FS-servicecommunicatie hetzelfde zijn als het SSL-certificaat dat aan de client wordt gepresenteerd wanneer wordt geprobeerd een SSL-tunnel met de AD FS-service tot stand te brengen.
  
  In AD FS 2.0:
  - Koppel het certificaat aan de eerste iis-standaardsite>.
  - Gebruik de AD FS-module om hetzelfde certificaat toe te voegen als het certificaat voor servicecommunicatie.
  In AD FS 2012 R2:
  - Gebruik de AD FS-module of de Add-adfscertificate opdracht om een servicecommunicatiecertificaat toe te voegen.
  - Gebruik de Set-adfssslcertificate opdracht om hetzelfde certificaat in te stellen voor SSL-binding.
2. Zorg ervoor dat het communicatiecertificaat van de AD FS-service wordt vertrouwd door de client.
3. Als niet-SNI-compatibele clients proberen een SSL-sessie met AD FS of WAP 2-12 R2 tot stand te brengen, kan de poging mislukken. In dit geval kunt u overwegen om een terugvalvermelding toe te voegen op de AD FS- of WAP-servers ter ondersteuning van niet-SNI-clients. Voor meer informatie, zie Hoe ondersteuning te bieden aan niet-SNI-capabele clients met Web Application Proxy en AD FS 2012 R2.

U kunt te maken krijgen met een foutmelding 'Onbekende verificatiemethode' of fouten die aangeven dat AuthnContext niet wordt ondersteund op AD FS- of STS-niveau wanneer u wordt doorgestuurd vanaf Office 365. Het is het meest gebruikelijk wanneer u omleidt naar AD FS of STS met behulp van een parameter die een verificatiemethode afdwingt. Gebruik een van de volgende methoden om een verificatiemethode af te dwingen:

Gebruik voor WS-Federation een WAUTH-queryreeks om een voorkeursverificatiemethode af te dwingen.

Gebruik voor SAML2.0 het volgende:

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

Wanneer de afgedwongen verificatiemethode wordt verzonden met een onjuiste waarde of als deze verificatiemethode niet wordt ondersteund op AD FS of STS, ontvangt u een foutbericht voordat u wordt geverifieerd.

In de volgende tabel ziet u de verificatietype-URI's die worden herkend door AD FS voor passieve WS-Federation-verificatie.

Verificatiemethode gevraagd	wauth URI
Verificatie via gebruikersnaam en wachtwoord	urn:oasis:names:tc:SAML:1.0:am:password
SSL-clientauthenticatie	urn:ietf:rfc:2246
Geïntegreerde Windows-verificatie	urn:federation:authentication:windows

Ondersteunde contextklassen voor SAML-verificatie

Verificatiemethode	URI van verificatiecontextklasse
Gebruikersnaam en wachtwoord	urn:oasis:names:tc:SAML:2.0:ac:classes:Password
Met een wachtwoord beveiligd transport	urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
TLS-client (Transport Layer Security)	urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
X.509-certificaat	urn:oasis:names:tc:SAML:2.0:ac:classes:X509
Geïntegreerde Windows-verificatie	urn:federation:authentication:windows
Kerberos	urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos

Controleer het volgende om ervoor te zorgen dat de verificatiemethode wordt ondersteund op AD FS-niveau.

AD FS 2.0

Controleer onder /adfs/ls/web.config of de vermelding voor het verificatietype aanwezig is.

<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: het lokale verificatietype wijzigen

AD FS 2012 R2

Onder AD FS-beheer, selecteer Verificatiebeleid in de AD FS-module.
Selecteer In de sectie Primaire verificatie de optie Bewerken naast Algemene instellingen. U kunt ook met de rechtermuisknop op Verificatiebeleid klikken en vervolgens Globale primaire verificatie bewerken selecteren. Of selecteer Bewerken globale primaire verificatie in het deelvenster Acties.
In het venster Globale verificatiebeleid bewerken, op het tabblad Primair , kunt u instellingen configureren als onderdeel van het globale verificatiebeleid. Voor primaire verificatie kunt u bijvoorbeeld beschikbare verificatiemethoden selecteren onder Extranet en Intranet.

Zorg ervoor dat het selectievakje voor de vereiste verificatiemethode is ingeschakeld.

Als u bij uw AD FS komt en uw referenties invoert, maar niet geverifieerd kunt worden, controleer dan de volgende problemen.
1. Probleem met Active Directory-replicatie
  
  Als AD-replicatie is verbroken, worden wijzigingen die zijn aangebracht in de gebruiker of groep mogelijk niet gesynchroniseerd tussen domeincontrollers. Tussen domeincontrollers kan een wachtwoord, UPN, GroupMembership of Proxyaddress niet overeenkomen met het AD FS-antwoord (verificatie en claims). U moet beginnen met het bekijken van de domeincontrollers op dezelfde site als AD FS. Als u een repadmin /showreps of een DCdiag /v opdracht uitvoert, moet u zien of er een probleem is op de domeincontrollers waarmee AD FS waarschijnlijk contact zal opnemen.
  
  U kunt ook een AD-replicatieoverzicht verzamelen om ervoor te zorgen dat AD-wijzigingen correct worden gerepliceerd op alle domeincontrollers. De repadmin /showrepl * /csv > showrepl.csv uitvoer is handig voor het controleren van de replicatiestatus. Zie Problemen met Active Directory-replicatie oplossen voor meer informatie.
2. Account is vergrendeld of uitgeschakeld in Active Directory
  
  Wanneer een eindgebruiker wordt geverifieerd via AD FS, ontvangt hij of zij geen foutbericht waarin staat dat het account is vergrendeld of uitgeschakeld. Vanuit AD FS- en aanmeldingscontrole moet u kunnen bepalen of verificatie is mislukt vanwege een onjuist wachtwoord, of het account is uitgeschakeld of vergrendeld, enzovoort.
  
  Voer de volgende stappen uit om AD FS- en aanmeldingscontrole in te schakelen op de AD FS-servers:
  1. Gebruik lokaal of domeinbeleid om succes en fouten in te schakelen voor het volgende beleid:
    - Aanmeldingsgebeurtenis controleren, gelegen in Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy
    - Toegang tot controleobjecten, gelegen in Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy
  2. Schakel het volgende beleid uit:
    
    Controle: instellingen voor controlebeleid met subcategorieën (Windows Vista of nieuwer) bekrachtigen om instellingen voor controlebeleid met categorieën op te heffen
    
    Dit beleid bevindt zich in Computer configuration\Windows Settings\Security setting\Local Policy\Security Option.
    
    Zie Computers configureren voor het oplossen van problemen met AD FS 2.0 als u deze wilt configureren met behulp van geavanceerde controle.
  3. AD FS configureren voor controle:
    1. Open de MODULE AD FS 2.0-beheer.
    2. In het deelvenster Acties selecteer Eigenschappen van Federation Service bewerken.
    3. Selecteer in het Federation Service Eigenschappen dialoogvenster het tabblad Gebeurtenissen.
    4. Schakel de selectievakjes bij Succesvolle controles en Mislukte controles in.
    5. Voer GPupdate /force uit op de server.
3. Service Principal Name (SPN) is onjuist geregistreerd
  
  Er kunnen dubbele SPN's of een SPN zijn die is geregistreerd onder een ander account dan het AD FS-serviceaccount. Voor het instellen van een AD FS-farm moet u ervoor zorgen dat SPN HOST/AD FSservicename is toegevoegd onder het serviceaccount waarop de AD FS-service wordt uitgevoerd. Voor een zelfstandige AD FS-installatie, waarbij de service wordt uitgevoerd onder Netwerkservice, moet de SPN zich onder het servercomputeraccount bevinden dat als host fungeert voor AD FS.
  
  Zorg ervoor dat er geen dubbele SPN's zijn voor de AD FS-service, omdat dit kan leiden tot onregelmatige verificatiefouten met AD FS. Als u de SPN's wilt weergeven, voert u het volgende uit SETSPN -L <ServiceAccount>.
  
  Voer SETSPN -A HOST/AD FSservicename ServiceAccount uit om de SPN toe te voegen.
  
  Voer deze opdracht uit SETSPN -X -F om te controleren op dubbele SPN's.
4. Dubbele UPNs in Active Directory
  
  Een gebruiker kan zich mogelijk verifiëren via AD FS wanneer hij SAMAccountName gebruikt, maar niet kan worden geverifieerd bij het gebruik van UPN. In dit scenario kan Active Directory twee gebruikers bevatten die dezelfde UPN hebben. Het is mogelijk om te eindigen met twee gebruikers die dezelfde UPN hebben wanneer gebruikers worden toegevoegd en gewijzigd via scripting (BIJVOORBEELD ADSIedit).
  
  Wanneer UPN wordt gebruikt voor verificatie in dit scenario, wordt de gebruiker geverifieerd tegen de dubbele gebruiker. De opgegeven referenties worden dus niet gevalideerd.
  
  U kunt query's zoals de volgende gebruiken om te controleren of er meerdere objecten in AD zijn met dezelfde waarden voor een kenmerk:
```
Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN
```
  Zorg ervoor dat de UPN van de dubbele gebruiker wordt hernoemd, zodat het verificatieverzoek met de UPN wordt gevalideerd tegen de juiste objecten.
5. In een scenario waarin u uw e-mailadres gebruikt als de aanmeldings-id in Office 365 en u hetzelfde e-mailadres invoert wanneer u wordt omgeleid naar AD FS voor verificatie, kan verificatie mislukken met de fout 'NO_SUCH_USER' in de auditlogboeken. Als u AD FS wilt inschakelen om een gebruiker te vinden voor verificatie met behulp van een ander kenmerk dan UPN of SAMaccountname, moet u AD FS configureren ter ondersteuning van een alternatieve aanmeldings-id. Zie Configuring Alternate Login ID (Engelstalig) voor meer informatie.
  
  Op AD FS 2012 R2
  1. Installeer Update 2919355.
  2. Werk de AD FS-configuratie bij door de volgende PowerShell-cmdlet uit te voeren op een van de federatieservers in uw farm (als u een WID-farm hebt, moet u deze opdracht uitvoeren op de primaire AD FS-server in uw farm):
```
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID <attribute> -LookupForests <forest domain>
```
    Notitie
    
    AlternateLoginID de LDAP-naam van het kenmerk dat u wilt gebruiken voor aanmelding. LookupForests is de lijst met DNS-vermeldingen van forests waartoe uw gebruikers behoren.
    
    Als u de alternatieve aanmeldings-id-functie wilt inschakelen, moet u zowel de parameters AlternateLoginID als LookupForests configureren met een niet-nul, geldige waarde.
6. Het AD FS-serviceaccount heeft geen leestoegang tot het AD FS-token dat de persoonlijke sleutel van het certificaat ondertekent. Voer de volgende stappen uit om deze machtiging toe te voegen:
  1. Wanneer u een nieuw certificaat voor tokenondertekening toevoegt, ontvangt u de volgende waarschuwing:
    
    Zorg ervoor dat de persoonlijke sleutel voor het gekozen certificaat toegankelijk is voor het serviceaccount voor deze Federation-service op elke server in de farm.
  2. Selecteer Start, selecteer Uitvoeren, typ mmc.exe en druk op Enter.
  3. Selecteer Bestand en selecteer vervolgens Module toevoegen/verwijderen.
  4. Dubbelklik op Certificaten.
  5. Selecteer het betreffende computeraccount en klik vervolgens op Volgende.
  6. Selecteer Lokale computer en klik op Voltooien.
  7. Vouw Certificaten (lokale computer) uit, vouw Persona l uit en selecteer Certificaten.
  8. Klik met de rechtermuisknop op het nieuwe certificaat voor tokenondertekening, selecteer Alle taken en selecteer vervolgens Persoonlijke sleutels beheren.
  9. Voeg leestoegang toe voor uw AD FS 2.0-serviceaccount en selecteer VERVOLGENS OK.
  10. Sluit de MMC voor certificaten.
7. De optie Uitgebreide beveiliging voor Windows-verificatie is ingeschakeld voor de virtuele map AD FS of LS. Dit kan problemen veroorzaken met specifieke browsers. Soms ziet u ad FS herhaaldelijk vragen om referenties, en het kan zijn gerelateerd aan de uitgebreide beveiligingsinstelling die is ingeschakeld voor Windows-verificatie voor de AD FS- of LS-toepassing in IIS.
  
  Wanneer Uitgebreide beveiliging voor verificatie is ingeschakeld, zijn verificatieaanvragen gebonden aan zowel de SPN's (Service Principal Names) van de server waarmee de client verbinding probeert te maken en met het buitenste TLS-kanaal (Transport Layer Security) waarop geïntegreerde Windows-verificatie plaatsvindt. Uitgebreide bescherming versterkt de bestaande functionaliteit van Windows-verificatie om verificatierelais of 'man in the middle'-aanvallen te voorkomen. Bepaalde browsers werken echter niet met de uitgebreide beveiligingsinstelling; in plaats daarvan vragen ze herhaaldelijk om referenties en weigeren ze vervolgens de toegang. Het uitschakelen van uitgebreide beveiliging helpt in dit scenario.
  
  Zie AD FS 2.0 voor meer informatie: Continu gevraagd om referenties tijdens het gebruik van Fiddler Web Debugger.
  
  Voor AD FS 2012 R2
  
  Voer de volgende cmdlet uit om uitgebreide beveiliging uit te schakelen:
```
Set-ADFSProperties -ExtendedProtectionTokenCheck None
```
8. Autorisatieregels voor uitgifte in de Relying Party (RP) vertrouwensrelatie kunnen de toegang voor gebruikers weigeren. Op de vertrouwensrelatie van AD FS Relying Party kunt u de uitgifteautorisatieregels configureren die bepalen of een geverifieerde gebruiker een token moet worden uitgegeven voor een Relying Party. Beheerders kunnen de claims gebruiken die worden uitgegeven om te bepalen of ze toegang willen weigeren tot een gebruiker die lid is van een groep die als claim wordt opgehaald.
  
  Als bepaalde federatieve gebruikers niet kunnen worden geverifieerd via AD FS, kunt u de uitgifteautorisatieregels voor de Office 365 RP controleren en zien of de regel Toegang tot alle gebruikers toestaan is geconfigureerd.
  
  Als deze regel niet is ingesteld, bekijkt u de aangepaste autorisatieregels om te controleren of de voorwaarde in die regel waar is voor de betrokken gebruiker. Voor meer informatie raadpleegt u de volgende bronnen:
  Als u vanuit een intranet kunt verifiëren wanneer u rechtstreeks toegang hebt tot de AD FS-server, maar u niet kunt verifiëren wanneer u AD FS opent via een AD FS-proxy, controleert u op de volgende problemen:
  - Probleem met tijdsynchronisatie op AD FS-server en AD FS-proxy
    
    Zorg ervoor dat de tijd op de AD FS-server en de tijd op de proxy zijn gesynchroniseerd. Wanneer de tijd op de AD FS-server met meer dan vijf minuten afwijkt van de tijd op de domeincontrollers, treden verificatiefouten op. Wanneer de tijd op AD FS-proxy niet wordt gesynchroniseerd met AD FS, wordt de vertrouwensrelatie van de proxy beïnvloed en verbroken. Een aanvraag die via de AD FS-proxy wordt geleverd, mislukt dus.
  - Controleer of de AD FS-proxyvertrouwensrelatie met de AD FS-service correct werkt. Voer de proxyconfiguratie opnieuw uit als u vermoedt dat de proxyvertrouwensrelatie is verbroken.
Nadat uw AD FS een token heeft afgegeven, geeft Microsoft Entra ID of Office 365 een fout weer. Controleer in deze situatie op de volgende problemen:
- De claims die zijn uitgegeven door AD FS in token moeten overeenkomen met de respectieve kenmerken van de gebruiker in Microsoft Entra ID. In het token voor Microsoft Entra ID of Office 365 zijn de volgende claims vereist.
  
  WSFED:
  UPN: de waarde van deze claim moet overeenkomen met de UPN van de gebruikers in Microsoft Entra-id.
  ImmutableID: de waarde van deze claim moet overeenkomen met de sourceAnchor of ImmutableID van de gebruiker in Microsoft Entra-id.
  
  Voer de volgende opdrachtregel uit om de waarde van het gebruikerskenmerk in Microsoft Entra-id op te halen:
```
Get-MgUser -UserId <user_id_string>
```
  SAML 2.0:
  IDPEmail: de waarde van deze claim moet overeenkomen met de user principal name van de gebruikers in Microsoft Entra ID.
  NAMEID: De waarde van deze claim moet overeenkomen met de sourceAnchor of ImmutableID van de gebruiker in Microsoft Entra-id.
  
  Voor meer informatie, zie Een SAML 2.0 Identity Provider (IdP) gebruiken voor Single Sign On.
  
  Voorbeelden:
  Dit probleem kan optreden wanneer de UPN van een gesynchroniseerde gebruiker wordt gewijzigd in AD, maar zonder de onlinedirectory bij te werken. In dit scenario kunt u de UPN van de gebruiker corrigeren in AD (zodat deze overeenkomt met de aanmeldingsnaam van de gerelateerde gebruiker) of de volgende cmdlet uitvoeren om de aanmeldingsnaam van de gerelateerde gebruiker in de onlinemap te wijzigen:
```
Update-MgUser -UserId <user_id_string> -UserPrincipalName <DomainUPN-AD>
```
  Het kan ook zijn dat u AADsync gebruikt om MAIL te synchroniseren als UPN en EMPID als SourceAnchor, maar de Relying Party-claimregels op AD FS-niveau zijn niet bijgewerkt om MAIL als UPN en EMPID te verzenden als ImmutableID.
- Er komt een certificaat voor tokenondertekening niet overeen tussen AD FS en Office 365.
  
  Dit is een van de meest voorkomende problemen. AD FS gebruikt het certificaat voor tokenondertekening om het token te ondertekenen dat naar de gebruiker of toepassing wordt verzonden. De vertrouwensrelatie tussen AD FS en Office 365 is een federatieve vertrouwensrelatie die is gebaseerd op dit certificaat voor tokenondertekening (Office 365 controleert bijvoorbeeld of het ontvangen token is ondertekend met behulp van een tokenondertekeningscertificaat van de claimprovider [de AD FS-service] die wordt vertrouwd).
  
  Als het certificaat voor token-ondertekening op de AD FS echter wordt gewijzigd vanwege automatische certificaatrollover of door tussenkomst van een beheerder (na of vóór het verlopen van het certificaat), moeten de details van het nieuwe certificaat worden bijgewerkt op de Office 365-tenant voor het federatieve domein. Het gebeurt mogelijk niet automatisch; hiervoor is mogelijk tussenkomst van een beheerder vereist. Wanneer het primaire tokenondertekeningscertificaat op de AD FS verschilt van wat Office 365 weet, wordt het token dat is uitgegeven door AD FS niet vertrouwd door Office 365. De federatieve gebruiker mag zich dus niet aanmelden.
  
  Office 365 of Microsoft Entra ID probeert contact op te nemen met de AD FS-service, ervan uitgaande dat de service bereikbaar is via het openbare netwerk. We proberen de AD FS-federatiemetagegevens regelmatig te peilen, om eventuele configuratiewijzigingen op AD FS op te halen, voornamelijk de gegevens van het tokenondertekeningscertificaat. Als dit proces niet werkt, moet de globale beheerder een waarschuwing ontvangen in de Office 365-portal over het verlopen van het certificaat voor token-ondertekening en over de acties die nodig zijn om het bij te werken.
  
  U kunt Get-MgDomainFederationConfiguration -DomainId <domain_id> gebruiken om de federatie-eigenschap op AD FS en Office 365 te dumpen. Hier kunt u de tokenSigningCertificate-vingerafdruk vergelijken om te controleren of de Office 365-tenantconfiguratie voor uw federatieve domein is gesynchroniseerd met AD FS. Als de configuratie van het certificaat voor token-ondertekening niet overeenkomt, voert u de volgende opdracht uit om deze bij te werken:
```
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
```
  Notitie
  
  < > domain_id is een tijdelijke aanduiding voor de naam van uw domein. Bijvoorbeeld contoso.com.
  
  Zie Federatiecertificaten vernieuwen voor Microsoft 365 en Microsoft Entra ID voor meer informatie.
- Claimregels voor uitgiftetransformatie voor de Office 365 RP zijn niet correct geconfigureerd.
  
  In een scenario waarin u meerdere TLD's (top-level domeinen) hebt, kunt u mogelijk aanmeldproblemen tegenkomen als de switch Supportmultipledomain niet is gebruikt toen de RP-vertrouwensrelatie werd aangemaakt en bijgewerkt.
  
  U wordt aangeraden Entra Connect te gebruiken voor het beheren van de federaties en de claimregels. Doorgaans worden ADFS en Entra automatisch en correct geconfigureerd. Zie Multiple Domain Support for Federating with Microsoft Entra ID voor meer informatie.
- Zorg ervoor dat tokenversleuteling niet wordt gebruikt door AD FS of STS wanneer een token wordt uitgegeven aan Microsoft Entra-id of aan Office 365.
Er zijn verouderde referenties in de cache in Windows Credential Manager.

Soms tijdens het aanmelden vanaf een werkstation naar de portal (of bij het gebruik van Outlook), wanneer de gebruiker om referenties wordt gevraagd, kunnen de referenties worden opgeslagen voor het doel (Office 365- of AD FS-service) in Windows Credentials Manager (Control Panel\User Accounts\Credential Manager). Hiermee voorkomt u dat er enige tijd om referenties wordt gevraagd, maar dit kan een probleem veroorzaken nadat het gebruikerswachtwoord is gewijzigd en de referentiesbeheerder niet wordt bijgewerkt. In dat scenario worden verouderde referenties naar de AD FS-service verzonden en daarom mislukt de verificatie. Het verwijderen of bijwerken van de referenties in de cache kan helpen in Windows Credential Manager.
Zorg ervoor dat het secure hash-algoritme dat is geconfigureerd op de Relying Party Trust voor Office 365 is ingesteld op SHA1.

Wanneer de vertrouwensrelatie tussen de STS/AD FS en Microsoft Entra ID/Office 365 SAML 2.0-protocol gebruikt, moet het secure hash-algoritme dat is geconfigureerd voor digitale handtekening SHA1 zijn.
Als geen van de voorgaande oorzaken van toepassing is op uw situatie, maakt u een ondersteuningsaanvraag bij Microsoft en vraagt u hen om te controleren of het gebruikersaccount consistent wordt weergegeven onder de Office 365-tenant. Voor meer informatie, zie Een federatieve gebruiker wordt herhaaldelijk om referenties gevraagd tijdens het aanmelden bij Office 365, Azure of Intune.

Afhankelijk van de cloudservice (geïntegreerd met Microsoft Entra ID) die u opent, kan de verificatieaanvraag die naar AD FS wordt verzonden, variëren. Bijvoorbeeld: bepaalde aanvragen kunnen aanvullende parameters bevatten, zoals Wauth of Wfresh, en deze parameters kunnen afwijkend gedrag veroorzaken op AD FS-niveau.

U wordt aangeraden binaire AD FS-bestanden altijd bijgewerkt te houden om de oplossingen voor bekende problemen op te nemen. Zie de volgende tabel voor meer informatie over de nieuwste updates.

AD FS 2.0	AD FS 2012 R2
Beschrijving van updatepakket 3 voor Active Directory Federation Services (AD FS) 2.0 Update is beschikbaar om verschillende problemen op te lossen nadat u beveiligingsupdate 2843638 op een AD FS-server hebt geïnstalleerd	Updatepakket van december 2014 voor Windows RT 8.1, Windows 8.1 en Windows Server 2012 R2

Referentie

Zie de volgende artikelen voor meer informatie over de Microsoft Graph-cmdlets:

Delen via

AD FS-problemen in Microsoft Entra-id en Office 365 oplossen

Symptomen

Problemen met werkstroom oplossen

Referentie

Feedback

Aanvullende resources