Konfigurieren der AD FS-Unterstützung für die Benutzerzertifikatauthentifizierung

2025-04-18
Gilt für:: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

In diesem Artikel wird beschrieben, wie Sie die Benutzerzertifikatauthentifizierung in Active Directory-Verbunddiensten (AD FS) aktivieren. Außerdem finden Sie Informationen zur Problembehandlung bei häufig auftretenden Problemen mit dieser Art der Authentifizierung.

Es gibt zwei Hauptanwendungsfälle für die Benutzerzertifikatauthentifizierung:

Benutzer verwenden Smartcards, um sich bei ihrem AD FS-System anzumelden.
Benutzer verwenden Zertifikate, die auf mobilen Geräten bereitgestellt werden.

Voraussetzungen

Ermitteln Sie den Modus der AD FS-Benutzerzertifikatauthentifizierung, den Sie mithilfe einer der in der AD FS-Unterstützung für alternative Hostnamenbindung zur Zertifikatauthentifizierung beschriebenen Methoden aktivieren möchten.
Stellen Sie sicher, dass Ihre Benutzerzertifikatvertrauenskette von allen AD FS- und Webanwendungsproxyservern (WAP) installiert und als vertrauenswürdig eingestuft wird, einschließlich aller Zwischenzertifizierungsstellen. Dies erfolgt in der Regel über das Gruppenrichtlinienobjekt (Group Policy Object, GPO) auf AD FS- und WAP-Servern.
Stellen Sie sicher, dass sich das Stammzertifikat der Vertrauenskette für Ihre Benutzerzertifikate im NTAuth-Speicher in Active Directory befindet.
Wenn Sie AD FS im alternativen Zertifikatauthentifizierungsmodus verwenden, stellen Sie sicher, dass Ihre AD FS- und WAP-Server SSL-Zertifikate (Secure Sockets Layer) besitzen, die den AD FS-Hostnamen mit dem Präfix "certauth" enthalten. Ein Beispiel ist certauth.fs.contoso.com. Stellen Sie außerdem sicher, dass der Datenverkehr zu diesem Hostnamen über die Firewall zulässig ist.
Wenn Sie die Zertifikatauthentifizierung über das Extranet verwenden, stellen Sie sicher, dass mindestens ein Zertifizierungsstelleninformationszugriff (Authority Information Access, AIA) und mindestens ein CRL-Verteilungspunkt (CRL Distribution Point, CDP) oder OCSP-Speicherort (Online Certificate Status Protocol) aus der liste, die in Ihren Zertifikaten angegeben ist, über das Internet zugänglich sind.
Wenn Sie AD FS für die Microsoft Entra-Zertifikatauthentifizierung konfigurieren, stellen Sie sicher, dass Sie die Microsoft Entra-Einstellungen und die AD FS-Anspruchsregeln konfiguriert haben, die für den Zertifikataussteller und die Seriennummer erforderlich sind.
Wenn Sie die Microsoft Entra-Zertifikatauthentifizierung für Exchange ActiveSync-Clients verwenden, muss das Clientzertifikat über die routingfähige E-Mail-Adresse des Benutzers in Exchange Online entweder im Wert "Prinzipalname " oder im RFC822-Namenswert des Felds " Alternativer Antragstellername " verfügen. Die Microsoft Entra-ID ordnet den RFC822-Wert dem Proxyadressen-Attribut im Verzeichnis zu.

Hinweis

AD FS unterstützt keine Benutzernamenhinweise mit Smartcard oder zertifikatbasierter Authentifizierung.

Aktivieren der Benutzerzertifikatauthentifizierung

Aktivieren Sie die Benutzerzertifikatauthentifizierung als Intranet- oder Extranetauthentifizierungsmethode in AD FS, indem Sie entweder die AD FS-Verwaltungskonsole oder das PowerShell-Cmdlet Set-AdfsGlobalAuthenticationPolicyverwenden.

Zu den optionalen Überlegungen gehören:

Wenn Sie zusätzlich zum EKU-Anspruchstyp Ansprüche basierend auf Zertifikatfeldern und Erweiterungen verwenden möchten, https://schemas.microsoft.com/2012/12/certificatecontext/extension/ekukonfigurieren Sie weitere Anspruchsdurchlaufregeln in der Active Directory-Anspruchsanbieter-Vertrauensstellung. Eine vollständige Liste der verfügbaren Zertifikatansprüche finden Sie weiter unten in diesem Artikel.
Wenn Sie den Zugriff basierend auf dem Zertifikattyp einschränken müssen, können Sie die zusätzlichen Eigenschaften für das Zertifikat in AD FS-Ausstellungsautorisierungsregeln für die Anwendung verwenden. Häufige Szenarien sind, nur Zertifikate zuzulassen, die von einem Mdm-Anbieter (Mobile Device Management) bereitgestellt werden, oder nur Smartcardzertifikate zulassen.

