Felsöka problem med enkel inloggning med Active Directory Federation Services (AD FS) (AD FS)

Den här artikeln hjälper dig att lösa problem med enkel inloggning (SSO) med Active Directory Federation Services (AD FS) (AD FS).

Välj något av följande avsnitt beroende på vilken typ av problem du stöter på.

Gäller för: Active Directory Federation Services (AD FS)
Ursprungligt KB-nummer: 4034932

NTLM- eller formulärbaserad autentiseringsprompt

Under felsökning av problem med enkel inloggning (SSO) med Active Directory Federation Services (AD FS) (AD FS) följer du stegen i den här artikeln för att felsöka problemet om användarna har fått oväntad NTLM eller formulärbaserad autentiseringsprompt.

Kontrollera inställningarna för Windows-integrerad autentisering

Om du vill felsöka det här problemet kontrollerar du inställningarna för Windows-integrerad autentisering i klientwebbläsaren, AD FS-inställningar och parametrar för autentiseringsbegäran.

Kontrollera användarens klientwebbläsare

Kontrollera följande inställningar i Internetalternativ:

• På fliken Avancerat kontrollerar du att inställningen Aktivera integrerad Windows-autentisering är aktiverad.
• Se till att AD FS-URL:en finns i listan över webbplatser genom att följa Säkerhetswebbplatser>> lokaltintranät>Avancerat.
• Kontrollera att inställningen Automatisk inloggning endast i zonen Intranät är markerad efter anpassad nivå för lokalt intranät > för säkerhet>.

Om du använder Firefox, Chrome eller Safari kontrollerar du att motsvarande inställningar i dessa webbläsare är aktiverade.

Kontrollera AD FS-inställningarna

Kontrollera inställningen WindowsIntegratedFallback

1. Öppna Windows PowerShell med alternativet Kör som administratör.

2. Hämta den globala autentiseringsprincipen genom att köra följande kommando:

   Get-ADFSGlobalAuthenticationPolicy | fl WindowsIntegratedFallbackEnabled
   

3. Granska värdet för attributet WindowsIntegratedFallbackEnabled .

Om värdet är Sant förväntas formulärbaserad autentisering. Det innebär att autentiseringsbegäran kommer från en webbläsare som inte stöder Windows-integrerad autentisering. Se nästa avsnitt om hur du får webbläsaren stödd.

Om värdet är Falskt bör windowsintegrerad autentisering förväntas.

Kontrollera inställningen WIASupportedUsersAgents

1. Hämta listan över användaragenter som stöds genom att köra följande kommando:

   Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
   

2. Granska listan över användaragentsträngar som kommandot returnerar.

Kontrollera om användaragentsträngen i webbläsaren finns i listan. Annars lägger du till användaragentsträngen genom att följa stegen nedan:

1. Gå till http://useragentstring.com/ som identifierar och visar användaragentsträngen i webbläsaren.

2. Hämta listan över användaragenter som stöds genom att köra följande kommando:

   $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
   

3. Lägg till användaragentsträngen i webbläsaren genom att köra följande kommando:

   $wiaStrings = $wiaStrings+"NewUAString"
   

   Exempel:

   $wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"
   

4. Uppdatera inställningen WIASupportedUserAgents genom att köra följande kommando:

   Set-ADFSProperties -WIASupportedUserAgents $wiaStrings
   

Kontrollera parametrarna för autentiseringsbegäran

Kontrollera om autentiseringsbegäran anger formulärbaserad autentisering som autentiseringsmetod

1. Om autentiseringsbegäran är en WS-Federation begäran kontrollerar du om begäran innehåller wauth= urn:oasis:names:tc:SAML:1.0:am:password.
2. Om autentiseringsbegäran är en SAML-begäran kontrollerar du om begäran innehåller ett samlp:AuthnContextClassRef-element med värdet urn:oasis:names:tc:SAML:2.0:ac:classes:Password.

Mer information finns i Översikt över autentiseringshanterare för AD FS-inloggningssidor.

Kontrollera om programmet är Microsoft Online Services för Office 365

Om det program som du vill komma åt inte är Microsoft Online Services förväntas och styrs det du upplever av begäran om inkommande autentisering. Arbeta med programägaren för att ändra beteendet.

Om programmet är Microsoft Online Services kan det du upplever styras av inställningen PromptLoginBehavior från objektet för betrodd sfär. Den här inställningen styr om Microsoft Entra klienter skickar prompt=login till AD FS. Följ dessa steg om du vill ange inställningen PromptLoginBehavior :

1. Öppna Windows PowerShell med alternativet Kör som administratör.

2. Hämta den befintliga domänfederationsinställningen genom att köra följande kommando:

   Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
   

3. Ange inställningen PromptLoginBehavior genom att köra följande kommando:

   Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior <TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>
   

   Värdena för parametern PromptLoginBehavior är:

   1. TranslateToFreshPasswordAuth: Microsoft Entra ID skickar wauth och wfresh till AD FS i stället för prompt=login. Detta leder till en autentiseringsbegäran om att använda formulärbaserad autentisering.
   2. NativeSupport: Parametern prompt=login skickas som den är till AD FS.
   3. Inaktiverad: Ingenting skickas till AD FS.

Mer information om kommandot Set-MSOLDomainFederationSettings finns i Active Directory Federation Services (AD FS) prompt=login parameter support (stöd för Active Directory Federation Services (AD FS) prompt=login parameter).

Microsoft Entra scenario

Om autentiseringsbegäran som skickas till Microsoft Entra ID inkludera parametern prompt=login inaktiverar du funktionen prompt=login genom att köra följande kommando:

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

När du har kört det här kommandot tar Office 365 program inte med parametern prompt=login i varje autentiseringsbegäran.

Scenario som inte är Microsoft Entra

Begärandeparametrar som WAUTH och RequestedAuthNContext i autentiseringsbegäranden kan ha angivna autentiseringsmetoder. Kontrollera om andra begärandeparametrar framtvingar den oväntade autentiseringsprompten. I så fall ändrar du begärandeparametern så att den använder den förväntade autentiseringsmetoden.

Kontrollera om enkel inloggning är inaktiverat

Om enkel inloggning är inaktiverat aktiverar du det och testar om problemet har lösts.

Fråga om multifaktorautentisering

Om du vill felsöka det här problemet kontrollerar du om anspråksreglerna i den förlitande parten är korrekt inställda för multifaktorautentisering.

Multifaktorautentisering kan aktiveras på en AD FS-server, hos en förlitande part eller anges i en parameter för autentiseringsbegäran. Kontrollera konfigurationerna för att se om de är korrekt inställda. Om multifaktorautentisering förväntas men du upprepade gånger uppmanas att göra det kontrollerar du reglerna för utfärdande av förlitande part för att se om multifaktorautentiseringsanspråk skickas till programmet.

Mer information om multifaktorautentisering i AD FS finns i följande artiklar:

• Under hood-rundturen på Multi-Factor Authentication i ADFS – del 1: Princip
• Under hood-rundturen på Multi-Factor Authentication i ADFS – del 2: MFA-medvetna förlitande parter

Kontrollera konfigurationen på AD FS-servern och den förlitande parten

Kontrollera konfigurationen på AD FS-servern genom att verifiera de globala ytterligare autentiseringsreglerna. Kontrollera konfigurationen på den förlitande parten genom att verifiera de ytterligare autentiseringsreglerna för förlitande partsförtroende.

1. Kontrollera konfigurationen på AD FS-servern genom att köra följande kommando i ett Windows PowerShell fönster.

   Get-ADFSAdditionalAuthenticationRule
   

   Kör följande kommando för att kontrollera konfigurationen på den förlitande parten:

   Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules
   

   Obs!

   Om kommandona inte returnerar något konfigureras inte de ytterligare autentiseringsreglerna. Hoppa över det här avsnittet.

