Delen via

AD FS-ondersteuning configureren voor verificatie van gebruikerscertificaten

In dit artikel wordt beschreven hoe u verificatie van gebruikerscertificaten inschakelt in Active Directory Federation Services (AD FS). Het biedt ook informatie over probleemoplossing voor veelvoorkomende problemen met dit type verificatie.

Er zijn twee hoofdgebruiksscenario's voor verificatie van gebruikerscertificaten:

  • Gebruikers gebruiken smartcards om zich aan te melden bij hun AD FS-systeem.
  • Gebruikers gebruiken certificaten die zijn ingericht voor mobiele apparaten.

Vereiste voorwaarden

  • Bepaal de modus van AD FS-gebruikerscertificaatverificatie die u wilt inschakelen met behulp van een van de modi die worden beschreven in AD FS-ondersteuning voor alternatieve hostnaambinding voor certificaatverificatie.
  • Zorg ervoor dat de vertrouwensketen van uw gebruikerscertificaat is geïnstalleerd en vertrouwd door alle WAP-servers (AD FS en Web Application Proxy), inclusief tussenliggende certificeringsinstanties. Dit doet u meestal via Groepsbeleidsobject (GPO) op AD FS- en WAP-servers.
  • Zorg ervoor dat het basiscertificaat van de vertrouwensketen voor uw gebruikerscertificaten zich in het NTAuth-archief in Active Directory bevindt.
  • Als u AD FS in de alternatieve verificatiemodus voor certificaten gebruikt, moet u ervoor zorgen dat uw AD FS- en WAP-servers SSL-certificaten (Secure Sockets Layer) hebben die de AD FS-hostnaam bevatten die is voorafgegaan door 'certauth'. Een voorbeeld is certauth.fs.contoso.com. Zorg er ook voor dat verkeer naar deze hostnaam is toegestaan via de firewall.
  • Als u certificaatverificatie gebruikt vanuit het extranet, zorg er dan voor dat ten minste één Authority Information Access (AIA) en ten minste één CRL-distributiepunt (CDP) of Online Certificate Status Protocol (OCSP) locatie vanuit de in uw certificaten opgegeven lijst toegankelijk is vanaf internet.
  • Als u AD FS voor Microsoft Entra-certificaatverificatie configureert, moet u ervoor zorgen dat u de Microsoft Entra-instellingen en de AD FS-claimregels hebt geconfigureerd die vereist zijn voor certificaatverlener en serienummer.
  • Als u Microsoft Entra-certificaatverificatie gebruikt voor Exchange ActiveSync-clients, moet het clientcertificaat het routeerbare e-mailadres van de gebruiker in Exchange Online hebben in de waarde Principal Name of de waarde RFC822 Name van het veld Alternatieve onderwerpnaam . Microsoft Entra ID wijst de RFC822-waarde toe aan het kenmerk proxyadres in de map.

Notitie

AD FS biedt geen ondersteuning voor hints voor gebruikersnaam met smartcard of verificatie op basis van certificaten.

Verificatie van gebruikerscertificaten inschakelen

Schakel verificatie van gebruikerscertificaten in als een intranet- of extranetverificatiemethode in AD FS met behulp van de AD FS-beheerconsole of de PowerShell-cmdlet Set-AdfsGlobalAuthenticationPolicy.

