Freigeben über

Überlegungen und bekannte Probleme bei der Verwendung von Credential Guard

Microsoft empfiehlt, dass Organisationen nicht nur Credential Guard bereitstellen, sich von Kennwörtern zu anderen Authentifizierungsmethoden wie Windows Hello for Business, FIDO 2-Sicherheitsschlüsseln oder Smartcards verlagern.

Überlegungen zum Upgrade

Wichtig

Windows Server 2025 befindet sich in der Vorschauphase. Diese Informationen beziehen sich auf ein Vorabversionsprodukt, das vor der Veröffentlichung erheblich geändert werden kann. Microsoft übernimmt in Bezug auf die hier bereitgestellten Informationen keine Gewährleistung, weder ausdrücklich noch konkludent.

Da Credential Guard seine Sicherheitsfeatures weiterentwickelt und verbessert, können sich neuere Versionen von Windows, auf denen Credential Guard ausgeführt wird, auf frühere Funktionsszenarien auswirken. Beispielsweise könnte Credential Guard die Verwendung bestimmter Anmeldeinformationen oder Komponenten einschränken, um Schadsoftware zu verhindern, die Sicherheitsrisiken ausnutzt.

Es ist ratsam, Betriebsszenarien innerhalb einer Organisation gründlich zu testen, bevor Sie Geräte aktualisieren, die Credential Guard verwenden.

Bei Upgrades auf Windows 11, Version 22H2, und Windows Server 2025 (Vorschauversion) ist Credential Guard standardmäßig aktiviert , sofern es nicht explizit deaktiviert ist.

Überlegungen zu WLAN und VPN

Wenn Credential Guard aktiviert ist, können Sie die klassische NTLM-Authentifizierung (NTLMv1) nicht mehr für einmaliges Anmelden (Single Sign-On, SSO) verwenden. Sie werden gezwungen, Ihre Anmeldeinformationen einzugeben, um diese Protokolle zu verwenden, und können die Anmeldeinformationen nicht für die zukünftige Verwendung speichern.

Wenn Sie WLAN- und VPN-Endpunkte verwenden, die auf MS-CHAPv2 basieren, sind diese ähnlichen Angriffen ausgesetzt wie bei NTLMv1.

Für WLAN- und VPN-Verbindungen wird empfohlen, von MSCHAPv2-basierten Verbindungen (z. B. PEAP-MSCHAPv2 und EAP-MSCHAPv2) zur zertifikatbasierten Authentifizierung (z. B. PEAP-TLS oder EAP-TLS) zu wechseln.

Überlegungen zur Delegierung

Wenn Credential Guard aktiviert ist, sind bestimmte Arten der Identitätsdelegierung nicht verwendbar, da die zugrunde liegenden Authentifizierungsschemas nicht mit Credential Guard kompatibel sind oder die angegebenen Anmeldeinformationen erfordern.

Wenn Credential Guard aktiviert ist, kann der Credential Security Support Provider ("CredSSP") gespeicherte oder SSO-Anmeldeinformationen nicht mehr verwenden, obwohl Klartextanmeldeinformationen weiterhin angegeben werden können. Die CredSSP-basierte Delegierung erfordert die Angabe von Klartextanmeldeinformationen auf dem Zielcomputer und funktioniert nicht mit SSO, sobald Credential Guard aktiviert ist und die Offenlegung von Klartextanmeldeinformationen blockiert. Die Verwendung von CredSSP für die Delegierung und im Allgemeinen wird aufgrund des Risikos des Diebstahls von Anmeldeinformationen nicht empfohlen.

Die nicht eingeschränkte Kerberos-Delegierung und DES werden von Credential Guard blockiert. Die uneingeschränkte Delegierung ist keine empfohlene Vorgehensweise.

Stattdessen wird Kerberos oder Negotiate SSP für die allgemeine Authentifizierung empfohlen, und für die Delegierung werden eingeschränkte Kerberos-Delegierung und ressourcenbasierte eingeschränkte Kerberos-Delegierung empfohlen. Diese Methoden bieten insgesamt eine höhere Anmeldeinformationssicherheit und sind auch mit Credential Guard kompatibel.

