Problembehandlung beim Host-Wächterdienst

Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016

In diesem Artikel werden Lösungen für häufige Probleme beschrieben, die beim Bereitstellen oder Ausführen eines Host Guardian Service (HGS)-Servers in einem geschützten Fabric auftreten. Wenn Sie sich nicht über die Art Ihres Problems entscheiden, versuchen Sie zunächst, die überwachte Fabric-Diagnose auf Ihren HGS-Servern und Hyper-V-Hosts auszuführen, um die potenziellen Ursachen einzuschränken.

Zertifikate

HGS erfordert mehrere Zertifikate, um zu funktionieren, einschließlich der vom Administrator konfigurierten Verschlüsselungs- und Signaturzertifikat sowie eines von HGS selbst verwalteten Zertifikats. Wenn diese Zertifikate falsch konfiguriert sind, kann HGS keine Anforderungen von Hyper-V-Hosts bereitstellen, die Schlüsselschutzzeichen für abgeschirmte V-Computer bestätigen oder entsperren möchten. In den folgenden Abschnitten werden allgemeine Probleme im Zusammenhang mit Zertifikaten behandelt, die auf HGS konfiguriert sind.

Zertifikatberechtigungen

HGS muss sowohl auf die öffentlichen als auch privaten Schlüssel der Verschlüsselungs- und Signaturzertifikate zugreifen können, die der HGS durch den Zertifikat-Fingerabdruck hinzugefügt wurden. Insbesondere benötigt das Gruppenverwaltungsdienstkonto (gMSA), das den HGS-Dienst ausführt, Zugriff auf die Schlüssel. Um die gMSA zu finden, die von HGS verwendet wird, führen Sie den folgenden Befehl in einer PowerShell-Eingabeaufforderung mit erhöhten Rechten auf Ihrem HGS-Server aus:

(Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

Wie Sie dem gMSA-Konto Zugriff auf die Verwendung des privaten Schlüssels gewähren, hängt davon ab, wo der Schlüssel gespeichert wird: auf dem Computer als lokale Zertifikatdatei, auf einem Hardwaresicherheitsmodul (HSM) oder mithilfe eines benutzerdefinierten Drittanbieters für den Schlüsselspeicher.

Gewähren des Zugriffs auf softwarebasierte private Schlüssel

Wenn Sie ein selbst signiertes Zertifikat oder ein Zertifikat verwenden, das von einer Zertifizierungsstelle ausgestellt wird, die nicht in einem Hardwaresicherheitsmodul oder einem benutzerdefinierten Schlüsselspeicheranbieter gespeichert ist, können Sie die berechtigungen für private Schlüssel ändern, indem Sie die folgenden Schritte ausführen:

  1. Öffnen des lokalen Zertifikat-Managers (certlm.msc)
  2. Erweitern Sie persönliche > Zertifikate , und suchen Sie das Signatur- oder Verschlüsselungszertifikat, das Sie aktualisieren möchten.
  3. Klicken Sie mit der rechten Maustaste auf das Zertifikat, und wählen Sie "Alle Aufgaben > verwalten private Schlüssel verwalten" aus.
  4. Wählen Sie "Hinzufügen " aus, um einem neuen Benutzer Zugriff auf den privaten Schlüssel des Zertifikats zu gewähren.
  5. Geben Sie im Objektauswahl den gMSA-Kontonamen für HGS ein, die zuvor gefunden wurden, und wählen Sie dann OK aus.
  6. Stellen Sie sicher, dass der gMSA Lesezugriff auf das Zertifikat hat.
  7. Wählen Sie "OK " aus, um das Berechtigungsfenster zu schließen.

Wenn Sie HGS auf Server Core ausführen oder den Server remote verwalten, können Sie keine privaten Schlüssel mithilfe des lokalen Zertifikat-Managers verwalten. Stattdessen müssen Sie das PowerShell-Modul "Guarded Fabric Tools" herunterladen, mit dem Sie die Berechtigungen in PowerShell verwalten können.

  1. Öffnen Sie eine PowerShell-Konsole auf dem Server Core-Computer oder verwenden Sie PowerShell Remoting mit einem Konto, das über lokale Administratorberechtigungen auf HGS verfügt.
  2. Führen Sie die folgenden Befehle aus, um das PowerShell-Modul guarded Fabric Tools zu installieren, und gewähren Sie dem gMSA-Konto Zugriff auf den privaten Schlüssel.
$certificateThumbprint = '<ENTER CERTIFICATE THUMBPRINT HERE>'

# Install the Guarded Fabric Tools module, if necessary
Install-Module -Name GuardedFabricTools -Repository PSGallery

# Import the module into the current session
Import-Module -Name GuardedFabricTools

# Get the certificate object
$cert = Get-Item "Cert:\LocalMachine\My\$certificateThumbprint"

# Get the gMSA account name
$gMSA = (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

# Grant the gMSA read access to the certificate
$cert.Acl = $cert.Acl | Add-AccessRule $gMSA Read Allow

Gewähren des Zugriffs auf HSM oder benutzerdefinierte vom Anbieter gesicherte private Schlüssel

Wenn die privaten Schlüssel Ihres Zertifikats von einem Hardwaresicherheitsmodul (HSM) oder einem benutzerdefinierten Schlüsselspeicheranbieter (KSP) unterstützt werden, hängt das Berechtigungsmodell von Ihrem bestimmten Softwareanbieter ab. Um die besten Ergebnisse zu erzielen, lesen Sie die Dokumentation oder Supportwebsite Ihres Anbieters, um Informationen darüber zu erhalten, wie private Schlüsselberechtigungen für Ihr bestimmtes Gerät/Software behandelt werden. In allen Fällen erfordert die gMSA, die von HGS verwendet wird, Leseberechtigungen für die Verschlüsselung, Signatur und Kommunikationszertifikat private Schlüssel, damit sie Signierungs- und Verschlüsselungsvorgänge ausführen kann.

Einige Hardwaresicherheitsmodule unterstützen nicht die Gewährung bestimmter Benutzerkonten für einen privaten Schlüssel; Stattdessen ermöglichen sie dem Computerkonto Zugriff auf alle Schlüssel in einem bestimmten Schlüsselsatz. Für solche Geräte ist es in der Regel ausreichend, dem Computer Zugriff auf Ihre Schlüssel zu geben und HGS kann diese Verbindung nutzen.

Tipps für HSMs

Nachfolgend finden Sie vorgeschlagene Konfigurationsoptionen, um Ihnen die erfolgreiche Verwendung von HSM-gesicherten Schlüsseln mit HGS basierend auf den Erfahrungen von Microsoft und seinen Partnern zu helfen. Diese Tipps werden für Ihre Bequemlichkeit bereitgestellt und sind nicht garantiert, dass sie zum Zeitpunkt des Lesens richtig sind, oder sie werden von den HSM-Herstellern unterstützt. Wenden Sie sich an Ihren HSM-Hersteller, um genaue Informationen zu Ihrem spezifischen Gerät zu erhalten, wenn Sie weitere Fragen haben.

HSM-Marke/Serie Vorschlag
Gemalto SafeNet Stellen Sie sicher, dass die Key Usage-Eigenschaft in der Zertifikatanforderungsdatei auf 0xa0 festgelegt ist, sodass das Zertifikat für die Signatur und Verschlüsselung verwendet werden kann. Darüber hinaus müssen Sie dem gMSA-Konto Lesezugriff auf den privaten Schlüssel erteilen, indem Sie das lokale Zertifikat-Manager-Tool verwenden (siehe schritte oben).
nCipher nShield Stellen Sie sicher, dass jeder HGS-Knoten Zugriff auf die Sicherheitswelt hat, die die Signatur- und Verschlüsselungsschlüssel enthält. Darüber hinaus müssen Sie den gMSA-Lesezugriff auf den privaten Schlüssel mithilfe des lokalen Zertifikat-Managers gewähren (siehe oben).
Utimaco CryptoServers Stellen Sie sicher, dass die Key Usage-Eigenschaft in der Zertifikatanforderungsdatei auf 0x13 festgelegt ist, sodass das Zertifikat für Verschlüsselung, Entschlüsselung und Signatur verwendet werden kann.

Zertifikatanforderungen

Wenn Sie eine Zertifizierungsstelle verwenden, um Ihre Zertifikate in einer PKI-Umgebung (Public Key Infrastructure) zu stellen, müssen Sie sicherstellen, dass Ihre Zertifikatanforderung die Mindestanforderungen für die Verwendung dieser Schlüssel enthält.

Signieren von Zertifikaten

CSR-Eigenschaft Erforderlicher Wert
Algorithmus RSA
Schlüsselgröße Mindestens 2048 Bit
Schlüsselverwendung Signature/Sign/DigitalSignature

Verschlüsselungszertifikate

CSR-Eigenschaft Erforderlicher Wert
Algorithmus RSA
Schlüsselgröße Mindestens 2048 Bit
Schlüsselverwendung Verschlüsselung/Verschlüsseln/DataEncipherment

Vorlagen für Active Directory-Zertifikatdienste

Wenn Sie Active Directory-Zertifikatdienste (ADCS)-Zertifikatvorlagen zum Erstellen der Zertifikate verwenden, empfehlen wir Ihnen, eine Vorlage mit den folgenden Einstellungen zu verwenden:

ADCS-Vorlageneigenschaft Erforderlicher Wert
Anbieterkategorie Schlüsselspeicheranbieter
Algorithmusname RSA
Mindestschlüsselgröße 2048
Zweck Signatur und Verschlüsselung
Schlüsselverwendungserweiterung Digitale Signatur, Key Encipherment, Data Encipherment ("Zulassen der Verschlüsselung von Benutzerdaten")

Zeitdrift

Wenn sich die Zeit Ihres Servers erheblich von den anderen HGS-Knoten oder Hyper-V-Hosts in Ihrem geschützten Fabric bewegt hat, können Sie Probleme mit der Gültigkeit des Zertifikats für die Zertifizierungszeichen haben. Das Zertifizierungszeichenzertifikat wird erstellt und hinter den Kulissen auf HGS erstellt und erneuert und wird verwendet, um Integritätszertifikate zu signieren, die von dem Attestationsdienst ausgestellt wurden.

Führen Sie den folgenden Befehl in einer PowerShell-Eingabeaufforderung mit erhöhten Rechten aus, um das Zertifizierungszeichenzertifikat zu aktualisieren.

Start-ScheduledTask -TaskPath \Microsoft\Windows\HGSServer -TaskName
AttestationSignerCertRenewalTask

Alternativ können Sie die geplante Aufgabe manuell ausführen, indem Sie den Taskplaner (taskschd.msc) öffnen, in der Taskplanerbibliothek > microsoft > Windows > HGSServer navigieren und den Vorgang mit dem Namen AttestationSignerCertRenewalTask ausführen.

Wechseln von Nachweismodi

Wenn Sie HGS vom TPM-Modus in den Active Directory-Modus oder umgekehrt über das Cmdlet "Set-HgsServer " wechseln, kann es bis zu 10 Minuten dauern, bis jeder Knoten im HGS-Cluster zum Erzwingen des neuen Zertifizierungsmodus benötigt wird. Dies ist normales Verhalten. Es wird empfohlen, keine Richtlinien zu entfernen, die Hosts aus dem vorherigen Nachweismodus zulassen, bis Sie überprüft haben, dass alle Hosts erfolgreich den neuen Nachweismodus verwenden.

Bekanntes Problem beim Wechseln von TPM zu AD-Modus

Wenn Sie Ihren HGS-Cluster im TPM-Modus initialisiert und später in den Active Directory-Modus wechseln, gibt es ein bekanntes Problem, das verhindert, dass andere Knoten in Ihrem HGS-Cluster zum neuen Nachweismodus wechseln. Um sicherzustellen, dass alle HGS-Server den richtigen Nachweismodus erzwingen, führen Sie auf jedem Knoten Ihres HGS-Clusters ausSet-HgsServer -TrustActiveDirectory. Dieses Problem gilt nicht, wenn Sie vom TPM-Modus zum AD-Modus wechseln und das Cluster ursprünglich im AD-Modus eingerichtet wurde.

Sie können den Nachweismodus Ihres HGS-Servers überprüfen, indem Sie Get-HgsServer ausführen.

Richtlinien zur Speicherabbildverschlüsselung

Wenn Sie versuchen, Speicherabbildverschlüsselungsrichtlinien zu konfigurieren und die Standard-HGS-Dumprichtlinien (Hgs_NoDumps, Hgs_DumpEncryption und Hgs_DumpEncryptionKey) oder das Cmdlet "Dumprichtlinien" (Add-HgsAttestationDumpPolicy) nicht anzuzeigen, ist es wahrscheinlich, dass das neueste kumulative Update nicht installiert ist. Um dies zu beheben, aktualisieren Sie Ihren HGS-Server auf das neueste kumulative Windows Update und aktivieren Sie die neuen Zertifizierungsrichtlinien. Stellen Sie sicher, dass Sie Ihre Hyper-V-Hosts auf das gleiche kumulative Update aktualisieren, bevor Sie die neuen Zertifizierungsrichtlinien aktivieren, da Hosts, die nicht über die neuen Speicherabbildverschlüsselungsfunktionen verfügen, wahrscheinlich eine Bestätigung fehlschlägt, sobald die HGS-Richtlinie aktiviert wird.

Fehlermeldungen des Bestätigungsschlüsselzertifikats

Beim Registrieren eines Hosts mithilfe des Cmdlets Add-HgsAttestationTpmHost werden zwei TPM-Bezeichner aus der bereitgestellten Plattformbezeichnerdatei extrahiert: das Bestätigungsschlüsselzertifikat (EKcert) und der öffentliche Bestätigungsschlüssel (EKpub). Die EKcert identifiziert den Hersteller des TPM, wodurch gewährleistet wird, dass das TPM authentifiziert und über die normale Lieferkette hergestellt wird. Das EKpub identifiziert eindeutig, dass bestimmte TPM und eine der Maßnahmen ist, die HGS verwendet, um einen Hostzugriff auf geschirmte VMs zu gewähren.

Beim Registrieren eines TPM-Hosts wird ein Fehler angezeigt, wenn eine der beiden Bedingungen wahr ist:

  1. Die Plattformbezeichnerdatei enthält kein Bestätigungsschlüsselzertifikat
  2. Die Plattformbezeichnerdatei enthält ein Bestätigungsschlüsselzertifikat, aber dieses Zertifikat ist auf Ihrem System nicht vertrauenswürdig .

Bestimmte TPM-Hersteller enthalten keine EKcerts in ihren TPMs. Wenn Sie vermuten, dass dies bei Ihrem TPM der Fall ist, bestätigen Sie mit Ihrem OEM, dass Ihre TPMs keine EKcert haben sollten und das Flag verwenden, um den -Force Host manuell mit HGS zu registrieren. Wenn Ihr TPM über eine EKcert verfügen sollte, aber eine nicht in der Plattformbezeichnerdatei gefunden wurde, stellen Sie sicher, dass Sie eine PowerShell-Konsole (mit erhöhten Rechten) verwenden, wenn Sie Get-PlatformIdentifier auf dem Host ausführen.

Wenn Sie den Fehler erhalten haben, dass Ihr EKcert nicht vertrauenswürdig ist, stellen Sie sicher, dass Sie das vertrauenswürdige TPM-Stammzertifikatpaket auf jedem HGS-Server installiert haben und dass das Stammzertifikat für Ihren TPM-Anbieter im TrustedTPM_RootCA Store des lokalen Computers vorhanden ist. Alle anwendbaren Zwischenzertifikate müssen auch auf dem lokalen Computer im TrustedTPM_IntermediateCA Store installiert werden. Nach der Installation der Stamm- und Zwischenzertifikate sollten Sie erfolgreich ausgeführt Add-HgsAttestationTpmHost werden können.

Berechtigungen für verwaltete Dienste (Group Managed Service Account, gMSA)

HGS-Dienstkonto (gMSA, das für den Key Protection Service-Anwendungspool in IIS verwendet wird) muss die Berechtigung "Sicherheitsüberprüfungen generieren " erteilt werden, auch bekannt als SeAuditPrivilege. Wenn diese Berechtigung fehlt, ist die anfängliche HGS-Konfiguration erfolgreich und IIS startet, aber der Key Protection Service ist nicht funktionsfähig und gibt HTTP-Fehler 500 ("Serverfehler in /KeyProtection-Anwendung") zurück. Sie können auch die folgenden Warnungsmeldungen im Anwendungsereignisprotokoll beobachten.

System.ComponentModel.Win32Exception (0x80004005): A required privilege is not held by the client
at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.NativeUtility.RegisterAuditSource(String pszSourceName, SafeAuditProviderHandle& phAuditProvider)
at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.RegisterAuditSource(String sourceName)

oder

Failed to register the security event source.
   at System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app)
   at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
   at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
   at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
   at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)