Optionele overwegingen zijn onder andere:

  • Als u claims wilt gebruiken die zijn gebaseerd op certificaatvelden en extensies naast het EKU-claimtype, configureert u meer regels voor claimpassthrough op de vertrouwensrelatie van de Active Directory-claimprovider. Zie de volledige lijst met beschikbare certificaatclaims verderop in dit artikel.

  • Als u de toegang wilt beperken op basis van het type certificaat, kunt u de aanvullende eigenschappen op het certificaat in AD FS-uitgifteautorisatieregels voor de toepassing gebruiken. Veelvoorkomende scenario's zijn om alleen certificaten toe te staan die zijn ingericht door een MDM-provider (Mobile Device Management) of alleen smartcard-certificaten toe te staan.

    Belangrijk

    Klanten die apparaatcodestroom gebruiken voor verificatie en apparaatverificatie uitvoeren met behulp van een andere id-provider dan Microsoft Entra-id (bijvoorbeeld AD FS) kunnen geen op apparaten gebaseerde toegang afdwingen voor Microsoft Entra-resources. Ze kunnen bijvoorbeeld niet alleen beheerde apparaten toestaan met behulp van een MDM-service van derden.

    Als u de toegang tot bedrijfsbronnen in Microsoft Entra ID wilt beveiligen en gegevenslekken wilt voorkomen, configureert u voorwaardelijke toegang op basis van Microsoft Entra-apparaten. Gebruik bijvoorbeeld Vereisen dat het apparaat wordt gemarkeerd als klacht om controle te verlenen in voorwaardelijke toegang van Microsoft Entra.

    Configureer toegestane verlenende certificeringsinstanties voor clientcertificaten met behulp van de richtlijnen onder 'Beheer van vertrouwde verleners voor clientverificatie' in het technische overzicht van Schannel-SSP.

  • Overweeg om aanmeldingspagina's aan te passen aan de behoeften van uw gebruikers wanneer ze certificaatverificatie uitvoeren. Een veelvoorkomend geval is het wijzigen van aanmelden met uw X509-certificaat in iets gebruiksvriendelijker.

Naadloze certificaatverificatie configureren voor de Chrome-browser op Windows-bureaubladen

Wanneer een computer meerdere gebruikerscertificaten (zoals Wi-Fi certificaten) heeft die voldoen aan de doeleinden van clientverificatie, wordt gebruikers in de Chrome-browser op Windows-bureaubladen gevraagd het juiste certificaat te selecteren. Deze prompt kan verwarrend zijn voor gebruikers. Als u deze ervaring wilt optimaliseren, kunt u een beleid voor Chrome instellen om automatisch het juiste certificaat te selecteren.

U kunt dit beleid handmatig instellen door een registerwijziging aan te brengen of u kunt dit automatisch configureren via GPO (om de registersleutels in te stellen). Hiervoor is vereist dat uw gebruikersclientcertificaten voor authenticatie met AD FS andere uitgevers hebben dan in andere gebruiksscenario's.

Zie de lijst met Chrome Enterprise-beleid voor meer informatie over het configureren van certificaatverificatie voor Chrome.

Problemen met certificaatverificatie oplossen

Gebruik de volgende informatie om veelvoorkomende problemen op te lossen wanneer u AD FS hebt geconfigureerd voor certificaatverificatie voor gebruikers.

Controleer of vertrouwde certificaatverleners correct zijn geconfigureerd op alle AD FS- en WAP-servers

Als vertrouwde certificaatverleners niet goed zijn geconfigureerd, is een veelvoorkomend symptoom een HTTP 204-fout: "Geen inhoud van https://certauth.adfs.contoso.com."

AD FS maakt gebruik van het onderliggende Windows-besturingssysteem om het bezit van het gebruikerscertificaat te bewijzen en ervoor te zorgen dat het overeenkomt met een vertrouwde verlener door de certificaatvertrouwensketen te valideren. Als u de vertrouwde verlener wilt vergelijken, moet u ervoor zorgen dat alle basis- en tussenliggende autoriteiten zijn geconfigureerd als vertrouwde verleners in het lokale archief voor computercertificeringsinstanties.

Als u dit automatisch wilt valideren, gebruikt u het hulpprogramma AD FS Diagnostics Analyzer. Het hulpprogramma vraagt alle servers op en zorgt ervoor dat de juiste certificaten correct worden ingericht.

  1. Download en voer het hulpprogramma uit.
  2. Upload de resultaten en controleer op eventuele fouten.

Controleer of certificaatverificatie is ingeschakeld in het AD FS-verificatiebeleid

