Läs på engelska

Dela via

Konfigurera AD FS-stöd för autentisering med användarcertifikat

I den här artikeln beskrivs hur du aktiverar autentisering av användarcertifikat i Active Directory Federation Services (AD FS). Den innehåller även felsökningsinformation för vanliga problem med den här typen av autentisering.

Det finns två huvudsakliga användningsfall för autentisering av användarcertifikat:

  • Användare använder smartkort för att logga in mot sitt AD FS-system.
  • Användare använder certifikat som har tilldelats till mobila enheter.

Förutsättningar

  • Fastställa läget för AD FS-användarcertifikatautentisering som du vill aktivera med hjälp av något av de lägen som beskrivs i AD FS-stöd för alternativ värdnamnsbindning för certifikatautentisering.
  • Se till att kedjan för användarcertifikatförtroende är installerad och betrodd av alla AD FS- och WAP-servrar (Web Application Proxy), inklusive mellanliggande certifikatutfärdare. Du gör vanligtvis detta via grupprincipobjekt (GPO) på AD FS- och WAP-servrar.
  • Kontrollera att rotcertifikatet för förtroendekedjan för dina användarcertifikat finns i NTAuth-arkivet i Active Directory.
  • Om du använder AD FS i alternativt certifikatautentiseringsläge kontrollerar du att AD FS- och WAP-servrarna har SSL-certifikat (Secure Sockets Layer) som innehåller AD FS-värdnamnet med prefixet "certauth". Ett exempel är certauth.fs.contoso.com. Se också till att trafik till det här värdnamnet tillåts via brandväggen.
  • Om du använder certifikatautentisering från extranätet kontrollerar du att minst en AIA(Authority Information Access) och minst en CRL-distributionsplats (CDP) eller OCSP-plats (Online Certificate Status Protocol) från listan som anges i dina certifikat är tillgängliga från Internet.
  • Om du konfigurerar AD FS för Microsoft Entra-certifikatautentisering, kontrollera att du har konfigurerat både Microsoft Entra-inställningar och AD FS-anspråksregler som krävs för certifikatutfärdare och serienummer.
  • Om du använder Microsoft Entra-certifikatautentisering för Exchange ActiveSync-klienter måste klientcertifikatet ha användarens dirigerbara e-postadress i Exchange Online antingen i Principal Name-värdet eller i RFC822 Name-värdet för fältets Ämnesalternativt namn. Microsoft Entra-ID mappar RFC822-värdet till proxyadressattributet i katalogen.

Anteckning

AD FS stöder inte uppmaningar om användarnamn med smartkort eller certifikatbaserad autentisering.

Aktivera autentisering av användarcertifikat

Aktivera autentisering av användarcertifikat som en autentiseringsmetod för intranät eller extranät i AD FS med hjälp av antingen AD FS-hanteringskonsolen eller PowerShell-cmdleten Set-AdfsGlobalAuthenticationPolicy.

Valfria överväganden är:

  • Om du vill använda anspråk baserat på certifikatfält och tillägg utöver EKU-anspråkstypen https://schemas.microsoft.com/2012/12/certificatecontext/extension/ekukonfigurerar du fler regler för genomströmning av anspråk i Active Directory-anspråksproviderns förtroende. Se den fullständiga listan över tillgängliga anspråk på certifikat senare i den här artikeln.

  • Om du behöver begränsa åtkomsten baserat på typen av certifikat kan du använda de ytterligare egenskaperna för certifikatet i AD FS-utfärdandeauktoriseringsregler för programmet. Vanliga scenarier är att endast tillåta certifikat som etablerats av en MDM-provider (hantering av mobila enheter) eller att endast tillåta smartkortcertifikat.

    Viktigt

    Kunder som använder enhetskodflöde för autentisering och utför enhetsautentisering med hjälp av en annan identitetsprovider än Microsoft Entra-ID (till exempel AD FS) kan inte framtvinga enhetsbaserad åtkomst för Microsoft Entra-resurser. De kan till exempel inte bara tillåta hanterade enheter med hjälp av en MDM-tjänst från tredje part.

    Konfigurera Microsoft Entra-enhetsbaserad villkorlig åtkomst för att skydda åtkomsten till företagsresurser i Microsoft Entra-ID och förhindra dataläckage. Använd till exempel Kräv att enheten markeras som klagomål för att bevilja kontroll i Villkorsstyrd åtkomst i Microsoft Entra.

    Konfigurera tillåtna utfärdare av certifikat för klientcertifikat med hjälp av vägledningen under "Hantering av betrodda utfärdare för klientautentisering" i Schannel SSP teknisk översikt.

  • Överväg att ändra inloggningssidor så att de passar användarnas behov när de utför certifikatautentisering. Ett vanligt fall är att ändra Logga in med ditt X509-certifikat till något mer användarvänligt.

Konfigurera sömlös certifikatautentisering för Webbläsaren Chrome på Windows-skrivbord