2. Observera den konfigurerade anspråksregeluppsättningen.

Kontrollera om multifaktorautentisering är aktiverat i anspråksregeluppsättningen

En anspråksregeluppsättning består av följande avsnitt:

• Villkorssatsen: C:[Type=``…,Value=…]
• Ärendeuttryck: => issue (Type=``…,Value=…)

Om issue-instruktionen innehåller följande anspråk anges multifaktorautentisering.
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"

Här följer exempel som kräver att multifaktorautentisering används för enheter som inte är anslutna till arbetsplatsen och för extranätsåtkomst:

• c:[Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")
• c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")

Kontrollera utfärdandereglerna för förlitande part

Om användaren upprepade gånger får frågor om multifaktorautentisering efter den första autentiseringen är det möjligt att svarsparten inte skickar igenom multifaktorautentiseringsanspråken till programmet. Följ dessa steg för att kontrollera om autentiseringsanspråken skickas:

1. Kör följande kommando i Windows PowerShell:

   Get-ADFSRelyingPartyTrust -TargetName ClaimApp
   

2. Observera regeluppsättningen som definierats i attributen IssuanceAuthorizationRules eller IssuanceAuthorizationRulesFile.

Regeluppsättningen bör innehålla följande utfärdanderegel för att passera multifaktorautentiseringsanspråken:
C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==" http://schemas.microsoft.com/claims/multipleauthn"]=>issue(claim = c)

Kontrollera parametern för autentiseringsbegäran

Kontrollera om autentiseringsbegäran anger multifaktorautentisering som autentiseringsmetod

• Om autentiseringsbegäran är en WS-Federation begäran kontrollerar du om begäran innehåller wauth= http://schemas.microsoft.com/claims/multipleauthn.
• Om autentiseringsbegäran är en SAML-begäran kontrollerar du om begäran innehåller ett samlp:AuthnContextClassRef-element med värdet http://schemas.microsoft.com/claims/multipleauthn.

Mer information finns i Översikt över autentiseringshanterare för AD FS-inloggningssidor.

Kontrollera om programmet är Microsoft Online Services för Office 365

Om det program som du vill komma åt är Microsoft Online Services för Office 365 kontrollerar du federationsinställningen för SupportsMFA-domän.

1. Hämta den aktuella inställningen för SupportsMFA-domänfederation genom att köra följande kommando:

   Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
   

2. Om inställningen SupportsMFA är FALSE ställer du in den på TRUE genom att köra följande kommando:

   Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE
   

Kontrollera om enkel inloggning är inaktiverat

Om enkel inloggning är inaktiverat aktiverar du det och testar om problemet har lösts.

Användare kan inte logga in på målwebbplatsen eller -tjänsten

Det här problemet kan inträffa på AD FS-inloggningssidan eller på programsidan.

Om problemet uppstår på AD FS-inloggningssidan får du ett felmeddelande om att ett fel har uppstått, att HTTP 503-tjänsten inte är tillgänglig eller något annat felmeddelande. URL:en för felsidan visar AD FS-tjänstnamnet, fs.contoso.comtill exempel .

Om problemet uppstår på programsidan visar URL:en för felsidan IP-adressen eller platsnamnet för måltjänsten.

Följ stegen i följande avsnitt där du stöter på det här problemet.

Det här problemet uppstår på AD FS-inloggningssidan

Om du vill felsöka det här problemet kontrollerar du om alla användare påverkas av problemet och om användarna kan komma åt alla förlitande parter.

Alla användare påverkas av problemet och användaren kan inte komma åt någon av de förlitande parterna

Nu ska vi kontrollera den interna inloggningsfunktionen med IdpInitiatedSignOn. Det gör du genom att använda sidan IdpInititatedSignOn för att kontrollera om AD FS-tjänsten är igång och autentiseringsfunktionen fungerar korrekt. Så här öppnar du sidan IdpInitiatedSignOn:

1. Aktivera sidan IdpInitiatedSignOn genom att köra följande kommando på AD FS-servern:

   Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
   

2. Besök följande sida från en dator som finns i nätverket:
   https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

3. Ange rätt autentiseringsuppgifter för en giltig användare på inloggningssidan.

Inloggningen har slutförts

Om inloggningen lyckas kontrollerar du om AD FS-tjänsttillståndet körs.

1. Öppna Serverhanteraren på AD FS-servern.
2. I Serverhanteraren klickar du på Verktygstjänster>.
3. Kontrollera om statusenför Active Directory Federation Services (AD FS)körs.

Kontrollera sedan de externa inloggningsfunktionerna med IdpInitiatedSignOn. Använd sidan IdpInititatedSignOn för att snabbt kontrollera om AD FS-tjänsten är igång och autentiseringsfunktionen fungerar korrekt. Så här öppnar du sidan IdpInitiatedSignOn:

1. Aktivera sidan IdpInitiatedSignOn genom att köra följande kommando på AD FS-servern:

   Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
   

2. Besök följande sida från en dator utanför nätverket:
   https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

3. Ange rätt autentiseringsuppgifter för en giltig användare på inloggningssidan.

Om inloggningen misslyckas läser du Kontrollera AD FS-relaterade komponenter och tjänster och Kontrollera proxyförtroenderelationen.

Om inloggningen lyckas fortsätter du felsökningen med stegen i Alla användare påverkas av problemet och användaren kan komma åt några av de förlitande parterna.

Inloggningen misslyckades

Om inloggningen misslyckas kontrollerar du de AD FS-relaterade komponenterna och tjänsterna.

Kontrollera om AD FS-tjänsttillståndet körs.

1. Öppna Serverhanteraren på AD FS-servern.
2. I Serverhanteraren klickar du på Verktygstjänster>.
3. Kontrollera om statusenför Active Directory Federation Services (AD FS)körs.

Kontrollera om slutpunkterna är aktiverade. AD FS tillhandahåller olika slutpunkter för olika funktioner och scenarier. Alla slutpunkter är inte aktiverade som standard. Så här kontrollerar du slutpunkternas status:

1. Öppna AD FS-hanteringskonsolen på AD FS-servern.

2. ExpanderaTjänstslutpunkter>.

3. Leta upp slutpunkterna och kontrollera om statusen är aktiverad i kolumnen Aktiverad .

   

Kontrollera sedan om Microsoft Entra Connect är installerat. Vi rekommenderar att du använder Microsoft Entra Connect, vilket gör SSL-certifikathantering enklare.

Om Microsoft Entra Connect är installerat kontrollerar du att du använder det för att hantera och uppdatera SSL-certifikat.

Om Microsoft Entra Connect inte är installerat kontrollerar du om SSL-certifikatet uppfyller följande AD FS-krav:

• Certifikatet kommer från en betrodd rotcertifikatutfärdare.

  AD FS kräver att SSL-certifikat kommer från en betrodd rotcertifikatutfärdare. Om AD FS nås från icke-domänanslutna datorer rekommenderar vi att du använder ett SSL-certifikat från en betrodd rotcertifikatutfärdare från tredje part som DigiCert, VeriSign osv. Om SSL-certifikatet inte kommer från en betrodd rotcertifikatutfärdare kan SSL-kommunikationen avbrytas.

• Certifikatets ämnesnamn är giltigt.

  Ämnesnamnet ska matcha federationstjänstens namn, inte AD FS-servernamnet eller något annat namn. Hämta federationstjänstens namn genom att köra följande kommando på den primära AD FS-servern:
  Get-AdfsProperties | select hostname