Überlegungen zu Nicht-Microsoft-Sicherheitssupportanbietern

Einige Nicht-Microsoft-Sicherheitssupportanbieter (SSPs und APs) sind möglicherweise nicht mit Credential Guard kompatibel, da nicht microsoft-basierte SSPs das Anfordern von Kennworthashes von LSA zulassen. SSPs und Zugriffspunkte werden aber weiterhin über das Kennwort informiert, wenn sich ein Benutzer anmeldet bzw. sein Kennwort ändert. Die Verwendung von nicht dokumentierten APIs in benutzerdefinierten SSPs und APs wird nicht unterstützt.

Es wird empfohlen, benutzerdefinierte Implementierungen von SSPs/APs mit Credential Guard zu testen. SSPs und Zugriffspunkte, die auf einem undokumentierten oder nicht unterstützten Verhalten basieren, werden nicht akzeptiert. Beispielsweise wird die Verwendung der KerbQuerySupplementalCredentialsMessage-API nicht unterstützt. Ersetzen Sie NTLM- oder Kerberos-SSPs durch benutzerdefinierte SSPs und Zugriffspunkte.

Weitere Informationen finden Sie unter Einschränkungen beim Registrieren und Installieren eines Sicherheitspakets.

Überlegungen zu gespeicherten Windows-Anmeldeinformationen

Mit dem Anmeldeinformations-Manager können Sie drei Arten von Anmeldeinformationen speichern:

  • Windows-Anmeldeinformationen
  • Zertifikatbasierte Anmeldeinformationen
  • Generische Anmeldeinformationen

Domänenanmeldeinformationen, die in Credential Manager gespeichert sind, werden mit Credential Guard geschützt.

Generische Anmeldeinformationen, z. B. Benutzernamen und Kennwörter, die Sie zum Anmelden von Websites verwenden, sind nicht geschützt, da die Anwendungen Ihr Klartextkennwort erfordern. Wenn die Anwendung keine Kopie des Kennworts benötigt, können sie Domänenanmeldeinformationen als geschützte Windows-Anmeldeinformationen speichern. Windows-Anmeldedaten werden verwendet, um eine Verbindung mit anderen Computern in einem Netzwerk herzustellen.

Für den Credential Guard-Schutz für die Anmeldeinformationsverwaltung sollten Sie Folgendes berücksichtigen:

  • Vom Remotedesktopclient gespeicherte Windows-Anmeldeinformationen können nicht an einen Remotehost gesendet werden. Versuche, gespeicherte Windows-Anmeldeinformationen zu verwenden, schlagen fehl, und es wird die Fehlermeldung Anmeldeversuch fehlgeschlagen angezeigt.
  • Anwendungen, die Windows-Anmeldeinformationen extrahieren, schlagen fehl.
  • Wenn Anmeldeinformationen von einem PC gesichert werden, auf dem Credential Guard aktiviert ist, können die Windows-Anmeldeinformationen nicht wiederhergestellt werden. Wenn Sie Ihre Anmeldeinformationen sichern müssen, müssen Sie dies tun, bevor Sie Credential Guard aktivieren.

Überlegungen zum TPM-Löschen

Virtualisierungsbasierte Sicherheit (VBS) verwendet das TPM, um den Schlüssel zu schützen. Wenn das TPM gelöscht wird, geht der TPM-geschützte Schlüssel, der zum Verschlüsseln von VBS-Geheimnissen verwendet wird, verloren.

Warnung

Das Löschen des TPM führt zu einem Verlust der geschützten Daten für alle Features, die VBS verwenden, um Daten zu schützen.

Wenn ein TPM gelöscht wird, können alle Features, die VBS zum Schutz von Daten verwenden, ihre geschützten Daten nicht mehr entschlüsseln.

