Konfigurieren Sie die AD FS-Unterstützung für die Benutzerzertifikat-Authentifizierung

  • Artikel

In diesem Artikel wird beschrieben, wie Sie die Benutzerzertifikatauthentifizierung in Active Directory-Verbunddiensten (AD FS) aktivieren. Außerdem werden Informationen zur Problembehandlung für häufige Probleme mit dieser Art der Authentifizierung bereitgestellt.

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

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

Voraussetzungen

  • Ermitteln Sie den Modus der AD FS-Benutzerzertifikatauthentifizierung, den Sie aktivieren möchten, indem Sie einen der unter AD FS-Unterstützung für die alternative Hostnamenbindung für die Zertifikatauthentifizierung beschriebenen Modi verwenden.
  • Stellen Sie sicher, dass Ihre Vertrauenskette für Benutzerzertifikate installiert und von allen AD FS- und Webanwendungsproxy-Servern (Web Application Proxy, WAP) als vertrauenswürdig eingestuft wurde (einschließlich aller Zwischenzertifizierungsstellen). Dies erfolgt in der Regel über Gruppenrichtlinienobjekte (Group Policy Objects, GPOs) 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 über SSL-Zertifikate (Secure Sockets Layer) verfügen, die den AD FS-Hostnamen mit dem Präfix „certauth“ enthalten. Ein Beispiel hierfür ist certauth.fs.contoso.com. Stellen Sie außerdem sicher, dass Datenverkehr an diesen Hostnamen über die Firewall zugelassen wird.
  • Wenn Sie die Zertifikatauthentifizierung über das Extranet verwenden, stellen Sie sicher, dass mindestens eine Berechtigung für den Zugriff auf Zertifizierungsstelleninfos (Authority Information Access, AIA) und mindestens ein Verteilungspunkt für die Zertifikatssperrliste (CRL Distribution Point, CDP) oder OCSP-Speicherort (Online Certificate Status Protocol) aus der in Ihren Zertifikaten angegebenen Liste über das Internet zugänglich ist.
  • Wenn Sie AD FS für die Microsoft Entra-Zertifikatauthentifizierung (Azure AD) konfigurieren, stellen Sie sicher, dass Sie die Microsoft Entra-Einstellungen und die AD FS-Anspruchsregeln konfiguriert haben, die für Zertifikataussteller und Seriennummern erforderlich sind.
  • Wenn Sie die Microsoft Entra-Zertifikatauthentifizierung für Exchange ActiveSync-Clients verwenden, muss das Clientzertifikat die routingfähige E-Mail-Adresse der Benutzer*innen in Exchange Online entweder im Wert Prinzipalname oder dem Wert RFC822-Name des Felds Alternativer Antragstellername enthalten. Microsoft Entra ID ordnet den RFC822-Wert dem Attribut für die Proxyadresse innerhalb des Verzeichnisses 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-AdfsGlobalAuthenticationPolicy verwenden.

Hier finden Sie optionale Überlegungen:

  • Wenn Sie Ansprüche basierend auf Zertifikatfeldern und Erweiterungen zusätzlich zum EKU-Anspruchstyp https://schemas.microsoft.com/2012/12/certificatecontext/extension/eku verwenden möchten, konfigurieren Sie weitere Passthrough-Regeln für Ansprüche für die Active Directory-Anspruchsanbieter-Vertrauensstellung. Weitere Informationen finden Sie im Abschnitt mit einer kompletten Liste der verfügbaren Zertifikatansprüche weiter unten.

  • Wenn Sie den Zugriff basierend auf dem Zertifikattyp einschränken müssen, können Sie die zusätzlichen Eigenschaften für das Zertifikat in den AD FS-Ausstellungsautorisierungsregeln für die Anwendung verwenden. Oft werden nur Zertifikate zugelassen, die von einem Anbieter für die Verwaltung mobiler Geräte (Mobile Device Management, MDM) bereitgestellt werden, oder es sind nur Smartcardzertifikate zulässig.

    Wichtig

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

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

    Konfigurieren Sie die zulässigen Ausstellerzertifikat-Zertifizierungsstellen für Clientzertifikate, indem Sie die Anleitung unter „Verwaltung vertrauenswürdiger Aussteller für die Clientauthentifizierung“ in der technischen Übersicht über den Schannel-SSP befolgen.

  • Erwägen Sie, Anmeldeseiten an die Anforderungen Ihrer Benutzer*innen anzupassen, wenn diese die Zertifikatauthentifizierung durchführen. Oft wird die Option für die Anmeldung mit einem X509-Zertifikat in eine benutzerfreundlichere Option geändert.

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