• Certifikatet har inte återkallats.

  Sök efter återkallning av certifikat. Om certifikatet återkallas kan SSL-anslutningen inte vara betrodd och blockeras av klienter.

Om SSL-certifikatet inte uppfyller dessa krav kan du försöka hämta ett kvalificerat certifikat för SSL-kommunikation. Vi rekommenderar att du använder Microsoft Entra Connect, vilket gör SSL-certifikathantering enklare. Se Uppdatera TLS/SSL-certifikatet för en Active Directory Federation Services (AD FS) -servergrupp (AD FS).

Om SSL-certifikatet uppfyller dessa krav kontrollerar du följande konfigurationer av SSL-certifikatet.

Kontrollera om SSL-certifikatet är korrekt installerat

SSL-certifikatet ska installeras i det personliga arkivet för den lokala datorn på varje federationsserver i servergruppen. Om du vill installera certifikatet dubbelklickar du på . PFX-filen för certifikatet och följ guiden.

Följ dessa steg för att kontrollera om certifikatet har installerats på rätt plats:

1. Ange de certifikat som finns i det personliga arkivet för den lokala datorn genom att köra följande kommando:
   dir Cert:\LocalMachine\My
2. Kontrollera om certifikatet finns i listan.

Kontrollera om rätt SSL-certifikat används

Hämta tumavtrycket för certifikatet som används för SSL-kommunikation och kontrollera om tumavtrycket matchar det förväntade certifikatets tumavtryck.

Kör följande kommando i Windows PowerShell för att hämta tumavtrycket för certifikatet som används:

Get-AdfsSslCertificate

Om fel certifikat används anger du rätt certifikat genom att köra följande kommando:

Set-AdfsSslCertificate –Thumbprint CorrectThumprint

Kontrollera om SSL-certifikatet har angetts som tjänstkommunikationscertifikat

SSL-certifikatet måste anges som tjänstkommunikationscertifikat i AD FS-servergruppen. Detta sker inte automatiskt. Följ dessa steg för att kontrollera om rätt certifikat har angetts:

1. I AD FS-hanteringskonsolen expanderar du Tjänstcertifikat>.
2. Kontrollera om certifikatet som anges under Tjänstkommunikation är det förväntade certifikatet.

Om fel certifikat visas anger du rätt certifikat och ger sedan AD FS-tjänsten läsbehörighet till certifikatet. Gör så här:

1. Ange rätt certifikat:

   1. Högerklicka på Certifikat och klicka sedan på Ange tjänstkommunikationscertifikat.
   2. Välj rätt certifikat.

2. Kontrollera om AD FS-tjänsten har läsbehörighet till certifikatet:

   1. Lägg till snapin-modulen Certifikat för det lokala datorkontot i Microsoft Management Console (MMC).
   2. Expandera Certifikat (lokal dator)>Personliga>certifikat.
   3. Högerklicka på SSL-certifikatet och klicka på Alla uppgifter>Hantera privata nycklar.
   4. Kontrollera om adfssrv visas under Grupp och användarnamn med läsbehörighet .

3. Om adfssrv inte visas beviljar du AD FS-tjänsten läsbehörighet till certifikatet:

   1. Klicka på Lägg till, klicka på Platser, klicka på servern och klicka sedan på OK.
   2. Under Ange de objektnamn som ska väljas anger du nt service\adfssrv, klickar på Kontrollera namn och klickar sedan på OK.
      Om du använder AD FS med Device Registration Service (DRS) anger du nt service\drs i stället.
   3. Bevilja behörigheten Läs och klicka sedan på OK.

Kontrollera om enhetsregistreringstjänsten (DRS) har konfigurerats i AD FS

Om du har konfigurerat AD FS med DRS kontrollerar du att SSL-certifikatet också är korrekt konfigurerat för RDS. Om det till exempel finns två UPN-suffix contoso.com och fabrikam.commåste certifikatet ha enterpriseregistration.contoso.com och enterpriseregistration.fabrikma.com som alternativa namn för certifikatmottagare (SAN).

Följ dessa steg för att kontrollera om SSL-certifikatet har rätt SAN:er:

1. Visa en lista över alla UPN-suffix som används i organisationen genom att köra följande kommando:

   Get-AdfsDeviceRegistratrionUpnSuffix
   

2. Kontrollera om SSL-certifikatet har de nödvändiga SAN:erna konfigurerade.

3. Om SSL-certifikatet inte har rätt DRS-namn som SAN hämtar du ett nytt SSL-certifikat som har rätt SAN för DRS och använder det sedan som SSL-certifikat för AD FS.

Kontrollera sedan certifikatkonfigurationen på WAP-servrar och återställningsbindningarna:

• Kontrollera om rätt SSL-certifikat har angetts på alla WAP-servrar.

  1. Kontrollera att SSL-certifikatet är installerat i det personliga arkivet för den lokala datorn på varje WAP-server.

  2. Hämta SSL-certifikatet som används av WAP genom att köra följande kommando:

     Get-WebApplicationProxySslCertificate
     

  3. Om SSL-certifikatet är fel anger du rätt SSL-certifikat genom att köra följande kommando:

     Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint
     

• Kontrollera certifikatbindningarna och uppdatera dem om det behövs.

  För att stödja icke-SNI-fall kan administratörer ange återställningsbindningar. Förutom standardbindningen federationservicename:443 letar du efter återställningsbindningar under följande program-ID:

  • {5d89a20c-beab-4389-9447-324788eb944a}: Detta är program-ID för AD FS.
  • {f955c070-e044-456c-ac00-e9e4275b3f04}: Det här är program-ID:t för Web Programproxy.

  Om till exempel SSL-certifikatet har angetts för en återställningsbindning som 0.0.0.0:443 kontrollerar du att bindningen uppdateras när SSL-certifikatet uppdateras.

Alla användare påverkas av problemet och användaren kan komma åt några av de förlitande parterna

Först hämtar vi den förlitande parten och OAuth-klientinformationen. Om du använder en konventionell förlitande part följer du dessa steg:

1. På den primära AD FS-servern öppnar du Windows PowerShell med alternativet Kör som administratör.

2. Lägg till AD FS 2.0-komponenten i Windows PowerShell genom att köra följande kommando:

   Add-PSSnapin Microsoft.Adfs.PowerShell
   

3. Hämta den förlitande partens information genom att köra följande kommando:

   $rp = Get-AdfsRelyingPartyTrust RPName
   

4. Hämta OAuth-klientinformationen genom att köra följande kommando:

   $client = Get-AdfsClient ClientName
   

Om du använder funktionen Programgrupp i Windows Server 2016 följer du stegen nedan:

1. På den primära AD FS-servern öppnar du Windows PowerShell med alternativet Kör som administratör.

2. Hämta den förlitande partens information genom att köra följande kommando:
   $rp = Get-AdfsWebApiApplication ResourceID

3. Om OAuth-klienten är offentlig hämtar du klientinformationen genom att köra följande kommando:

   $client = Get-AdfsNativeClientApplication ClientName
   

   Om klienten är konfidentiell hämtar du klientinformationen genom att köra följande kommando:

   $client = Get-AdfsServerApplication ClientName
   

Fortsätt nu med följande felsökningsmetoder.

Kontrollera inställningarna för den förlitande parten och klienten

Den förlitande partens identifierare, klient-ID och omdirigerings-URI ska tillhandahållas av programmets ägare och klienten. Det kan dock fortfarande finnas ett matchningsfel mellan vad ägaren tillhandahåller och vad som konfigureras i AD FS. Till exempel kan ett matchningsfel orsakas av ett stavfel. Kontrollera om inställningarna som tillhandahålls av ägaren matchar de som konfigurerats i AD FS. Stegen på föregående sida beskriver de inställningar som konfigurerats i AD FS via PowerShell.