Daher kann Credential Guard geschützte Daten nicht mehr entschlüsseln. VBS erstellt einen neuen, von TPM geschützten Schlüssel für Credential Guard. Credential Guard verwendet den neuen Schlüssel, um neue Daten zu schützen. Alle vorher geschützten Daten sind unwiederbringlich verloren.

Hinweis

Credential Guard erhält den Schlüssel während der Initialisierung. Der Datenverlust wirkt sich nur auf persistente Daten aus und tritt nach dem nächsten Systemstart auf.

Von der Anmeldeinformationsverwaltung gesicherte Windows-Anmeldedaten

Da der Anmeldeinformations-Manager gespeicherte Windows-Anmeldeinformationen nicht entschlüsseln kann, werden sie gelöscht. Anwendungen sollten zur Eingabe von Anmeldedaten auffordern, die zuvor gespeichert wurden. Nachdem sie erneut gespeichert wurden, sind die Windows-Anmeldedaten durch Credential Guard geschützt.

Automatisch bereitgestellter öffentlicher Schlüssel des in die Domäne eingebundenen Geräts

In die Active Directory-Domäne eingebundene Geräte stellen automatisch einen gebundenen öffentlichen Schlüssel bereit. Weitere Informationen zur automatischen Bereitstellung von öffentlichen Schlüsseln finden Sie unter Authentifizierung mit in die Domäne eingebundener öffentlicher Schlüssel für Geräte.

Da Credential Guard den geschützten privaten Schlüssel nicht entschlüsseln kann, verwendet Windows das Kennwort des in die Domäne eingebundenen Computers für die Authentifizierung bei der Domäne. Sofern keine anderen Richtlinien bereitgestellt werden, sollte es keinen Funktionsverlust geben. Wenn ein Gerät so konfiguriert ist, dass es nur einen öffentlichen Schlüssel verwendet, kann es sich erst dann mit einem Kennwort authentifizieren, wenn diese Richtlinie deaktiviert ist. Weitere Informationen zum Konfigurieren von Geräten, die nur öffentliche Schlüssel verwenden, finden Sie unter Domain-joined Device Public Key Authentication.

Auch wenn bei Zugriffssteuerungsprüfungen einschließlich Authentifizierungsrichtlinien erforderlich ist, dass Geräte entweder über die KEY TRUST IDENTITY (S-1-18-4)FRESH PUBLIC KEY IDENTITY (S-1-18-3) oder über bekannte SIDs verfügen, schlagen diese Zugriffsprüfungen fehl. Weitere Informationen über Authentifizierungsrichtlinien finden Sie unter Authentifizierungsrichtlinien und Authentifizierungsrichtliniensilos. Weitere Informationen zu bekannten SIDs finden Sie unter [MS-DTYP] Section 2.4.2.4 Well-known SID Structures.

DPAPI auf Geräte in einer Domäne

Auf den zu einer Domäne gehörenden Geräten kann DPAPI Schlüssel des Benutzers mit einem Domänencontroller aus der Domäne des Benutzers wiederherstellen. Wenn ein in die Domäne eingebundenes Gerät nicht mit einem Domänencontroller verbunden ist, ist die Wiederherstellung nicht möglich.

Wichtig

Das Löschen eines TPM auf einem Domänengerät sollte daher in einem Netzwerk mit Konnektivität zu Domänencontrollern erfolgen. Dadurch ist sichergestellt, dass DPAPI-Funktionen ausgeführt werden und der Benutzer kein ungewöhnliches Verhalten bemerkt.

Die automatische VPN-Konfiguration ist durch Benutzer-DPAPI geschützt. Der Benutzer kann möglicherweise keine VPN-Verbindung mit Domänencontrollern herstellen, da die VPN-Konfigurationen verloren gehen. Wenn Sie das TPM auf einem Domänengerät ohne Verbindung zu den Domänencontrollern löschen müssen, sollten Sie Folgendes beachten.