AD FS voert standaard verificatie van gebruikerscertificaten uit op poort 49443 met dezelfde hostnaam als AD FS (bijvoorbeeld: adfs.contoso.com). U kunt AD FS ook configureren voor het gebruik van poort 443 (de standaard HTTPS-poort) met behulp van de alternatieve SSL-binding. De URL die in deze configuratie wordt gebruikt, is certauth.<adfs-farm-name> echter (bijvoorbeeld: certauth.contoso.com). Zie AD FS-ondersteuning voor alternatieve hostnaambinding voor certificaatverificatie voor meer informatie.

Notitie

In AD FS op Windows Server 2016 worden nu twee modi ondersteund. De eerste modus maakt gebruik van de host adfs.contoso.com met poorten 443 en 49443. De tweede modus maakt gebruik van hosts adfs.contoso.com en certauth.adfs.contoso.com met poort 443. U hebt een SSL-certificaat nodig voor ondersteuning certauth.\<adfs-service-name> als alternatieve onderwerpnaam. U kunt dit doen tijdens het aanmaken van de farm of later via PowerShell.

Het meest voorkomende geval van netwerkverbindingsproblemen is dat een firewall onjuist is geconfigureerd en verkeer voor verificatie van gebruikerscertificaten blokkeert. Normaal gesproken ziet u een leeg scherm of een 500-serverfout wanneer dit probleem optreedt. U kunt dit probleem als volgt oplossen:

  1. Noteer de hostnaam en poort die u hebt geconfigureerd in AD FS.
  2. Zorg ervoor dat elke firewall voor AD FS of WAP is geconfigureerd om de hostname:port-combinatie voor uw AD FS-farm toe te staan. Uw netwerktechnicus moet deze stap uitvoeren.

CRL-connectiviteit controleren

Certificaatintrekkingslijsten (CRL's) zijn eindpunten die zijn gecodeerd in het gebruikerscertificaat om runtime-intrekkingscontroles uit te voeren. Als een apparaat met een certificaat bijvoorbeeld wordt gestolen, kan een beheerder het certificaat toevoegen aan de lijst met ingetrokken certificaten. Elk eindpunt dat dit certificaat eerder heeft geaccepteerd, mislukt nu de verificatie.

Elke AD FS- en WAP-server moet het CRL-eindpunt bereiken om te controleren of het certificaat dat aan de server is gepresenteerd nog steeds geldig is en niet is ingetrokken. CRL-validatie kan plaatsvinden via HTTPS, HTTP, LDAP of OCSP. Als AD FS- en WAP-servers het eindpunt niet kunnen bereiken, mislukt de verificatie. Gebruik de volgende stappen om problemen op te lossen:

  1. Neem contact op met uw PKI-engineer (Public Key Infrastructure) om te bepalen welke CRL-eindpunten worden gebruikt om gebruikerscertificaten van uw PKI-systeem in te trekken.
  2. Controleer op elke AD FS- en WAP-server of de CRL-eindpunten bereikbaar zijn via het gebruikte protocol (meestal HTTPS of HTTP).
  3. Schakel voor geavanceerde validatie CAPI2-gebeurtenislogboekregistratie in op elke AD FS- en WAP-server.
  4. Controleer op gebeurtenis-id 41 (intrekkingsverificatie) in de operationele CAPI2-logboeken.
  5. Controleer op <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>.

Hint

U kunt zich richten op één AD FS- of WAP-server voor eenvoudigere probleemoplossing door DNS-resolutie (hosts-bestand in Windows) te configureren om naar een specifieke server te verwijzen. Met deze techniek kunt u tracering inschakelen door een server te targeten.

Controleren op SNI-problemen

AD FS vereist clientapparaten (of browsers) en de load balancers ter ondersteuning van servernaamindicatie (SNI). Sommige clientapparaten (bijvoorbeeld oudere versies van Android) bieden mogelijk geen ondersteuning voor SNI. Daarnaast bieden load balancers mogelijk geen ondersteuning voor SNI of zijn ze mogelijk niet geconfigureerd voor SNI. In deze gevallen krijgt u waarschijnlijk fouten met gebruikerscertificering.

U kunt dit probleem oplossen door samen te werken met uw netwerktechnicus om ervoor te zorgen dat de load balancer voor AD FS en WAP SNI ondersteunt. Als SNI niet kan worden ondersteund, gebruikt u de volgende tijdelijke oplossing in AD FS:

  1. Open een opdrachtpromptvenster met verhoogde bevoegdheid op de primaire AD FS-server.
  2. Voer Netsh http show sslcertin.
  3. Kopieer de toepassings-GUID en certificaat-hash van de federation-service.
  4. Voer netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicationGUID}in.