Wenn ein Computer über mehrere Benutzerzertifikate (z. B. WLAN-Zertifikate) verfügt, die die Zwecke der Clientauthentifizierung erfüllen, fordert der Chrome-Browser auf Windows-Desktopcomputern Benutzer*innen auf, das richtige Zertifikat auszuwählen. Diese Eingabeaufforderung kann für Benutzer*innen verwirrend sein. Um diese Funktion 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 können sie automatisch über das Gruppenrichtlinienobjekt konfigurieren (zum Festlegen der Registrierungsschlüssel). 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 unter Liste der Chrome Enterprise-Richtlinien.

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*innen konfiguriert haben.

Überprüfen Sie, ob die vertrauenswürdigen Zertifikataussteller auf allen AD FS- und WAP-Servern ordnungsgemäß konfiguriert sind.

Wenn vertrauenswürdige Zertifikataussteller nicht ordnungsgemäß konfiguriert sind, tritt häufig der HTTP-Fehler 204 („Kein Inhalt von https://certauth.adfs.contoso.com."“) auf.

AD FS verwendet das zugrunde liegende Windows-Betriebssystem, um den Besitz des Benutzerzertifikats nachzuweisen 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.

Um dies automatisch zu überprüfen, können Sie das Tool AD FS Diagnostics Analyzer verwenden. Das Tool fragt alle Server ab und stellt sicher, dass die richtigen Zertifikate ordnungsgemäß bereitgestellt werden.

  1. Laden Sie das Tool herunter, und führen Sie es aus.
  2. Laden Sie die Ergebnisse hoch, und überprüfen Sie sie auf Fehler.

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

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

Hinweis

Unter Windows Server 2016 werden in AD FS jetzt zwei Modi unterstützt. Der erste Modus verwendet den Host adfs.contoso.com mit den Ports 443 und 49443. Der zweite Modus verwendet die Hosts adfs.contoso.com und certauth.adfs.contoso.com mit Port 443. Sie benötigen ein SSL-Zertifikat, um certauth.\<adfs-service-name> als alternativen Antragstellernamen zu unterstützen. Sie können diesen Schritt zum Zeitpunkt der Farmerstellung oder später über PowerShell ausführen.

Das gängigste Problem hinsichtlich der Netzwerkkonnektivität besteht darin, dass eine Firewall falsch konfiguriert wurde und den Datenverkehr für die Benutzerzertifikatauthentifizierung blockiert. In der Regel wird ein leerer Bildschirm oder der Serverfehler 500 angezeigt, wenn dieses Problem auftritt. Problemlösung:

  1. Notieren Sie sich den Hostnamen und Port, den Sie in AD FS konfiguriert haben.
  2. Stellen Sie sicher, dass jede Firewall vor AD FS oder dem WAP so konfiguriert ist, dass sie die Kombination hostname:port für Ihre AD FS-Farm zulässt. Ihr Network Engineer muss diesen Schritt ausführen.

Überprüfen der CRL-Konnektivität

Zertifikatsperrlisten (Certificate Revocation Lists, CRLs) sind Endpunkte, die in das Benutzerzertifikat codiert werden, um Runtimesperrprüfungen durchzuführen. Wenn beispielsweise ein Gerät, das ein Zertifikat enthält, gestohlen wird, können Administrator*innen das Zertifikat der Liste der gesperrten Zertifikate hinzufügen. Bei jedem Endpunkt, der dieses Zertifikat zuvor akzeptiert hat, tritt jetzt bei der Authentifizierung ein Fehler auf.

Jeder AD FS- und WAP-Server muss den CRL-Endpunkt erreichen können, um zu überprüfen, ob das vorgezeigte Zertifikat weiterhin gültig ist und nicht gesperrt 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, tritt bei der Authentifizierung ein Fehler auf. Führen Sie zur Problembehandlung die folgenden Schritte aus:

  1. Wenden Sie sich an die für die Public Key-Infrastruktur verantwortlichen Personen, um zu ermitteln, welche CRL-Endpunkte zum Sperren von Benutzerzertifikaten über Ihr PKI-System verwendet werden.
  2. Stellen Sie auf jedem AD FS- und WAP-Server sicher, dass die CRL-Endpunkte über das verwendete Protokoll (in der Regel HTTPS oder HTTP) erreichbar sind.
  3. Aktivieren Sie für die erweiterte Validierung die CAPI2-Ereignisprotokollierung auf jedem AD FS- und WAP-Server.
  4. Überprüfen Sie die CAPI2-Betriebsprotokolle auf die Ereignis-ID 41 (Sperrung überprüfen).
  5. Überprüfen Sie sie auf <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>.

Tipp

Sie können einen einzelnen AD FS- oder WAP-Server als Ziel verwenden, um die Problembehandlung zu vereinfachen, 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, dass Clientgeräte (oder Browser) und die Lastenausgleiche die Servernamensanzeige (Server Name Indication, SNI) unterstützen. Einige Clientgeräte (z. B. ältere Android-Versionen) unterstützen die SNI möglicherweise nicht. Darüber hinaus bieten Lastenausgleiche möglicherweise keine Unterstützung für die SNI oder sind nicht für diese konfiguriert. In diesen Fällen treten wahrscheinlich Fehler bei der Benutzerzertifizierung auf.

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

  1. Öffnen Sie ein Eingabeaufforderungsfenster mit erhöhten Rechten auf dem primären AD FS-Server.
  2. Geben Sie Netsh http show sslcert ein.
  3. Kopieren Sie die Anwendungs-GUID und den Zertifikathash des Verbunddiensts.
  4. Geben Sie netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicaitonGUID} 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:

  1. Wenn das Problem spezifisch für ein Android-Gerät ist, besteht 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 die angemeldeten Benutzer*innen überprüfen (nicht System oder Computer).

  2. Exportieren Sie das Clientbenutzerzertifikat in eine CER-Datei, und führen Sie den Befehl certutil -f -urlfetch -verify certificatefilename.cer aus.

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