Wichtig

Kunden, die den Gerätecodefluss für die Authentifizierung verwenden und die Geräteauthentifizierung mithilfe eines anderen Identitätsanbieters als Microsoft Entra ID (z. B. AD FS) ausführen, können den gerätebasierten Zugriff für Microsoft Entra-Ressourcen nicht erzwingen. Beispielsweise können sie nicht nur verwaltete Geräte mit einem MDM-Dienst eines Drittanbieters zulassen.

Um den Zugriff auf Unternehmensressourcen in der Microsoft Entra-ID zu schützen und Datenverluste zu verhindern, konfigurieren Sie den gerätebasierten bedingten Zugriff von Microsoft Entra. Verwenden Sie beispielsweise Markieren des Geräts als kompatibel erforderlich, um die Kontrollberechtigung für den bedingten Microsoft Entra-Zugriff zuzuweisen.

Konfigurieren Sie zulässige Zertifizierungsstellen für Clientzertifikate mithilfe der Anleitung unter "Verwaltung vertrauenswürdiger Aussteller für die Clientauthentifizierung" in der technischen Übersicht zu Schannel SSP.
Erwägen Sie, Anmeldeseiten entsprechend den Anforderungen Ihrer Benutzer zu ändern, wenn sie die Zertifikatauthentifizierung durchführen. Ein gängiger Fall besteht darin, die Anmeldung mit Ihrem X509-Zertifikat zu einem benutzerfreundlicheren Element zu ändern.

Konfigurieren der nahtlosen Zertifikatauthentifizierung für den Chrome-Browser auf Windows-Desktops

Wenn ein Computer über mehrere Benutzerzertifikate (z. B. Wi-Fi Zertifikate) verfügt, die die Clientauthentifizierung erfüllen, fordert der Chrome-Browser auf Windows-Desktops Benutzer auf, das richtige Zertifikat auszuwählen. Diese Aufforderung kann für Benutzer verwirrend sein. Um diese Erfahrung zu optimieren, können Sie eine Richtlinie für Chrome festlegen, um automatisch das richtige Zertifikat auszuwählen.

Sie können diese Richtlinie manuell festlegen, indem Sie eine Registrierungsänderung vornehmen oder sie automatisch über GPO konfigurieren (um die Registrierungsschlüssel festzulegen). Dies erfordert, dass Ihre Benutzerclientzertifikate für die Authentifizierung bei AD FS unterschiedliche Aussteller für andere Anwendungsfälle haben.

Weitere Informationen zum Konfigurieren der Zertifikatauthentifizierung für Chrome finden Sie in der Chrome Enterprise-Richtlinienliste.

Problembehandlung bei der Zertifikatauthentifizierung

Verwenden Sie die folgenden Informationen, um häufige Probleme zu beheben, wenn Sie AD FS für die Zertifikatauthentifizierung für Benutzer konfiguriert haben.

Überprüfen, ob vertrauenswürdige Zertifikatherausgeber auf allen AD FS- und WAP-Servern ordnungsgemäß konfiguriert sind

Wenn vertrauenswürdige Zertifikatherausgeber nicht ordnungsgemäß konfiguriert sind, ist ein häufiges Symptom ein HTTP 204-Fehler: "Kein Inhalt von https://certauth.adfs.contoso.com."

AD FS verwendet das zugrunde liegende Windows-Betriebssystem, um den Besitz des Benutzerzertifikats zu beweisen und sicherzustellen, dass es einem vertrauenswürdigen Aussteller entspricht, indem die Zertifikatvertrauenskette überprüft wird. Damit das Zertifikat einem vertrauenswürdigen Aussteller entspricht, müssen Sie sicherstellen, dass alle Stamm- und Zwischenzertifizierungsstellen im lokalen Speicher für Computerzertifikat-Zertifizierungsstellen als vertrauenswürdige Aussteller konfiguriert sind.

Verwenden Sie das AD FS Diagnostics Analyzer-Tool, um dies automatisch zu überprüfen. Das Tool fragt alle Server ab und stellt sicher, dass die richtigen Zertifikate korrekt bereitgestellt werden.

Laden Sie das Tool herunter, und führen Sie es aus.
Laden Sie die Ergebnisse hoch, und überprüfen Sie alle Fehler.