Inställningar som tillhandahålls av ägaren	Inställningar som konfigurerats i AD FS
Förlitande parts-ID	$rp. Identifierare
Omdirigerings-URI för förlitande part	Ett prefix eller jokertecken som matchar $rp. WSFedEndpoint för en WS-Fed förlitande part $rp. SamlEndpoints för en SAML-förlitande part
Klient-ID	$client. ClientId
Omdirigerings-URI för klient	En prefixmatchning av $client. RedirectUri

Om objekten i tabellen matchar kontrollerar du dessutom om de här inställningarna matchar vad de visas i autentiseringsbegäran som skickas till AD FS och vad som konfigureras i AD FS. Prova att återskapa problemet när du registrerar en Fiddler-spårning på autentiseringsbegäran som skickas av programmet till AD FS. Granska begärandeparametrarna för att göra följande kontroller beroende på typ av begäran.

OAuth-begäranden

En OAuth-begäran ser ut så här:

https://sts.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource=https://www.TestApp.com

Kontrollera om begärandeparametrarna matchar de inställningar som konfigurerats i AD FS.

Begärandeparametrar	Inställningar som konfigurerats i AD FS
client_id	$client. ClientId
redirect_uri	En prefixmatchning av @client_RedirectUri

Parametern "resource" ska representera en giltig förlitande part i AD FS. Hämta information om förlitande part genom att köra något av följande kommandon.

• Om du använder en konventionell förlitande part kör du följande kommando:
  Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"
• Om du använder funktionen Programgrupp i Windows Server 2016 kör du följande kommando:
  Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

WS-Fed begäranden

En WS-Fed begäran ser ut så här:

https://fs.contoso.com/adfs/ls/?wa=wsignin1.0&wtrealm=https://claimsweb.contoso.com&wctx=rm=0&id=passive&ru=/&wct=2014-10-21T22:15:42Z

Kontrollera om begärandeparametrarna matchar de inställningar som konfigurerats i AD FS:

Begärandeparametrar	Inställningar som konfigurerats i AD FS
wtrealm	$rp. Identifierare
wreply	En matchning av prefix eller jokertecken för $rp. WSFedEndpoint

SAML-begäranden

En SAML-begäran ser ut så här:

https://sts.contoso.com/adfs/ls/?SAMLRequest=EncodedValue&RelayState=cookie:29002348&SigAlg=http://www.w3.org/2000/09/Fxmldsig#rsa-sha1&Signature=Signature

Avkoda värdet för SAMLRequest-parametern med hjälp av alternativet "Från deflatedSAML" i Fiddler-textguiden. Det avkodade värdet ser ut så här:

<samlp:AuthnRequest ID="ID" Version="2.0" IssueInstant="2017-04-28T01:02:22.664Z" Destination="https://TestClaimProvider-Samlp-Only/adfs/ls" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" ForceAuthn="true" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://fs.contoso.com/adfs/services/trust</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>

Gör följande kontroller inom det avkodade värdet:

• Kontrollera om värdnamnet i värdet för Mål matchar AD FS-värdnamnet.
• Kontrollera om värdet för Utfärdaren matchar $rp.Identifier.

Ytterligare anteckningar för SAML:

• $rp. SamlEndpoints: Visar alla typer av SAML-slutpunkter. Svaret från AD FS skickas till motsvarande URL:er som konfigurerats i slutpunkterna. En SAML-slutpunkt kan använda omdirigerings-, post- eller artefaktbindningar för meddelandeöverföring. Alla dessa URL:er kan konfigureras i AD FS.
• $rp. SignedSamlRequestsRequired: Om värdet anges måste SAML-begäran som skickas från den förlitande parten signeras. Parametrarna "SigAlg" och "Signatur" måste finnas i begäran.
• $rp. RequestSigningCertificate: Det här är signeringscertifikatet som används för att generera signaturen för SAML-begäran. Kontrollera att certifikatet är giltigt och be programägaren att matcha certifikatet.

Kontrollera krypteringscertifikatet

Om $rp.EncryptClaims returnerar Aktiverad aktiveras förlitande partkryptering. AD FS använder krypteringscertifikatet för att kryptera anspråken. Gör följande kontroller:

• $rp. EncryptionCertificate: Använd det här kommandot för att hämta certifikatet och kontrollera om det är giltigt.
• $rp. EncryptionCertificateRevocationCheck: Använd det här kommandot för att kontrollera om certifikatet uppfyller kraven för återkallningskontroll.

De föregående två metoderna fungerar inte

Information om hur du fortsätter felsökningen finns i Använda dumptokenappen.

Alla användare påverkas inte av problemet och användaren kan inte komma åt någon av de förlitande parterna

I det här scenariot gör du följande kontroller.

Kontrollera om användaren är inaktiverad

Kontrollera användarstatusen i Windows PowerShell eller användargränssnittet. Om användaren är inaktiverad aktiverar du användaren.

Kontrollera användarstatusen med Windows PowerShell

1. Logga in på någon av domänkontrollanterna.

2. Öppna Windows PowerShell.

3. Kontrollera användarstatusen genom att köra följande kommando:

   Get-ADUser -Identity <samaccountname of the user> | Select Enabled
   

   

Kontrollera användarstatusen i användargränssnittet

1. Logga in på någon av domänkontrollanterna.

2. Öppna Active Directory - användare och datorer-hanteringskonsolen.

3. Klicka på noden Användare , högerklicka på användaren i den högra rutan och klicka sedan på Egenskaper.

4. Klicka på fliken Konto .

5. Under Kontoalternativ kontrollerar du om Kontot är inaktiverat är markerat.

   

6. Om alternativet är markerat avmarkerar du det.

Kontrollera om användaregenskaperna har uppdaterats nyligen

Om någon egenskap för användaren uppdateras i Active Directory resulterar det i en ändring i metadata för användarobjektet. Kontrollera användarmetadataobjektet för att se vilka egenskaper som uppdaterades nyligen. Om ändringar hittas kontrollerar du att de hämtas av de relaterade tjänsterna. Följ dessa steg för att kontrollera om det har skett egenskapsändringar för en användare:

1. Logga in på en domänkontrollant.

2. Öppna Windows PowerShell.

3. Hämta metadata för användarobjektet genom att köra följande kommando:
   repadmin /showobjmeta <destination DC> "user DN"

   Ett exempel på kommandot är:
   repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"

4. I metadata undersöker du kolumnen Tid/Datum för varje attribut för att få en ledtråd till en ändring. I följande exempel tar attributet userPrincipleName ett senare datum än de andra attributen som representerar en ändring av metadata för användarobjektet.

   

Kontrollera skogsförtroendet om användaren tillhör en annan skog

I en AD FS-miljö med flera skogar krävs ett dubbelriktat skogsförtroende mellan skogen där AD FS distribueras och de andra skogarna som använder AD FS-distributionen för autentisering. Följ dessa steg för att kontrollera om förtroendet mellan skogarna fungerar som förväntat:

1. Logga in på en domänkontrollant i skogen där AD FS distribueras.

2. Öppna hanteringskonsolen för Active Directory-domäner och förtroenden .

3. Högerklicka på domänen som innehåller det förtroende som du vill verifiera i hanteringskonsolen och klicka sedan på Egenskaper.

4. Klicka på fliken Förtroenden .

5. Under Domäner som är betrodda av den här domänen (utgående förtroenden) eller Domäner som litar på den här domänen (inkommande förtroenden) klickar du på det förtroende som ska verifieras och klickar sedan på Egenskaper.