Controleer of het clientapparaat correct is voorzien van het certificaat

Mogelijk merkt u dat sommige apparaten correct werken, maar andere apparaten niet. In de meeste gevallen betekent dit dat het gebruikerscertificaat niet correct is ingericht op sommige clientapparaten. Volg deze stappen:

  1. Als het probleem specifiek is voor een Android-apparaat, is de meest voorkomende oorzaak dat de certificaatketen niet volledig wordt vertrouwd op het apparaat. Raadpleeg uw MDM-leverancier om ervoor te zorgen dat het certificaat correct is ingericht en dat de volledige keten volledig wordt vertrouwd op het Android-apparaat.

    Als het probleem specifiek is voor een Windows-apparaat, controleert u of het certificaat correct is ingericht door het Windows-certificaatarchief te controleren op de aangemelde gebruiker (niet op het systeem of de computer).

  2. Exporteer het certificaat van de clientgebruiker naar een .cer-bestand en voer de opdracht certutil -f -urlfetch -verify certificatefilename.ceruit.

Controleer of de TLS-versie compatibel is tussen AD FS/WAP-servers en het clientapparaat

In zeldzame gevallen wordt een clientapparaat bijgewerkt ter ondersteuning van alleen een hogere versie van TLS (bijvoorbeeld 1.3). Of u hebt mogelijk het omgekeerde probleem, waarbij AD FS- en WAP-servers zijn bijgewerkt om alleen een hogere TLS-versie te gebruiken die het clientapparaat niet ondersteunt.

U kunt online SSL-hulpprogramma's gebruiken om uw AD FS- en WAP-servers te controleren en te zien of ze compatibel zijn met het apparaat. Zie Ssl/TLS-protocollen en coderingssuites beheren voor AD FS voor meer informatie over het beheren van de TLS-versies.

Controleer of Microsoft Entra PromptLoginBehavior correct is geconfigureerd in uw federatieve domeininstellingen

Veel Office 365-toepassingen verzenden prompt=login naar Microsoft Entra-id. Microsoft Entra-id converteert deze standaard naar een nieuwe wachtwoordaanmelding naar AD FS. Als gevolg hiervan, zelfs als u certificaatverificatie hebt geconfigureerd in AD FS, zien uw gebruikers alleen een wachtwoordaanmelding. Ga als volgt te werk om dit probleem op te lossen:

  1. Haal de federatieve domeininstellingen op met behulp van de Get-MgDomainFederationConfiguration cmdlet.
  2. Zorg ervoor dat de PromptLoginBehavior parameter is ingesteld op Disabled of NativeSupport.

Zie ad FS prompt=login parameter support voor meer informatie.

Andere problemen oplossen

Als uw CRL-lijsten in zeldzame gevallen erg lang zijn, kan er een time-out optreden bij het downloaden. In dit geval moet u bijwerken MaxFieldLength en MaxRequestByte zoals beschreven in Http.sys registerinstellingen voor Windows.

Naslaginformatie: Volledige lijst met claimtypen voor gebruikerscertificaten en voorbeeldwaarden

Claim type Voorbeeldwaarde
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