Windows Hello for Business bekannte Bereitstellungsprobleme

Der Inhalt dieses Artikels besteht darin, bekannte Bereitstellungsprobleme für Windows Hello for Business zu beheben.

Bei der PIN-Zurücksetzung auf Microsoft Entra-Einbindungsgeräten tritt der Fehler Wir können diese Seite jetzt nicht öffnen auf.

Die PIN-Zurücksetzung auf Microsoft Entra verbundenen Geräten verwendet einen Flow namens Webanmeldung, um den Benutzer über der Sperre zu authentifizieren. Die Webanmeldung ermöglicht nur die Navigation zu bestimmten Domänen. Wenn die Webanmeldung versucht, zu einer domäne zu navigieren, die nicht zulässig ist, wird eine Seite mit der Fehlermeldung Wir können diese Seite jetzt nicht öffnen angezeigt.

Identifizieren eines Problems mit zulässigen Domänen bei der PIN-Zurücksetzung

Der Benutzer kann den PIN-Zurücksetzungsflow über den Sperrbildschirm starten, indem er den Link Ich habe meine PIN vergessen im ANBIETER der PIN-Anmeldeinformationen verwendet. Wenn Sie den Link auswählen, wird eine Vollbildbenutzeroberfläche für die PIN-Benutzeroberfläche auf Microsoft Entra Geräten gestartet. In der Regel wird auf der Benutzeroberfläche eine Azure-Authentifizierungsseite angezeigt, auf der sich der Benutzer mit Microsoft Entra Anmeldeinformationen authentifiziert und MFA abschließt.

In Verbundumgebungen kann die Authentifizierung so konfiguriert werden, dass sie an AD FS oder einen Nicht-Microsoft-Identitätsanbieter weitergeleitet wird. Wenn der PIN-Zurücksetzungsflow gestartet wird und versucht, zu einer Serverseite des Verbundidentitätsanbieters zu navigieren, tritt ein Fehler auf und es wird der Fehler Wir können diese Seite im Moment nicht öffnen angezeigt, wenn die Domäne für die Serverseite nicht in einer Positivliste enthalten ist.

Wenn Sie Ein Kunde der Azure US Government-Cloud sind, versucht die PIN-Zurücksetzung auch, zu einer Domäne zu navigieren, die nicht in der Standard-Positivliste enthalten ist. Das Ergebnis ist die Meldung Wir können diese Seite im Moment nicht öffnen.

Beheben des Problems mit zulässigen Domänen für die PIN-Zurücksetzung

Um den Fehler zu beheben, können Sie mithilfe der Richtlinie ConfigureWebSignInAllowedUrls eine Liste der zulässigen Domänen für die PIN-Zurücksetzung konfigurieren. Informationen zum Konfigurieren der Richtlinie finden Sie unter Konfigurieren zulässiger URLs für Verbundidentitätsanbieter auf Microsoft Entra verbundenen Geräten.

Anmeldung der Hybridschlüsselvertrauensstellung aufgrund des Löschens des öffentlichen Schlüssels des Benutzers unterbrochen

Gilt für:

  • Hybride Schlüsselvertrauensbereitstellungen
  • Windows Server 2016, Builds 14393.3930 bis 14393.4048
  • Windows Server 2019, Builds 17763.1457 bis 17763.1613

In hybriden Schlüsselvertrauensbereitstellungen mit Domänencontrollern, auf denen bestimmte Builds von Windows Server 2016 und Windows Server 2019 ausgeführt werden, wird der Windows Hello for Business Schlüssel des Benutzers gelöscht, nachdem er sich angemeldet hat. Bei nachfolgenden Anmeldungen tritt ein Fehler auf, bis der Schlüssel des Benutzers während des nächsten Microsoft Entra Deltasynchronisierungszyklus connect synchronisiert wird.

Identifizieren eines Problems beim Löschen des öffentlichen Schlüssels des Benutzers

Nachdem der Benutzer eine Windows Hello for Business Anmeldeinformationen in einer Hybridschlüsselvertrauensumgebung bereitgestellt hat, muss der Schlüssel während eines Microsoft Entra Verbindungssynchronisierungszyklus von Microsoft Entra ID mit Active Directory synchronisiert werden. Der öffentliche Schlüssel des Benutzers wird in das msDS-KeyCredentialLink Attribut des Benutzerobjekts geschrieben.