Domänenbenutzer melden sich nach dem Löschen eines TPM auf einem in die Domäne eingebundenen Gerät an, solange keine Verbindung mit einem Domänencontroller besteht:

Anmeldedatentyp Verhalten
Zertifikat (Smartcard oder Windows Hello for Business) Alle Daten, die mit der Benutzer-DPAPI geschützt werden, sind nicht verwendbar, und die Benutzer-DPAPI funktioniert überhaupt nicht.
Kennwort Wenn sich der Benutzer vor dem Löschen des TPM mit einem Zertifikat oder Kennwort angemeldet hat, kann er sich mit einem Kennwort anmelden, und die Benutzer-DPAPI ist davon nicht betroffen.

Nachdem das Gerät über Konnektivität zum Domänencontroller verfügt, stellt DPAPI den Schlüssel des Benutzers wieder her, und vor dem Löschen des TPM geschützte Daten können entschlüsselt werden.

Auswirkungen eines DPAPI-Ausfalls auf Windows Information Protection

Wenn die per Benutzer-DPAPI geschützten Daten unbrauchbar sind, verliert der Benutzer den Zugriff auf alle von Windows Information Protection geschützten Arbeitsdaten. Die Auswirkungen umfassen: Outlook kann nicht gestartet werden, und arbeitsgeschützte Dokumente können nicht geöffnet werden. Wenn DPAPI funktioniert, werden neu erstellte Arbeitsdaten geschützt und können abgerufen werden.

Problemumgehung: Benutzer können das Problem beheben, indem Sie ihr Gerät mit der Domäne verbinden und neu starten oder ihr Data Recovery Agent-Zertifikat für das Encrypting File System verwenden. Weitere Informationen über das Recovery Agent-Zertifikat für das Encrypting File System finden Sie unter Erstellen und Überprüfen eines Datenwiederherstellungs-Agent (DRA)-Zertifikats des verschlüsselnden Dateisystems (Encrypting File System, EFS).

Bekannte Probleme

Credential Guard blockiert bestimmte Authentifizierungsfunktionen. Anwendungen, die solche Funktionen erfordern, funktionieren nicht, wenn Credential Guard aktiviert ist.

In diesem Artikel werden bekannte Probleme beschrieben, wenn Credential Guard aktiviert ist.

Livemigration mit Hyper-V unterbricht beim Upgrade auf Windows Server 2025 (Vorschau)

Wichtig

Windows Server 2025 befindet sich in der Vorschauphase. Diese Informationen beziehen sich auf ein Vorabversionsprodukt, das vor der Veröffentlichung erheblich geändert werden kann. Microsoft übernimmt in Bezug auf die hier bereitgestellten Informationen keine Gewährleistung, weder ausdrücklich noch konkludent.

Geräte, die die CredSSP-basierte Delegierung verwenden, können nach dem Upgrade auf Windows Server 2025 (Vorschauversion) möglicherweise nicht mehr die Livemigration mit Hyper-V verwenden. Anwendungen und Dienste, die von der Livemigration (z. B. SCVMM) abhängig sind, können ebenfalls betroffen sein. Die CredSSP-basierte Delegierung ist die Standardeinstellung für Windows Server 2022 und früher für die Livemigration.

Beschreibung
Betroffene Geräte Dieses Problem kann auf jedem Server mit aktiviertem Credential Guard auftreten. Ab Windows Server 2025 (Vorschau) ist Credential Guard standardmäßig auf allen in die Domäne eingebundenen Servern aktiviert, die keine Domänencontroller sind. Die Standardaktivierung von Credential Guard kann vor dem Upgrade vorzeitig blockiert werden.
Ursache des Problems Livemigration mit Hyper-V und Anwendungen und Diensten, die darauf basieren, sind von dem Problem betroffen, wenn eines oder beide Enden einer bestimmten Verbindung versuchen, CredSSP mit aktiviertem Credential Guard zu verwenden. Wenn Credential Guard aktiviert ist, kann CredSSP nur die angegebenen Anmeldeinformationen verwenden, nicht gespeicherte Anmeldeinformationen oder SSO-Anmeldeinformationen.