In seltenen Fällen wird ein Clientgerät so aktualisiert, dass es nur eine höhere TLS-Version unterstützt (z. B. Version 1.3). Umgekehrt kann es jedoch auch sein, dass AD FS- und WAP-Server so aktualisiert wurden, dass sie nur eine höhere TLS-Version verwenden, die vom Clientgerät nicht unterstützt wird.

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

Überprüfen, ob der Microsoft Entra-Parameter „PromptLoginBehavior“ für Ihre Verbunddomäneneinstellungen ordnungsgemäß konfiguriert ist

Viele Office 365-Anwendungen senden prompt=login an Microsoft Entra ID. Microsoft Entra ID konvertiert dies standardmäßig in eine neue Kennwortanmeldung für AD FS um. Daher wird Ihren Benutzer*innen nur eine Kennwortanmeldung angezeigt, selbst wenn Sie die Zertifikatauthentifizierung in AD FS konfiguriert haben. So beheben Sie dieses Problem:

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

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

Weitere Informationen zur Problembehandlung

In seltenen Fällen kann beim Downloadversuch ein Timeout auftreten, wenn Ihre CRL-Listen sehr lang sind. In diesem Fall müssen Sie MaxFieldLength und MaxRequestByte wie im Artikel zu den Http.sys-Registrierungseinstellungen für Windows beschrieben aktualisieren.

Referenz: Vollständige Liste der Benutzerzertifikat-Anspruchstypen 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: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