Vor der Synchronisierung des Windows Hello for Business Schlüssels des Benutzers schlagen Anmeldungen mit Windows Hello for Business mit der Fehlermeldung Diese Option ist vorübergehend nicht verfügbar fehl. Verwenden Sie vorerst eine andere Methode, um sich anzumelden. Nachdem der Schlüssel erfolgreich synchronisiert wurde, kann sich der Benutzer mit seiner PIN oder registrierten biometrischen Daten anmelden und entsperren.

In Umgebungen mit dem Problem schlägt der nächste Anmeldeversuch fehl, nachdem die erste Anmeldung mit Windows Hello for Business und bereitstellung abgeschlossen ist. In Umgebungen, in denen Domänencontroller eine Mischung aus Builds ausführen, kann das Problem einige Benutzer beeinträchtigen, und nachfolgende Anmeldeversuche können an verschiedene Domänencontroller gesendet werden. Das Ergebnis sind zeitweilige Anmeldefehler.

Nach dem ersten Anmeldeversuch wird der Windows Hello for Business öffentlichen Schlüssel des Benutzers aus der msDS-KeyCredentialLink attributegelöscht. Sie können den Löschvorgang überprüfen, indem Sie das Attribut eines Benutzers msDS-KeyCredentialLink vor und nach der Anmeldung abfragen. Sie können die msDS-KeyCredentialLink in AD abfragen, indem Sie Get-ADUser verwenden und für den -Properties Parameter angebenmsds-keycredentiallink.

Beheben des Problems beim Löschen eines öffentlichen Schlüssels für Benutzer

Um das Problem zu beheben, aktualisieren Sie Windows Server 2016- und 2019-Domänencontroller mit den neuesten Patches. Für Windows Server 2016 wurde das Verhalten in Build 14393.4104 (KB4593226) und höher behoben. Für Windows Server 2019 wurde das Verhalten in Build 17763.1637 (KB4592440) behoben.

Microsoft Entra eingebundenen Gerätezugriff auf lokale Ressourcen mithilfe der Schlüsselvertrauensstellung und der Nicht-Microsoft-Zertifizierungsstelle

Gilt für:

  • Microsoft Entra eingebundene Schlüsselvertrauensbereitstellungen
  • Nicht-Microsoft-Zertifizierungsstelle, die Domänencontrollerzertifikate ausstellt

Windows Hello for Business verwendet smart-Karte-basierte Authentifizierung für viele Vorgänge. Bei dieser Art der Authentifizierung gelten spezielle Richtlinien, wenn sie eine Nicht-Microsoft-Zertifizierungsstelle für die Zertifikatausstellung verwenden, von denen einige für die Domänencontroller gelten. Nicht alle Windows Hello for Business Bereitstellungstypen erfordern diese Konfigurationen. Für den Zugriff auf lokale Ressourcen über ein Microsoft Entra verbundenes Gerät ist eine spezielle Konfiguration erforderlich, wenn Sie eine Nicht-Microsoft-Zertifizierungsstelle zum Ausstellen von Domänencontrollerzertifikaten verwenden.

Weitere Informationen finden Sie unter Richtlinien zum Aktivieren von Smart Karte Anmeldung bei Nicht-Microsoft-Zertifizierungsstellen.

Identifizieren von Problemen mit dem Zugriff auf lokale Ressourcen mit Nicht-Microsoft-Zertifizierungsstellen

Das Problem kann mithilfe von Netzwerkablaufverfolgungen oder der Kerberos-Protokollierung vom Client identifiziert werden. In der Netzwerkablaufverfolgung kann der Client keine TGS_REQ Anforderung platzieren, wenn ein Benutzer versucht, auf eine Ressource zuzugreifen. Auf dem Client kann dies im Ereignisprotokoll des Kerberos-Vorgangs unter Application and Services/Microsoft/Windows/Security-Kerberos/Operationalbeobachtet werden. Die Protokolle sind standardmäßig deaktiviert. Das Fehlerereignis für diesen Fall enthält die folgenden Informationen:

Log Name:      Microsoft-Windows-Kerberos/Operational
Source:        Microsoft-Windows-Security-Kerberos
Event ID:      107
GUID:          {98e6cfcb-ee0a-41e0-a57b-622d4e1b30b1}
Task Category: None
Level:         Error
Keywords:
User:          SYSTEM
Description:

The Kerberos client received a KDC certificate that does not have a matched domain name.
Expected Domain Name: ad.contoso.com
Error Code: 0xC000006D

Beheben eines Problems mit dem Zugriff auf lokale Ressourcen mit Nicht-Microsoft-Zertifizierungsstellen

Um das Problem zu beheben, müssen Domänencontrollerzertifikate aktualisiert werden, sodass der Zertifikatantragsteller den Verzeichnispfad des Serverobjekts (distinguished name) enthält. Beispiel betreff: CN=DC1,OU=Domain Controllers,DC=ad,DC=contoso,DC=com

Alternativ können Sie den alternativen Antragstellernamen (Subject Alternative Name, SAN) des Domänencontrollerzertifikats so festlegen, dass er den vollqualifizierten Domänennamen des Serverobjekts und den NETBIOS-Namen der Domäne enthält. Beispiel für alternativen Antragstellernamen:

dns=dc1.ad.contoso.com
dns=ad.contoso.com
dns=ad

Authentifizierung mit Schlüsselvertrauensstellung für Windows Server 2019 unterbrochen

Gilt für:

  • Windows Server 2019
  • Hybride Schlüsselvertrauensbereitstellungen
  • Lokale Schlüsselvertrauensbereitstellungen

Bei Domänencontrollern, auf denen frühe Versionen von Windows Server 2019 ausgeführt werden, tritt ein Problem auf, das verhindert, dass die Authentifizierung mit Schlüsselvertrauen ordnungsgemäß funktioniert. Netzwerkablaufverfolgungen melden KDC_ERR_CLIENT_NAME_MISMATCH.

Identifizieren eines Problems mit der Windows Server 2019-Authentifizierung mit Schlüsselvertrauensstellung

Auf dem Client schlägt die Authentifizierung mit Windows Hello for Business mit der Fehlermeldung Fehlschlagen. Diese Option ist vorübergehend nicht verfügbar. Verwenden Sie vorerst eine andere Methode, um sich anzumelden.

Der Fehler wird auf Microsoft Entra hybrid eingebundenen Geräten in Schlüsselvertrauensstellungen angezeigt, nachdem Windows Hello for Business bereitgestellt wurde, aber bevor der Schlüssel eines Benutzers von Microsoft Entra ID mit Active Directory synchronisiert wird. Wenn der Schlüssel eines Benutzers nicht aus Microsoft Entra ID synchronisiert wird und das msDS-keycredentiallink Attribut für das Benutzerobjekt in AD für NGC aufgefüllt wird, tritt der Fehler möglicherweise auf.

Ein weiterer Indikator für den Ausfall kann mithilfe von Netzwerkablaufverfolgungen identifiziert werden. Wenn Sie Netzwerkablaufverfolgungen für ein Schlüsselvertrauens-Anmeldeereignis erfassen, zeigen die Ablaufverfolgungen, dass Kerberos mit dem Fehler KDC_ERR_CLIENT_NAME_MISMATCH fehlschlägt.

Beheben eines Problems mit der Server 2019 Key Trust-Authentifizierung

Das Problem wurde in Windows Server 2019, Build 17763.316 (KB4487044), behoben. Aktualisieren Sie alle Windows Server 2019-Domänencontroller auf Build 17763.316 oder höher, um das Problem zu beheben.

Bereitstellung von Zertifikatvertrauensstellungen mit AD FS unter Windows Server 2019 fehlerhaft

Gilt für:

  • Windows Server 2019
  • Hybride Zertifikatvertrauensbereitstellungen
  • Lokale Zertifikatvertrauensbereitstellungen

AD FS unter Windows Server 2019 kann die Geräteauthentifizierung aufgrund einer ungültigen Überprüfung eingehender Bereiche in der Anforderung nicht abschließen. Die Geräteauthentifizierung bei AD FS ist eine Voraussetzung für Windows Hello for Business, um ein Zertifikat mithilfe von AD FS zu registrieren. Der Client blockiert Windows Hello for Business Bereitstellung, bis die Authentifizierung erfolgreich ist.