6. Klicka på Verifiera.
   I dialogrutan Active Directory Domain Services väljer du något av alternativen.

   • Om du väljer Nej rekommenderar vi att du upprepar samma procedur för den ömsesidiga domänen.

   • Om du väljer Ja anger du en administrativ användarautentiseringsuppgift för den ömsesidiga domänen. Du behöver inte utföra samma procedur för den ömsesidiga domänen.

     

Om de här stegen inte hjälpte dig att lösa problemet fortsätter du felsökningen med stegen i avsnittet Inte alla användare påverkas av problemet och användaren kan komma åt några av de förlitande parterna .

Alla användare påverkas inte av problemet och användaren kan komma åt några av de förlitande parterna

I det här scenariot kontrollerar du om det här problemet uppstår i ett Microsoft Entra scenario. I så fall gör du dessa kontroller för att felsöka det här problemet. Om inte kan du läsa Använda dumptokenappen för att felsöka det här problemet.

Kontrollera om användaren är synkroniserad med Microsoft Entra ID

Om en användare försöker logga in på Microsoft Entra ID omdirigeras de till AD FS för autentisering för en federerad domän. En av de möjliga orsakerna till en misslyckad inloggning är att användaren ännu inte har synkroniserats till Microsoft Entra ID. Du kan se en loop från Microsoft Entra ID till Active Directory FS efter det första autentiseringsförsöket i AD FS. Följ dessa steg för att avgöra om användaren är synkroniserad med Microsoft Entra ID:

1. Ladda ned och installera Azure AD PowerShell-modulen för Windows PowerShell.
2. Öppna Windows PowerShell med alternativet Kör som administratör.
3. Initiera en anslutning till Microsoft Entra ID genom att köra följande kommando:
   Connect-MsolService
4. Ange den globala administratörens autentiseringsuppgifter för anslutningen.
5. Hämta listan över användare i Microsoft Entra ID genom att köra följande kommando:
   Get-MsolUser
6. Kontrollera om användaren finns i listan.

Om användaren inte finns i listan synkroniserar du användaren till Microsoft Entra ID.

Kontrollera immutableID och UPN i anspråksregeln för utfärdande

Microsoft Entra ID kräver oföränderligtID och användarens UPN för att autentisera användaren.

Administratörer kan använda Microsoft Entra Connect för automatisk hantering av AD FS-förtroende med Microsoft Entra ID. Om du inte hanterar förtroendet via Microsoft Entra Connect rekommenderar vi att du gör det genom att ladda ned Microsoft Entra Connect Microsoft Entra Connect aktiverar automatisk hantering av anspråksregler baserat på synkroniseringsinställningar.

Följ dessa steg för att kontrollera om anspråksreglerna för immutableID och UPN i AD FS matchar vad Microsoft Entra ID använder:

1. Hämta sourceAnchor och UPN i Microsoft Entra Connect.

   1. Öppna Microsoft Entra Anslut.

   2. Klicka på Visa aktuell konfiguration.

      

   3. På sidan Granska din lösning antecknar du värdena för SOURCE ANCHOR och USER PRINCIPAL NAME.

2. Kontrollera värdena för immutableID (sourceAnchor) och UPN i motsvarande anspråksregel som konfigurerats på AD FS-servern.

   1. Öppna AD FS-hanteringskonsolen på AD FS-servern.

   2. Klicka på Förlitande partsförtroenden.

   3. Högerklicka på det förlitande partsförtroendet med Microsoft Entra ID och klicka sedan på Redigera princip för utfärdande av anspråk.

   4. Öppna anspråksregeln för oföränderligt ID och UPN.

   5. Kontrollera om variablerna som efterfrågas för värden för immutableID och UPN är desamma som de som visas i Microsoft Entra Connect.

      

3. Om det finns en skillnad använder du någon av metoderna nedan:

   • Om AD FS hanteras av Microsoft Entra Connect återställer du det förlitande partförtroendet med hjälp av Microsoft Entra Connect.
   • Om AD FS inte hanteras av Microsoft Entra Connect korrigerar du anspråken med rätt attribut.

Om de här kontrollerna inte hjälpte dig att lösa problemet kan du läsa Använda dumptokenappen för att felsöka det här problemet.

Det här problemet uppstår på programsidan

Om certifikatet för tokensignering nyligen förnyades av AD FS kontrollerar du om det nya certifikatet hämtas av federationspartnern. Om AD FS använder ett tokendekrypteringscertifikat som också förnyades nyligen gör du samma kontroll också. Följ dessa steg för att kontrollera om det aktuella AD FS-tokensigneringscertifikatet på AD FS matchar det som finns på federationspartnern:

1. Hämta det aktuella tokensigneringscertifikatet på AD FS genom att köra följande kommando:

   Get-ADFSCertificate -CertificateType token-signing
   

2. I listan över certifikat som returneras letar du reda på det med IsPrimary = TRUE och antecknar tumavtrycket.

3. Hämta tumavtrycket för det aktuella tokensigneringscertifikatet på federationspartnern. Programägaren måste ange detta.

4. Jämför tumavtrycken för de två certifikaten.

Gör samma kontroll om AD FS använder ett förnyat tokendekrypteringscertifikat, förutom att kommandot för att hämta certifikatet för tokendekryptering på AD FS är följande:

Get-ADFSCertificate -CertificateType token-decrypting

Tumavtrycken för de två certifikaten matchar

Om tumavtrycken matchar kontrollerar du att partnern använder de nya AD FS-certifikaten.

Om det finns felmatchade certifikat kontrollerar du att partnern använder de nya certifikaten. Certifikat ingår i federationsmetadata som publiceras av AD FS-servern.

• Partner kan komma åt federationsmetadata

  Om partnerna kan komma åt federationsmetadata ber du partnerna att använda de nya certifikaten.

• Partnerna kan inte komma åt federationsmetadata

  I det här fallet måste du manuellt skicka partnerna de offentliga nycklarna för de nya certifikaten. Gör så här:

  1. Exportera de offentliga nycklarna som .cert-filer eller som .p7b-filer för att inkludera hela certifikatkedjorna.
  2. Skicka de offentliga nycklarna till partnerna.
  3. Be partnerna att använda de nya certifikaten.

Tumavtrycken för de två certifikaten matchar inte

Kontrollera sedan om det finns ett felmatchat tokensigneringsalgoritm. Gör så här:

1. Fastställ den algoritm som används av den förlitande parten genom att köra följande kommando:

   Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm
   

   Möjliga värden är SHA1 eller SHA256.

2. Kontrollera med programägaren om algoritmen som används på programsidan.

3. Kontrollera om de två algoritmerna matchar.

Om de två algoritmerna matchar kontrollerar du om namn-ID-formatet matchar vad programmet kräver.