När en dator har flera användarcertifikat (till exempel Wi-Fi certifikat) som uppfyller klientautentiseringssyften uppmanas användarna att välja rätt certifikat i Webbläsaren Chrome på Windows-skrivbord. Den här uppmaningen kan vara förvirrande för användarna. För att optimera den här upplevelsen kan du ange en princip för Chrome för att automatiskt välja rätt certifikat.

Du kan ange den här principen manuellt genom att göra en registerändring, eller så kan du konfigurera den automatiskt via grupprincipobjektet (för att ange registernycklarna). Detta kräver att dina användarklientcertifikat för autentisering mot AD FS har distinkta utfärdare från andra användningsfall.

Mer information om hur du konfigurerar certifikatautentisering för Chrome finns i Chrome Enterprise-principlista.

Felsöka problem med certifikatautentisering

Använd följande information för att felsöka vanliga problem när du har konfigurerat AD FS för certifikatautentisering för användare.

Kontrollera om betrodda certifikatutfärdare är korrekt konfigurerade på alla AD FS- och WAP-servrar

Om betrodda certifikatutfärdare inte är korrekt konfigurerade är ett vanligt symptom ett HTTP 204-fel: "Inget innehåll från https://certauth.adfs.contoso.com."

AD FS använder det underliggande Windows-operativsystemet för att bevisa innehav av användarcertifikatet och se till att det matchar en betrodd utfärdare genom att validera certifikatförtroendekedjan. För att matcha den betrodda utfärdaren måste du se till att alla rot- och mellanliggande certifikatutfärdare är konfigurerade som betrodda utfärdare i den lokala lagringen för datorcertifikatutfärdare.

Om du vill verifiera detta automatiskt använder du verktyget AD FS Diagnostics Analyzer. Verktyget förfrågar alla servrar och säkerställer att rätt certifikat etableras korrekt.

  1. Ladda ned och kör verktyget.
  2. Ladda upp resultaten och granska eventuella fel.

Kontrollera om certifikatautentisering är aktiverat i AD FS-autentiseringsprincipen

AD FS utför autentisering av användarcertifikat som standard på port 49443 med samma värdnamn som AD FS (exempel: adfs.contoso.com). Du kan också konfigurera AD FS att använda port 443 (https-standardporten) med hjälp av den alternativa SSL-bindningen. Url:en som används i den här konfigurationen är dock certauth.<adfs-farm-name> (exempel: certauth.contoso.com). Mer information finns i AD FS-stöd för alternativ värdnamnsbindning för certifikatautentisering.

Anteckning

I AD FS på Windows Server 2016 stöds nu två lägen. I det första läget används värden adfs.contoso.com med portarna 443 och 49443. Det andra läget använder värdar adfs.contoso.com och certauth.adfs.contoso.com med port 443. Du behöver ett SSL-certifikat för att stödja certauth.\<adfs-service-name> som ett alternativt ämnesnamn. Du kan göra detta när farmen skapas eller senare via PowerShell.

Det vanligaste fallet med problem med nätverksanslutningen är att en brandvägg har konfigurerats felaktigt och blockerar trafik för autentisering med användarcertifikat. Vanligtvis visas en tom skärm eller ett 500-serverfel när det här problemet uppstår. Så här åtgärdar du det:

  1. Observera värdnamnet och porten som du konfigurerade i AD FS.
  2. Se till att alla brandväggar framför AD FS eller WAP har konfigurerats för att tillåta kombinationen hostname:port för din AD FS-servergrupp. Nätverksteknikern måste utföra det här steget.

Kontrollera CRL-anslutningen

Listor över återkallade certifikat (CRL:er) är endpoints som är inbäddade i användarcertifikatet för att genomföra kontroll av återkallning vid körning. Om en enhet som innehåller ett certifikat till exempel blir stulen kan en administratör lägga till certifikatet i listan över återkallade certifikat. Alla slutpunkter som accepterade det här certifikatet tidigare misslyckas nu med autentiseringen.

Varje AD FS- och WAP-server måste nå CRL-slutpunkten för att verifiera om certifikatet som visades för den fortfarande är giltigt och inte har återkallats. CRL-validering kan ske via HTTPS, HTTP, LDAP eller OCSP. Om AD FS- och WAP-servrar inte kan nå slutpunkten misslyckas autentiseringen. Använd följande steg för att felsöka det:

  1. Kontakta PKI-teknikern (Public Key Infrastructure) för att avgöra vilka CRL-slutpunkter som används för att återkalla användarcertifikat från PKI-systemet.
  2. På varje AD FS- och WAP-server kontrollerar du att CRL-slutpunkterna kan nås via det protokoll som används (vanligtvis HTTPS eller HTTP).
  3. För avancerad validering aktivera CAPI2-händelseloggning på varje AD FS- och WAP-server.
  4. Sök efter händelse-ID 41 (verifiera återkallande) i CAPI2-driftloggarna.
  5. Sök efter <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>.