Identifizieren der Zertifikatvertrauensstellung bei AD FS 2019-Registrierungsproblem

Die Bereitstellungsoberfläche für Windows Hello for Business wird gestartet, wenn die Voraussetzungsprüfungen erfolgreich sind. Das Ergebnis der ProvisioningAdmin-Überprüfungen ist in Ereignisprotokollen unter Microsoft-Windows-Benutzergeräteregistrierung verfügbar. Wenn die Bereitstellung blockiert wird, weil die Geräteauthentifizierung nicht erfolgreich ist, wird die Ereignis-ID 362 protokolliert, die besagt , dass sich der Benutzer erfolgreich beim Unternehmens-STS authentifiziert hat: Nein.

Log Name:      Microsoft-Windows-User Device Registration/Admin
Source:        Microsoft-Windows-User Device Registration
Date:          <Date and time>
Event ID:      362
Task Category: None
Level:         Warning
Keywords:
User:          <User SID>
Computer:      <Computer name>
Description:
Windows Hello for Business provisioning will not be launched.
Device is Azure Active Directory-joined ( AADJ or DJ++ ): Yes
User has logged on with Azure Active Directory credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: Yes
Enterprise user logon certificate enrollment endpoint is ready: Not Tested
Enterprise user logon certificate template is : No ( 1 : StateNoPolicy )
User has successfully authenticated to the enterprise STS: No
Certificate enrollment method: enrollment authority
See https://go.microsoft.com/fwlink/?linkid=832647 for more details.

Wenn ein Gerät kürzlich einer Domäne beigetreten ist, kann es zu einer Verzögerung kommen, bevor die Geräteauthentifizierung erfolgt. Wenn der Fehlerstatus dieser Voraussetzungsprüfung weiterhin besteht, kann dies auf ein Problem mit der AD FS-Konfiguration hinweisen.

Wenn das Problem mit dem AD FS-Bereich vorliegt, weisen Ereignisprotokolle auf dem AD FS-Server auf einen Authentifizierungsfehler des Clients hin. Der Fehler wird in Ereignisprotokollen unter AD FS/Admin als Ereignis-ID 1021 protokolliert, und das Ereignis gibt an, dass dem Client der Zugriff auf die Ressource http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope mit dem Bereich ugsuntersagt ist:

Log Name:      AD FS/Admin
Source:        AD FS
Date:          <Date and time>
Event ID:      1021
Task Category: None
Level:         Error
Keywords:      AD FS
User:          <ADFS service Account>
Computer:      <Date and time>
Description:
Encountered error during OAuth token request.
Additional Data
Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthUnauthorizedClientException: MSIS9368: Received invalid OAuth request. The client '38aa3b87-a06d-4817-b275-7a316988d93b' is forbidden to access the resource 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' with scope 'ugs'.
       at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthProtocolContext.ValidateScopes(String scopeParameter, String clientId, String relyingPartyId)
       at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()

Beheben eines Problems mit der Zertifikatvertrauensstellung bei der AD FS 2019-Registrierung

Dieses Problem wurde in Windows Server, Version 1903 und höher, behoben. Für Windows Server 2019 kann das Problem durch manuelles Hinzufügen des Ugs-Bereichs behoben werden.

  1. Starten Sie AD FS Verwaltungskonsole. Navigieren Sie zu Dienstbereichsbeschreibungen>.

  2. Wählen Sie mit der rechten Maustaste Bereichsbeschreibungen und dann Bereichsbeschreibung hinzufügen aus.

  3. Geben Sie unter name ugs ein, und wählen Sie Ok anwenden >aus.

  4. Starten Sie PowerShell als Administrator.

  5. Rufen Sie den ObjectIdentifier der Anwendungsberechtigung mit dem ClientRoleIdentifier-Parameter gleich "38aa3b87-a06d-4817-b275-7a316988d93b" ab:

    (Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier

  6. Führen Sie den Befehl aus Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'.

  7. Starten Sie den AD FS-Dienst neu.

  8. Auf dem Client: Starten Sie den Client neu. Der Benutzer sollte aufgefordert werden, Windows Hello for Business bereitzustellen.