Überprüfen, ob die Zertifikatauthentifizierung in der AD FS-Authentifizierungsrichtlinie aktiviert ist

AD FS führt die Benutzerzertifikatauthentifizierung standardmäßig auf Port 49443 mit demselben Hostnamen wie AD FS (Beispiel: ) aus. adfs.contoso.com Sie können AD FS auch so konfigurieren, dass Port 443 (der standardmäßige HTTPS-Port) mithilfe der alternativen SSL-Bindung verwendet wird. Die in dieser Konfiguration verwendete URL lautet certauth.<adfs-farm-name> jedoch (Beispiel: certauth.contoso.com). Weitere Informationen finden Sie unter AD FS-Unterstützung für alternative Hostnamenbindung für die Zertifikatauthentifizierung.

Hinweis

In AD FS unter Windows Server 2016 werden jetzt zwei Modi unterstützt. Der erste Modus verwendet den Host adfs.contoso.com mit den Ports 443 und 49443. Der zweite Modus verwendet Hosts adfs.contoso.com und certauth.adfs.contoso.com mit Port 443. Sie benötigen ein SSL-Zertifikat, das certauth.\<adfs-service-name> als alternativer Subjektname unterstützt. Sie können dies zum Zeitpunkt der Farmerstellung oder später über PowerShell tun.

Der häufigste Fall von Netzwerkkonnektivitätsproblemen besteht darin, dass eine Firewall falsch konfiguriert wurde und datenverkehr für die Benutzerzertifikatauthentifizierung blockiert wurde. Normalerweise wird beim Auftreten dieses Problems ein leerer Bildschirm oder ein 500 Serverfehler angezeigt. So beheben Sie dies:

Beachten Sie den Hostnamen und den Port, den Sie in AD FS konfiguriert haben.
Stellen Sie sicher, dass jede Firewall vor AD FS oder WAP so konfiguriert ist, dass die hostname:port Kombination für Ihre AD FS-Farm zulässig ist. Ihr Netzwerktechniker muss diesen Schritt ausführen.

Überprüfen der CRL-Konnektivität

Zertifikatsperrlisten (Certificate Revocation Lists, CRLs) sind Endpunkte, die in das Benutzerzertifikat codiert sind, um Laufzeitsperrprüfungen durchzuführen. Wenn beispielsweise ein Gerät, das ein Zertifikat enthält, gestohlen wird, kann ein Administrator das Zertifikat der Liste der widerrufenen Zertifikate hinzufügen. Jeder Endpunkt, der dieses Zertifikat zuvor akzeptiert hat, schlägt jetzt die Authentifizierung fehl.

Jeder AD FS- und WAP-Server muss den CRL-Endpunkt erreichen, um zu überprüfen, ob das zertifikat, das darin angezeigt wurde, noch gültig ist und nicht widerrufen wurde. Die CRL-Überprüfung kann über HTTPS, HTTP, LDAP oder OCSP erfolgen. Wenn AD FS- und WAP-Server den Endpunkt nicht erreichen können, schlägt die Authentifizierung fehl. Gehen Sie die folgenden Schritte durch, um das Problem zu beheben:

Wenden Sie sich an Ihren PKI-Techniker (Public Key Infrastructure), um zu ermitteln, welche CRL-Endpunkte verwendet werden, um Benutzerzertifikate aus Ihrem PKI-System zu widerrufen.
Stellen Sie auf jedem AD FS- und WAP-Server sicher, dass die CRL-Endpunkte über das verwendete Protokoll erreichbar sind (in der Regel HTTPS oder HTTP).
Aktivieren Sie für die erweiterte Überprüfung die CAPI2-Ereignisprotokollierung auf jedem AD FS- und WAP-Server.
Überprüfen Sie die CAPI2-Betriebsprotokolle auf die Ereignis-ID 41 (Sperrung überprüfen).
Suchen Sie nach <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>.

Tipp

Sie können auf einen einzelnen AD FS- oder WAP-Server abzielen, um die Problembehandlung zu erleichtern, indem Sie die DNS-Auflösung (Hostdatei unter Windows) so konfigurieren, dass sie auf einen bestimmten Server verweist. Mit dieser Technik können Sie die Ablaufverfolgung aktivieren, indem Sie einen Server als Ziel festlegen.

Überprüfen auf SNI-Probleme

AD FS erfordert Clientgeräte (oder Browser) und die Lastenausgleichsgeräte zur Unterstützung von Server Name Indication (SNI). Einige Clientgeräte (z. B. ältere Versionen von Android) unterstützen möglicherweise SNI nicht. Darüber hinaus unterstützen Lastenausgleichsgeräte möglicherweise keine SNI oder sind nicht für SNI konfiguriert. In diesen Fällen erhalten Sie wahrscheinlich Fehler bei der Benutzerzertifizierung.