1. På AD FS-servern dumpar du reglerna för utfärdandetransformering genom att köra följande kommando:

   (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules
   

2. Leta upp regeln som utfärdar NameIdentifier-anspråket. Om en sådan regel inte finns hoppar du över det här steget.

   Här är ett exempel på regeln:

   c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

   Lägg märke till formatet NameIdentifier i följande syntax:

   Properties["Property-type-URI"] = "ValueURI"

   Möjliga format visas nedan. Det första formatet är standardformatet.

   • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifie.
   • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
   • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
   • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

3. Be programägaren om det NameIdentifier-format som krävs av programmet.

4. Kontrollera om de två NameIdentifier-formaten matchar.

5. Om formaten inte matchar konfigurerar du nameIdentifier-anspråket så att det använder det format som programmet kräver. Gör så här:

   1. Öppna AD FS-hanteringskonsolen.
   2. Klicka på Förlitande partsförtroenden, välj lämplig federationspartner och klicka sedan på Redigera anspråksutfärdandeprincip i fönstret Åtgärder .
   3. Lägg till en ny regel om det inte finns någon regel för att utfärda NameIdentifier-anspråket eller uppdatera en befintlig regel. Välj Namn-ID för Inkommande anspråkstyp och ange sedan det format som programmet kräver.

   

Om de två algoritmerna matchar inte uppdaterar du signeringsalgoritmen som används av det förlitande partförtroendet.

1. Öppna AD FS-hanteringskonsolen.

2. Högerklicka på det förlitande partförtroendet och klicka sedan på Egenskaper.

3. På fliken Avancerat väljer du algoritmen för att matcha vad programmet kräver.

   

Om automatisk förnyelse av certifikat

Om certifikatet för tokensignering eller tokendekrypteringscertifikatet är självsignerat aktiveras AutoCertificateRollover som standard på dessa certifikat och AD FS hanterar automatisk förnyelse av certifikaten när de är nära att upphöra att gälla.

Följ dessa steg för att avgöra om du använder självsignerade certifikat:

1. Kör följande kommando:

   Get-ADFSCerticate -CertificateType "token-signing"
   

   

2. Granska certifikatattributen.

   Om både attributen Subject och Issuer börjar med "CN=ADFS Signing..." är certifikatet självsignerat och hanteras av AutoCertRollover.

Följ dessa steg för att bekräfta om certifikaten förnyas automatiskt:

1. Kör följande kommando:

   Get-ADFSProperties | FL AutoCertificateRollover
   

   

2. Granska attributet AutoCertificateRollover.

   • Om AutoCertificateRollover = TRUE genererar AD FS automatiskt nya certifikat (30 dagar före förfallodatumet som standard) och anger dem som primära certifikat (25 dagar före förfallodatum).
   • Om AutoCertificateRollover = FALSE måste du ersätta certifikaten manuellt.

Kontrollera de ADFS-relaterade komponenterna och tjänsterna

Den här artikeln beskriver hur du kontrollerar de ADFS-relaterade komponenterna och tjänsterna. De här stegen kan hjälpa dig när du felsöker inloggningsproblem (SSO) med Active Directory Federation Services (AD FS) (ADFS).

Kontrollera DNS

Åtkomst till ADFS bör peka direkt på någon av WAP-servrarna (Web Programproxy) eller lastbalanseraren framför WAP-servrarna. Gör följande kontroller:

• Pinga federationstjänstens namn (t.ex. fs.contoso.com). Kontrollera om IP-adressen som pinget matchas till är en av WAP-servrarna eller lastbalanseraren för WAP-servrarna.
• Kontrollera om det finns en A-post för federationstjänsten på DNS-servern. A-posten ska peka på någon av WAP-servrarna eller till lastbalanseraren för WAP-servrarna.

Om WAP inte implementeras i ditt scenario för extern åtkomst kontrollerar du om åtkomsten till ADFS pekar direkt till någon av ADFS-servrarna eller lastbalanseraren framför ADFS-servrarna:

• Pinga federationstjänstens namn (t.ex. fs.contoso.com). Kontrollera om IP-adressen som du får matchar någon av ADFS-servrarna eller lastbalanseraren för ADFS-servrarna.
• Kontrollera om det finns en A-post för federationstjänsten på DNS-servern. A-posten ska peka på en av ADFS-servrarna eller till lastbalanseraren för ADFS-servrarna.

Kontrollera lastbalanseraren om den används

Kontrollera om brandväggen blockerar trafik mellan:

• ADFS-servern och lastbalanseraren.
• WAP-servern (Web Programproxy) och lastbalanseraren om WAP används.

Om avsökningen är aktiverad i lastbalanseraren kontrollerar du följande:

• Om du kör Windows Server 2012 R2 kontrollerar du att samlad uppdatering från augusti 2014 är installerad.
• Kontrollera om port 80 är aktiverad i brandväggen på WAP-servrarna och ADFS-servrarna.
• Kontrollera att avsökningen har angetts för port 80 och för slutpunkten /adfs/probe.

Kontrollera brandväggsinställningarna

Kontrollera om inkommande trafik via TCP-port 443 är aktiverad:

• brandväggen mellan webbservern Programproxy och federationsservergruppen.
• brandväggen mellan klienterna och webbservern Programproxy.

Kontrollera om inkommande trafik via TCP-port 49443 är aktiverad i brandväggen mellan klienterna och webbservern Programproxy när följande villkor är uppfyllda:

• TLS-klientautentisering med X.509-certifikat är aktiverat.
• Du använder ADFS på Windows Server 2012 R2.

Kontrollera om slutpunkten är aktiverad på proxyn

ADFS tillhandahåller olika slutpunkter för olika funktioner och scenarier. Alla slutpunkter är inte aktiverade som standard. Så här kontrollerar du om slutpunkten är aktiverad på proxyn:

1. Öppna ADFS-hanteringskonsolen på ADFS-servern.

2. ExpanderaTjänstslutpunkter>.

3. Leta upp slutpunkten och kontrollera om statusen är aktiverad i kolumnen Proxyaktiverad .

   

Kontrollera proxyförtroenderelationen

Om Web Programproxy (WAP) distribueras måste proxyförtroenderelationen upprättas mellan WAP-servern och AD FS-servern. Kontrollera om proxyförtroenderelationen har upprättats eller börjar misslyckas någon gång.

Bakgrundsinformation

Proxyförtroenderelationen är klientcertifikatbaserad. När du kör guiden Web Programproxy efter installationen genererar guiden ett självsignerat klientcertifikat med de autentiseringsuppgifter som du angav i guiden. Sedan infogar guiden certifikatet i AD FS-konfigurationsdatabasen och lägger till det i certifikatarkivet AdfsTrustedDevices på AD FS-servern.

För all SSL-kommunikation använder http.sys följande prioritetsordning för SSL-certifikatbindningar för att matcha ett certifikat:

Prioritet	Namn	Parametrar	Beskrivning
1	IP	IP:port	Exakt IP- och portmatchning
2	SNI	Värdnamn:port	Exakt matchning av värdnamn (anslutningen måste ange SNI)
3	CCS	Port	Anropa centralt certifikatarkiv
4	Jokertecken för IPv6	Port	IPv6-jokerteckenmatchning (anslutningen måste vara IPv6)
5	IP-jokertecken	Port	Matchning av IP-jokertecken (anslutningen kan vara IPv4 eller IPv6)

AD FS 2012 R2 och senare är oberoende av Internet Information Services (IIS) och körs som en tjänst ovanpå http.sys. hostname:port SSL-certifikatbindningar används av AD FS. Under klientcertifikatautentisering skickar AD FS en lista över betrodda certifikat (CTL) baserat på certifikaten i AdfsTrustedDevices-arkivet. Om en SSL-certifikatbindning för AD FS-servern använder IP:port eller om CTL-arkivet inte är AdfsTrustedDevices, kanske proxyförtroenderelationen inte upprättas.

Hämta SSL-certifikatbindningarna för AD FS

Kör följande kommando på AD FS-servern i Windows PowerShell:
netsh http show sslcert

I listan över returnerade bindningar letar du upp dem med program-ID:t 5d89a20c-beab-4389-9447-324788eb944a. Här är ett exempel på en felfri bindning. Observera raden "Ctl Store Name".

Hostname:port : adfs.contoso.com:443
Certificate Hash : 3638de9b03a488341dfe32fc3ae5c480ee687793
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)  
Ctl Store Name : AdfsTrustedDevices
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled

Köra skript för att identifiera problem automatiskt

Kör följande skript för att automatiskt identifiera problem med proxyförtroenderelationen. Baserat på det identifierade problemet vidtar du åtgärden i enlighet med detta.