Failed to register the security event source.
   at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.RegisterAuditSource(String sourceName)
   at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.ReportAudit(EventLogEntryType eventType, UInt32 eventId, Object[] os)
   at Microsoft.Windows.KpsServer.KpsServerHttpApplication.Application_Start()

A required privilege is not held by the client
   at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.NativeUtility.RegisterAuditSource(String pszSourceName, SafeAuditProviderHandle& phAuditProvider)
   at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.RegisterAuditSource(String sourceName)

Darüber hinaus können Sie feststellen, dass keine der Key Protection Service-Cmdlets (z. B. Get-HgsKeyProtectionCertificate) funktionieren und stattdessen Fehler zurückgeben.

Um dieses Problem zu beheben, müssen Sie gMSA die "Generieren von Sicherheitsprüfungen" (SeAuditPrivilege) gewähren. Dazu können Sie entweder lokale Sicherheitsrichtlinien SecPol.msc für jeden Knoten des HGS-Clusters oder Gruppenrichtlinie verwenden. Alternativ können Sie SecEdit.exe Tool verwenden, um die aktuelle Sicherheitsrichtlinie zu exportieren, die erforderlichen Bearbeitungen in der Konfigurationsdatei (was ein nur Text ist), und importieren Sie sie dann wieder.

Hinweis

Wenn Sie diese Einstellung konfigurieren, wird die Liste der für ein Recht definierten Sicherheitsprinzipien vollständig außer Kraft gesetzt (es wird nicht verketten). Wenn Sie diese Richtlinieneinstellung definieren, müssen Sie daher beide Standardhalter dieses Rechtes (Netzwerkdienst und lokaler Dienst) neben dem gMSA enthalten, den Sie hinzufügen.