Um dieses Problem zu beheben, arbeiten Sie mit Ihrem Netzwerktechniker zusammen, um sicherzustellen, dass das Lastenausgleichsmodul für AD FS und WAP SNI unterstützt. Wenn SNI nicht unterstützt werden kann, verwenden Sie die folgende Problemumgehung in AD FS:

Öffnen Sie ein Eingabeaufforderungsfenster mit erhöhten Rechten auf dem primären AD FS-Server.
Geben Sie Netsh http show sslcert ein.
Kopieren Sie die Anwendungs-GUID und den Zertifikathash des Verbunddiensts.
Geben Sie netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicationGUID} ein.

Überprüfen, ob das Clientgerät ordnungsgemäß mit dem Zertifikat bereitgestellt wurde

Möglicherweise stellen Sie fest, dass einige Geräte ordnungsgemäß funktionieren, andere Geräte jedoch nicht. In den meisten Fällen bedeutet dies, dass das Benutzerzertifikat auf einigen Clientgeräten nicht ordnungsgemäß bereitgestellt wurde. Folgen Sie diesen Schritten:

Wenn das Problem spezifisch für ein Android-Gerät ist, liegt die häufigste Ursache darin, dass die Zertifikatkette auf dem Gerät nicht vollständig vertrauenswürdig ist. Wenden Sie sich an Ihren MDM-Anbieter, um sicherzustellen, dass das Zertifikat ordnungsgemäß bereitgestellt wurde und die gesamte Kette auf dem Android-Gerät vollständig vertrauenswürdig ist.

Wenn das Problem für ein Windows-Gerät spezifisch ist, überprüfen Sie, ob das Zertifikat ordnungsgemäß bereitgestellt wird, indem Sie den Windows-Zertifikatspeicher für den angemeldeten Benutzer überprüfen (nicht auf System oder Computer).
Exportieren Sie das Clientbenutzerzertifikat in eine .cer Datei, und führen Sie den Befehl certutil -f -urlfetch -verify certificatefilename.ceraus.

Überprüfen, ob die TLS-Version zwischen AD FS/WAP-Servern und dem Clientgerät kompatibel ist

In seltenen Fällen wird ein Clientgerät aktualisiert, um nur eine höhere Version von TLS zu unterstützen (z. B. 1.3). Oder Sie haben möglicherweise das umgekehrte Problem, bei dem AD FS- und WAP-Server aktualisiert wurden, um nur eine höhere TLS-Version zu verwenden, die vom Clientgerät nicht unterstützt wird.

Sie können Online-SSL-Tools verwenden, um Ihre AD FS- und WAP-Server zu überprüfen und festzustellen, ob sie mit dem Gerät kompatibel sind. Weitere Informationen zum Steuern der TLS-Versionen finden Sie unter Verwalten von SSL/TLS-Protokollen und Verschlüsselungssammlungen für AD FS.

Überprüfen Sie, ob Microsoft Entra PromptLoginBehavior in Ihren Verbunddomäneneinstellungen ordnungsgemäß konfiguriert ist.

Viele Office 365-Anwendungen senden prompt=login an Microsoft Entra ID. Microsoft Entra-ID konvertiert sie standardmäßig in eine neue Kennwortanmeldung in AD FS. Selbst wenn Sie die Zertifikatauthentifizierung in AD FS konfiguriert haben, sehen Ihre Benutzer daher nur eine Kennwortanmeldung. So beheben Sie dieses Problem:

Rufen Sie die Verbunddomäneneinstellungen mithilfe des Get-MgDomainFederationConfiguration Cmdlets ab.
Stellen Sie sicher, dass der Parameter PromptLoginBehavior entweder auf Disabled oder NativeSupport gesetzt ist.

Weitere Informationen finden Sie im Artikel zur Unterstützung für den AD FS-Parameter „prompt=login“.

Zusätzliche Problembehandlung

Sollten Ihre CRL-Listen sehr lang sein, kann es in seltenen Fällen passieren, dass ein Timeout eintritt, wenn Sie versuchen, sie herunterzuladen. In diesem Fall müssen Sie MaxFieldLength und MaxRequestByte wie in Http.sys Registrierungseinstellungen für Windows beschrieben aktualisieren.

Referenz: Vollständige Liste der Benutzerzertifikatanspruchstypen und Beispielwerte

Anspruchstyp	Beispielwert
`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:1`8
`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`

Freigeben über