Wenn der Quellcomputer einer Livemigration CredSSP für die Delegierung mit aktiviertem Credential Guard verwendet, tritt bei der Livemigration ein Fehler auf. In den meisten Fällen wirkt sich der Aktivierungsstatus von Credential Guard auf dem Zielcomputer nicht auf die Livemigration aus. Bei der Livemigration tritt auch in Clusterszenarien (z. B. SCVMM) ein Fehler auf, da jedes Gerät als Quellcomputer fungieren kann.
Lösung Anstelle der CredSSP-Delegierung werden eingeschränkte Kerberos-Delegierung und Resource-Based eingeschränkte Kerberos-Delegierung empfohlen. Diese Formen der Delegierung bieten einen besseren Schutz von Anmeldeinformationen und sind nicht nur mit Credential Guard kompatibel. Administratoren von Hyper-V können diese Delegierungstypen manuell oder mithilfe automatisierter Skripts konfigurieren.

Unterbrechungen des einmaligen Anmeldens für Netzwerkdienste nach dem Upgrade auf Windows 11, Version 22H2 oder Windows Server 2025 (Vorschau)

Geräte, die 802.1x drahtlose oder verkabelte Netzwerk-, RDP- oder VPN-Verbindungen verwenden, die auf unsicheren Protokollen mit kennwortbasierter Authentifizierung basieren, können SSO nicht für die Anmeldung verwenden und sind gezwungen, sich in jeder neuen Windows-Sitzung manuell erneut zu authentifizieren, wenn Credential Guard ausgeführt wird.

Beschreibung
Betroffene Geräte Das Problem kann auf jedem Gerät mit aktiviertem Credential Guard auftreten. Ab Windows 11, Version 22H2, und Windows Server 2025 (Vorschau) ist für berechtigte Geräte, die Credential Guard nicht deaktiviert haben, standardmäßig aktiviert. Dies betrifft alle Geräte mit Enterprise-Lizenzen (E3 und E5) und Education sowie einige Pro-Lizenzen, sofern sie die Mindesthardwareanforderungen erfüllen.

Alle Windows Pro-Geräte, die zuvor Credential Guard unter einer berechtigten Lizenz ausgeführt und später auf Pro herabgestuft wurden und die weiterhin die Mindesthardwareanforderungen erfüllen, erhalten die Standardaktivierung.
Ursache des Problems Anwendungen und Dienste sind von dem Problem betroffen, wenn sie auf unsichere Protokolle angewiesen sind, die die kennwortbasierte Authentifizierung verwenden. Solche Protokolle gelten als unsicher, da sie zur Kennwortveröffentlichung auf dem Client oder server führen können und Credential Guard sie blockiert. Zu den betroffenen Protokollen gehören:

– Uneingeschränkte Kerberos-Delegierung (sowohl SSO als auch die angegebenen Anmeldeinformationen werden blockiert)
– Kerberos, wenn PKINIT rsa-Verschlüsselung anstelle von Diffie-Hellman verwendet (sowohl SSO als auch die angegebenen Anmeldeinformationen werden blockiert)
– MS-CHAP (nur SSO ist blockiert)
– WDigest (nur SSO ist blockiert)
– NTLM v1 (nur SSO ist blockiert)

Hinweis: Da nur SSO für MS-CHAP, WDigest und NTLM v1 blockiert ist, können diese Protokolle weiterhin verwendet werden, indem der Benutzer aufgefordert wird, Anmeldeinformationen anzugeben.
Lösung Microsoft empfiehlt, von MSCHAPv2-basierten Verbindungen (z. B. PEAP-MSCHAPv2 und EAP-MSCHAPv2) zur zertifikatbasierten Authentifizierung (z. B. PEAP-TLS oder EAP-TLS) zu wechseln. Credential Guard blockiert die zertifikatbasierte Authentifizierung nicht.