param
(
  [switch]$syncproxytrustcerts
)
function checkhttpsyscertbindings()
{
Write-Host; Write-Host("1 – Checking http.sys certificate bindings for potential issues")
$httpsslcertoutput = netsh http show sslcert
$adfsservicefqdn = (Get-AdfsProperties).HostName
$i = 1
$certbindingissuedetected = $false
While($i -lt $httpsslcertoutput.count)
{
        $ipport = $false
        $hostnameport = $false
        if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $true }
        elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) { $hostnameport = $true }
        ## Check for IP specific certificate bindings
        if ( ( $ipport -eq $true ) )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            if ( ( $ipbindingparsed[2].trim() -ne "0.0.0.0" ) -and ( $ipbindingparsed[3].trim() -eq "443") )
            {
                $warning = "There is an IP specific binding on IP " + $ipbindingparsed[2].trim() + " which may conflict with the AD FS port 443 cert binding." | Write-Warning
                $certbindingissuedetected = $true
            }
            $i = $i + 14
            continue
        }
        ## check that CTL Store is set for ADFS service binding
        elseif ( $hostnameport -eq $true )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            If ( ( $ipbindingparsed[2].trim() -eq $adfsservicefqdn ) -and ( $ipbindingparsed[3].trim() -eq "443") -and ( $httpsslcertoutput[$i+10].split(":")[1].trim() -ne "AdfsTrustedDevices" ) )
            {
                Write-Warning "ADFS Service binding does not have CTL Store Name set to AdfsTrustedDevices"
                $certbindingissuedetected = $true
            }
        $i = $i + 14
        continue
        }
    $i++
}
If ( $certbindingissuedetected -eq $false ) { Write-Host "Check Passed: No certificate binding issues detected" }
}
function checkadfstrusteddevicesstore()
{
## check for CA issued (non-self signed) certs in the AdfsTrustedDevices cert store
Write-Host; Write-Host "2 – Checking AdfsTrustedDevices cert store for non-self signed certificates"
$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse | Where-Object {$_.Issuer -ne $_.Subject}
If ( $certlist.count -gt 0 )
{
    Write-Warning "The following non-self signed certificates are present in the AdfsTrustedDevices store and should be removed"
    $certlist | Format-List Subject
}
Else { Write-Host "Check Passed: No non-self signed certs present in AdfsTrustedDevices cert store" }
}
function checkproxytrustcerts
{
    Param ([bool]$repair=$false)
    Write-Host; Write-Host("3 – Checking AdfsTrustedDevices cert store is in sync with ADFS Proxy Trust config")
    $doc = new-object Xml
    $doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config")
    $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
    $command = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"
    $cli = new-object System.Data.SqlClient.SqlConnection
    $cli.ConnectionString = $connString
    $cmd = new-object System.Data.SqlClient.SqlCommand
    $cmd.CommandText = $command
    $cmd.Connection = $cli
    $cli.Open()
    $configString = $cmd.ExecuteScalar()
    $configXml = new-object XML
    $configXml.LoadXml($configString)
    $rawCerts = $configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration._subjectNameIndex.KeyValueOfstringArrayOfX509Certificate29zVOn6VQ.Value.X509Certificate2
    #$ctl = dir cert:\LocalMachine\ADFSTrustedDevices
    $store = new-object System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices","LocalMachine")
    $store.open("MaxAllowed")
    $atLeastOneMismatch = $false
    $badCerts = @()
    foreach($rawCert in $rawCerts)
    {   
        $rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')
        $cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)
        $now = Get-Date
        if ( ($cert.NotBefore -lt $now) -and ($cert.NotAfter -gt $now))
        {
            $certThumbprint = $cert.Thumbprint
         $certSubject = $cert.Subject
         $ctlMatch = dir cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction SilentlyContinue
         if ($ctlMatch -eq $null)
         {
       $atLeastOneMismatch = $true
          Write-Warning "This cert is NOT in the CTL: $certThumbprint – $certSubject"
       if ($repair -eq $true)
       {
        write-Warning "Attempting to repair"
        $store.Add($cert)
        Write-Warning "Repair successful"
       }
                else
                {
                    Write-Warning ("Please install KB.2964735 or re-run script with -syncproxytrustcerts switch to add missing Proxy Trust certs to AdfsTrustedDevices cert store")
                }
         }
        }
    }
    $store.Close()
    if ($atLeastOneMismatch -eq $false)
    {
     Write-Host("Check Passed: No mismatched certs found. CTL is in sync with DB content")
    }
}
checkhttpsyscertbindings
checkadfstrusteddevicesstore
checkproxytrustcerts($syncproxytrustcerts)
Write-Host; Write-Host("All checks completed.")

Problem 1: Det finns en IP-specifik bindning

Bindningen kan vara i konflikt med AD FS-certifikatbindningen på port 443.

IP:portbindningen har högst prioritet. Om en IP:portbindning finns i AD FS SSL-certifikatbindningarna använder http.sys alltid certifikatet för bindningen för SSL-kommunikation. Lös problemet med hjälp av följande metoder.

1. Ta bort IP:portbindningen

   Tänk på att IP:portbindningen kan komma tillbaka när du har tagit bort den. Ett program som konfigurerats med den här IP:portbindningen kan till exempel automatiskt återskapa den vid nästa tjänststart.

2. Använda en annan IP-adress för AD FS SSL-kommunikation

   Om IP:portbindning krävs kan du matcha ADFS-tjänstens FQDN med en annan IP-adress som inte används i några bindningar. På så sätt använder http.sys bindningen Hostname:port för SSL-kommunikation.

3. Ange AdfsTrustedDevices som CTL Store för IP:portbindningen

   Detta är den sista utvägen om du inte kan använda metoderna ovan. Men det är bättre att förstå följande villkor innan du ändrar standard-CTL-arkivet till AdfsTrustedDevices:

   • Varför IP:portbindningen finns där.
   • Om bindningen är beroende av standard-CTL-arkivet för klientcertifikatautentisering.

Problem 2: AD FS-certifikatbindningen har inte ctl-lagringsnamnet inställt på AdfsTrustedDevices

Om Microsoft Entra Connect är installerat använder du Microsoft Entra Connect för att ställa in CTL Store Name på AdfsTrustedDevices för SSL-certifikatbindningarna på alla AD FS-servrar. Om Microsoft Entra Connect inte är installerat återskapar du AD FS-certifikatbindningarna genom att köra följande kommando på alla AD FS-servrar.

Set-AdfsSslCertificate -Thumbprint Thumbprint

Problem 3: Ett certifikat som inte är självsignerat finns i certifikatarkivet AdfsTrustedDevices

Om ett certifikat som utfärdats av certifikatutfärdare finns i ett certifikatarkiv där endast självsignerade certifikat normalt skulle finnas, skulle ctl som genereras från arkivet endast innehålla certifikatutfärdarcertifikatet. Certifikatarkivet AdfsTrustedDevices är ett sådant arkiv som bara ska ha självsignerade certifikat. Dessa certifikat är:

• MS-Organization-Access: Det självsignerade certifikat som används för att utfärda certifikat för arbetsplatsanslutning.
• ADFS-proxyförtroende: Certifikaten för varje webb-Programproxy-server.

Ta därför bort certifikatutfärdare som utfärdats av certifikatutfärdaren från certifikatarkivet AdfsTrustedDevices.

Problem 4: Installera KB2964735 eller kör skriptet igen med -syncproxytrustcerts