Dricks

Du kan fokusera på en enskild AD FS- eller WAP-server för enklare felsökning genom att konfigurera DNS-upplösning (i värdfilen på Windows) så att den pekar på en specifik server. Med den här tekniken kan du aktivera spårning genom att rikta in dig på en server.

Sök efter SNI-problem

AD FS kräver klientenheter (eller webbläsare) och lastbalanserarna för att stödja SNI (Server Name Indication). Vissa klientenheter (till exempel äldre versioner av Android) kanske inte stöder SNI. Dessutom kanske lastbalanserare inte stöder SNI eller kanske inte har konfigurerats för SNI. I dessa fall kommer du förmodligen att få fel i användarcertifieringen.

Du kan åtgärda problemet genom att samarbeta med nätverksteknikern för att säkerställa att lastbalanseraren för AD FS och WAP stöder SNI. Om SNI inte kan stödjas använder du följande lösning i AD FS:

  1. Öppna ett upphöjt kommandotolkfönster på den primära AD FS-servern.
  2. Ange Netsh http show sslcert.
  3. Kopiera programmets GUID och certifikatshash för federationstjänsten.
  4. Ange netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicationGUID}.

Kontrollera om klientenheten har konfigurerats korrekt med certifikatet

Du kanske märker att vissa enheter fungerar korrekt, men andra enheter fungerar inte. I de flesta fall innebär det att användarcertifikatet inte har etablerats korrekt på vissa klientenheter. Följ dessa steg:

  1. Om problemet är specifikt för en Android-enhet är den vanligaste orsaken att certifikatkedjan inte är helt betrodd på enheten. Kontakta din MDM-leverantör för att säkerställa att certifikatet har tillhandahållits korrekt och att hela kedjan är fullt betrodd på Android-enheten.

    Om problemet är specifikt för en Windows-enhet kontrollerar du om certifikatet har etablerats korrekt genom att kontrollera Windows-certifikatarkivet för den inloggade användaren (inte system eller dator).

  2. Exportera klientanvändarcertifikatet till en .cer-fil och kör kommandot certutil -f -urlfetch -verify certificatefilename.cer.

Kontrollera om TLS-versionen är kompatibel mellan AD FS/WAP-servrar och klientenheten

I sällsynta fall uppdateras en klientenhet för att endast stödja en högre version av TLS (till exempel 1.3). Eller så kan du ha det omvända problemet, där AD FS- och WAP-servrar uppdaterades för att endast använda en högre TLS-version som klientenheten inte stöder.

Du kan använda online-SSL-verktyg för att kontrollera dina AD FS- och WAP-servrar och se om de är kompatibla med enheten. Mer information om hur du styr TLS-versionerna finns i Hantera SSL/TLS-protokoll och chiffersviter för AD FS.

Kontrollera om Microsoft Entra PromptLoginBehavior har konfigurerats korrekt i dina federerade domäninställningar

Många Office 365-program skickar prompt=login till Microsoft Entra-ID. Microsoft Entra-ID konverterar som standard det till en ny lösenordsinloggning till AD FS. Det innebär att även om du har konfigurerat certifikatautentisering i AD FS ser användarna bara en lösenordsinloggning. Så här åtgärdar du problemet:

  1. Hämta inställningarna för federerad domän med hjälp av cmdleten Get-MgDomainFederationConfiguration.
  2. Kontrollera att parametern PromptLoginBehavior är inställd på antingen Disabled eller NativeSupport.

Mer information finns i AD FS prompt=login parameter support.

Ytterligare felsökning

Om crl-listorna är mycket långa kan de i ett sällsynt fall nå en tidsgräns när de försöker ladda ner. I det här fallet måste du uppdatera MaxFieldLength och MaxRequestByte enligt beskrivningen i Http.sys registerinställningar för Windows.

Referens: Fullständig lista över anspråkstyper för användarcertifikat och exempelvärden

Anspråkstyp Exempelvärde
http://schemas.microsoft.com/2012/12/certificatecontext/field/x509version 3
http://schemas.microsoft.com/2012/12/certificatecontext/field/signaturealgorithm sha256RSA
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/notbefore 12/05/2016 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/notafter 12/05/2017 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/subject E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/subjectname E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/rawdata {Base64 encoded digital certificate data}
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage DigitalSignature
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage KeyEncipherment
http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier 9D11941EC06FACCCCB1B116B56AA97F3987D620A
http://schemas.microsoft.com/2012/12/certificatecontext/extension/authoritykeyidentifier KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3 0b 25 7f
http://schemas.microsoft.com/2012/12/certificatecontext/extension/certificatetemplatename User
http://schemas.microsoft.com/2012/12/certificatecontext/extension/san Other Name:Principal Name=user@contoso.com, RFC822 Name=user@contoso.com
http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku 1.3.6.1.4.1.311.10.3.4