Deaktivieren Sie Credential Guard, um eine sofortigere, aber weniger sichere Lösung zu erhalten. Credential Guard verfügt nicht über Protokoll- oder Anwendungsrichtlinien und kann entweder aktiviert oder deaktiviert werden. Wenn Sie Credential Guard deaktivieren, lassen Sie gespeicherte Domänenanmeldeinformationen anfällig für Diebstahl.

Tipp

Um die Standardaktivierung zu verhindern, konfigurieren Sie Ihre Geräte so, dass Credential Guard deaktiviert wird, bevor Sie auf eine Version aktualisieren, die die Standardaktivierung erhalten hat. Wenn die Einstellung nicht konfiguriert ist (der Standardstatus) und das Gerät berechtigt ist, aktiviert das Gerät Credential Guard nach dem Update automatisch.

Wenn Credential Guard explizit deaktiviert ist, aktiviert das Gerät Credential Guard nach dem Update nicht automatisch.

Hinweis

Um festzustellen, ob ein Windows Pro-Gerät beim Upgrade auf Windows 11, Version 22H2 oder Windows Server 2025 (Vorschau) die Standardaktivierung erhält, überprüfen Sie, ob der Registrierungsschlüssel IsolatedCredentialsRootSecret in Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0vorhanden ist. Wenn es vorhanden ist, aktiviert das Gerät Credential Guard nach dem Update.

Credential Guard kann nach dem Upgrade deaktiviert werden, indem Sie die Anweisungen zur Deaktivierung befolgen.

So bestätigen Sie das Problem

MS-CHAP und NTLMv1 sind für den SSO-Bruch nach dem Update für Windows 11, Version 22H2, relevant. Um zu überprüfen, ob Credential Guard MS-CHAP oder NTLMv1 blockiert, öffnen Sie die Ereignisanzeige (eventvwr.exe), und wechseln Sie zu Application and Services Logs\Microsoft\Windows\NTLM\Operational. Überprüfen Sie die folgenden Protokolle:

Ereignis-ID (Typ)

Beschreibung

4013 (Warnung)

<string
id="NTLMv1BlockedByCredGuard"
value="Attempt to use NTLMv1 failed.
Target server: %1%nSupplied user: %2%nSupplied domain: %3%nPID
of client process: %4%nName
of client process: %5%nLUID
of client process: %6%nUser identity
of client process: %7%nDomain name
of user identity of client process: %8%nMechanism OID: 9%n%n
This device doesn't support NTLMv1.
/>

4014 (Fehler)

<string
id="NTLMGetCredentialKeyBlockedByCredGuard"
value="Attempt to get credential key by call package blocked by Credential Guard.%n%n
Calling Process Name: %1%nService Host Tag: %2"
/>

Probleme mit Nicht-Microsoft-Anwendungen

Das folgende Problem betrifft MSCHAPv2:

Das folgende Problem betrifft die Java-GSS-API. Informationen finden Sie im folgenden Datenbankartikeln zu Oracle-Fehlern:

Wenn Credential Guard unter Windows aktiviert ist, wird die Java GSS-API nicht authentifiziert. Credential Guard blockiert bestimmte Anwendungsauthentifizierungsfunktionen und stellt den TGT-Sitzungsschlüssel nicht für Anwendungen bereit, unabhängig von den Registrierungsschlüsseleinstellungen. Weitere Informationen finden Sie unter Anwendungsanforderungen.

Anbieterunterstützung

Die folgenden Produkte und Dienste unterstützen Credential Guard nicht:

Wichtig

Diese Liste ist nicht umfassend. Überprüfen Sie, ob Ihr Produktanbieter, Ihre Produktversion oder Ihr Computersystem Credential Guard auf Systemen unterstützt, auf denen eine bestimmte Version von Windows ausgeführt wird. Bestimmte Computersystemmodelle sind möglicherweise nicht mit Credential Guard kompatibel.