När en proxyförtroenderelation upprättas med en AD FS-server skrivs klientcertifikatet till AD FS-konfigurationsdatabasen och läggs till i certifikatarkivet AdfsTrustedDevices på AD FS-servern. För en AD FS-servergruppsdistribution förväntas klientcertifikatet synkroniseras till de andra AD FS-servrarna. Om synkroniseringen inte sker av någon anledning fungerar en proxyförtroenderelation endast mot DEN AD FS-server som förtroendet upprättades med, men inte mot de andra AD FS-servrarna.

Lös problemet genom att använda någon av följande metoder.

Metod 1

Installera uppdateringen som dokumenteras i KB-2964735 på alla AD FS-servrar. När uppdateringen har installerats förväntas en synkronisering av klientcertifikatet ske automatiskt.

Metod 2

Kör skriptet med växeln – syncproxytrustcerts för att synkronisera klientcertifikaten manuellt från AD FS-konfigurationsdatabasen till certifikatarkivet AdfsTrustedDevices. Skriptet ska köras på alla AD FS-servrar i servergruppen.

Problem 5: Alla kontroller skickas. Men problemet kvarstår

Kontrollera om det finns ett felmatchat tids- eller tidszonsfel. Om tiden matchar men tidszonen inte gör det kan proxyförtroenderelationen inte heller upprättas.

Kontrollera om det finns SSL-avslutning mellan AD FS-servern och WAP-servern

Om SSL-avslutning sker på en nätverksenhet mellan AD FS-servrar och WAP-servern bryts kommunikationen mellan AD FS och WAP eftersom kommunikationen baseras på klientcertifikatet.

Inaktivera SSL-avslutning på nätverksenheten mellan AD FS- och WAP-servrarna.

Använda dumptokenappen

DumpTokenappen är användbar när du felsöker problem med federationstjänsten och verifierar anpassade anspråksregler. Det är inte en officiell lösning utan en bra oberoende felsökningslösning som rekommenderas i felsökningssyfte.

Innan du använder dumptokenappen

Innan du använder dumptokenappen måste du:

1. Hämta information om den förlitande parten för det program som du vill komma åt. Om OAuth-autentisering implementeras hämtar du även OAuth-klientinformationen.
2. Konfigurera dumptokenappen.

Hämta den förlitande parten och OAuth-klientinformationen

Om du använder en konventionell förlitande part följer du dessa steg:

1. På AD FS-servern öppnar du Windows PowerShell med alternativet Kör som administratör.

2. Lägg till AD FS 2.0-komponenten i Windows PowerShell genom att köra följande kommando:

   Add-PSSnapin Microsoft.Adfs.PowerShell
   

3. Hämta den förlitande partens information genom att köra följande kommando:

   $rp = Get-AdfsRelyingPartyTrust RPName
   

4. Hämta OAuth-klientinformationen genom att köra följande kommando:

   $client = Get-AdfsClient ClientName
   

Om du använder funktionen Programgrupp i Windows Server 2016 följer du stegen nedan:

1. På AD FS-servern öppnar du Windows PowerShell med alternativet Kör som administratör.

2. Hämta den förlitande partens information genom att köra följande kommando:

   $rp = Get-AdfsWebApiApplication ResourceID
   

3. Om OAuth-klienten är offentlig hämtar du klientinformationen genom att köra följande kommando:

   $client = Get-AdfsNativeClientApplication ClientName
   

   Om OAuth-klienten är konfidentiell hämtar du klientinformationen genom att köra följande kommando:

   $client = Get-AdfsServerApplication ClientName
   

Konfigurera dumptokenappen

Om du vill konfigurera dumptokenappen kör du följande kommandon i fönstret Windows PowerShell:

$authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"
$issuanceRules = "x:[]=>issue(claim=x);"
$redirectUrl = "https://dumptoken.azurewebsites.net/default.aspx"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

Fortsätt nu med följande felsökningsmetoder. I slutet av varje metod kan du se om problemet är löst. Annars använder du en annan metod.

Felsökningsmetoder

Kontrollera auktoriseringsprincipen för att se om användaren påverkas

I den här metoden börjar du med att hämta principinformationen och använder sedan dumptokenappen för att diagnostisera principen för att se om användaren påverkas.

Hämta principinformationen

$rp. IssuanceAuthorizationRules visar auktoriseringsregler för den förlitande parten.

I Windows Server 2016 och senare versioner kan du använda $rp. AccessControlPolicyName för att konfigurera autentiserings- och auktoriseringsprincip. Om $rp. AccessControlPolicyName har ett värde. Det finns en princip för åtkomstkontroll som styr auktoriseringsprincipen. I så fall $rp. IssuanceAuthorizationRules är tom. Använd $rp. ResultantPolicy för att ta reda på information om åtkomstkontrollprincipen.

Om $rp. ResultantPolicy har inte information om principen. Titta på de faktiska anspråksreglerna. Följ dessa steg för att hämta anspråksreglerna:

1. Ange åtkomstkontrollprincipen till $null genom att köra följande kommando:
   Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
2. Hämta den förlitande partens information genom att köra följande kommando:
   $rp = Get-AdfsRelyingPartyTrust RPName
3. Kontrollera $rp.IssuanceAuthorizationRules och $rp. AdditionalAuthenticationRules.

Använd dumptokenappen för att diagnostisera auktoriseringsprincipen

1. Ställ in autentiseringsprincipen för dumptoken på samma sätt som den förlitande parten som misslyckas.

2. Låt användaren öppna någon av följande länkar beroende på vilken autentiseringsprincip du anger.

   • WS-Fed: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
   • SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
   • Framtvinga multifaktorautentisering: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

3. Logga in på sidan Sign-In.

Det du får är en uppsättning anspråk för användaren. Se om det finns något i auktoriseringsprincipen som uttryckligen nekar eller tillåter användaren baserat på dessa anspråk.

Kontrollera om ett saknat eller oväntat anspråk orsakar åtkomstnekning till resursen

1. Konfigurera anspråksreglerna i dumptokenappen så att de är desamma som anspråksreglerna för den förlitande parten som inte fungerar.

2. Konfigurera autentiseringsprincipen för dumptoken så att den är samma som den förlitande parten som inte fungerar.

3. Låt användaren öppna någon av följande länkar beroende på vilken autentiseringsprincip du anger.

   • WS-Fed: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
   • SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
   • Framtvinga multifaktorautentisering: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

4. Logga in på sidan Sign-In.

Det här är den uppsättning anspråk som den förlitande parten kommer att få för användaren. Om några anspråk saknas eller är oväntade kan du titta på utfärdandeprincipen för att ta reda på orsaken.

Om alla anspråk finns kontrollerar du med programägaren vilket anspråk som saknas eller är oväntat.

Kontrollera om ett enhetstillstånd krävs

Om auktoriseringsreglerna söker efter enhetsanspråk kontrollerar du om något av dessa enhetsanspråk saknas i listan över anspråk som du får från dumptokenappen. De anspråk som saknas kan blockera enhetsautentisering. Om du vill hämta anspråken från dumptokenappen följer du stegen i avsnittet Använd dumptokenappen för att diagnostisera auktoriseringsprincipen i metoden Kontrollera auktoriseringsprincip om användaren påverkades .

Följande är enhetsanspråken. Auktoriseringsreglerna kan använda vissa av dem.

• http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid
• http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname
• http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier
• http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype
• http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion
• http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged
• http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser
• http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown
• http://schemas.microsoft.com/2014/02/deviceusagetime
• http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant
• http://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype

Om det saknas ett anspråk följer du stegen i Konfigurera lokal villkorlig åtkomst med hjälp av registrerade enheter för att kontrollera att miljön är konfigurerad för enhetsautentisering.

Om alla anspråk finns kan du se om värdena för anspråken från dumptokenappen matchar de värden som krävs i auktoriseringsprincipen.