Problembehandlung für den Host-Überwachungsdienst

Artikel
12/26/2023

In diesem Artikel werden Lösungen für häufige Probleme beschrieben, die beim Bereitstellen oder Betreiben eines Host-Überwachungsdienst-Servers (Host Guardian Service, HGS) in einem geschützten Fabric auftreten.

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

Wenn Sie sich nicht sicher sind, welche Art das Problem hat, versuchen Sie zunächst, das geschützte Fabric Diagnose auf Ihren HGS-Servern und Hyper-V-Hosts auszuführen, um die möglichen Ursachen einzugrenzen.

Zertifikate

HGS erfordert für den Betrieb mehrere Zertifikate, einschließlich des vom Administrator konfigurierten Verschlüsselungs- und Signaturzertifikats sowie eines Nachweiszertifikats, das von HGS selbst verwaltet wird. Wenn diese Zertifikate falsch konfiguriert sind, kann HGS keine Anforderungen von Hyper-V-Hosts verarbeiten, die Schlüsselschutzvorrichtungen für abgeschirmte VMs nachweisen oder entsperren möchten. In den folgenden Abschnitten werden häufige Probleme im Zusammenhang mit Zertifikaten behandelt, die in HGS konfiguriert sind.

Zertifikatberechtigungen

HGS muss sowohl auf die öffentlichen als auch auf den privaten Schlüssel der Verschlüsselungs- und Signaturzertifikate zugreifen können, die dem HGS durch den Zertifikatfingerabdruck hinzugefügt wurden. Insbesondere das gruppenverwaltete Dienstkonto (gMSA), das den HGS-Dienst ausführt, benötigt Zugriff auf die Schlüssel. Führen Sie den folgenden Befehl in einer PowerShell-Eingabeaufforderung mit erhöhten Rechten auf Ihrem HGS-Server aus, um den vom HGS verwendeten GMSA zu ermitteln:

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

Wie Sie dem gMSA-Konto Zugriff zur 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 bei Verwendung eines benutzerdefinierten Drittanbieters für Schlüsselspeicher.

Gewähren des Zugriffs auf softwaregestützte private Schlüssel

Wenn Sie ein selbstsigniertes Zertifikat oder ein Zertifikat verwenden, das von einer Zertifizierungsstelle ausgestellt wurde, 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:

Öffnen Sie den lokalen Zertifikat-Manager (certlm.msc).
Erweitern Sie Persönliche>Zertifikate, und suchen Sie das Signatur- oder Verschlüsselungszertifikat, das Sie aktualisieren möchten.
Klicken Sie mit der rechten Maustaste auf das Zertifikat, und wählen Sie Alle Aufgaben>Private Schlüssel verwalten aus.
Wählen Sie Hinzufügen aus, um einem neuen Benutzer Zugriff auf den privaten Schlüssel des Zertifikats zu gewähren.
Geben Sie in der Objektauswahl den zuvor gefundenen gMSA-Kontonamen für HGS ein, und wählen Sie dann OK aus.
Stellen Sie sicher, dass der gMSA über Lesezugriff auf das Zertifikat verfügt.
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 private Schlüssel nicht 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.

Öffnen Sie eine PowerShell-Konsole mit erhöhten Rechten auf dem Server Core-Computer, oder verwenden Sie PowerShell Remoting mit einem Konto, das über lokale Administratorberechtigungen für HGS verfügt.
Führen Sie die folgenden Befehle aus, um das PowerShell-Modul Guarded Fabric Tools zu installieren und dem gMSA-Konto Zugriff auf den privaten Schlüssel zu gewähren.

$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) gesichert werden, hängt das Berechtigungsmodell von Ihrem jeweiligen Softwareanbieter ab. Die besten Ergebnisse finden Sie in der Dokumentation oder auf der Supportwebsite Ihres Anbieters, um Informationen darüber zu erhalten, wie Berechtigungen für private Schlüssel für Ihr bestimmtes Gerät/Ihre Software behandelt werden. In allen Fällen erfordert die vom HGS verwendete gMSA Leseberechtigungen für die privaten Schlüssel des Verschlüsselungs-, Signatur- und Kommunikationszertifikats, damit sie Signierungs- und Verschlüsselungsvorgänge ausführen kann.

Einige Hardwaresicherheitsmodule unterstützen nicht, bestimmten Benutzerkonten Zugriff auf einen privaten Schlüssel zu gewähren. stattdessen erlauben sie dem Computerkonto den 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 gewähren, und HGS kann diese Verbindung nutzen.

Tipps für HSMs

Im Folgenden finden Sie die empfohlenen Konfigurationsoptionen, die Ihnen dabei helfen sollen, HSM-gestützte Schlüssel mit HGS basierend auf den Erfahrungen von Microsoft und seinen Partnern erfolgreich zu verwenden. Diese Tipps werden zu Ihrer Bequemlichkeit bereitgestellt und sind nicht garantiert, dass sie zum Zeitpunkt der Lektüre korrekt sind, noch werden sie von den HSM-Herstellern unterstützt. Wenn Sie weitere Fragen haben, wenden Sie sich an ihren HSM-Hersteller, um genaue Informationen zu Ihrem spezifischen Gerät zu erhalten.

HSM-Marke/-Serie	Vorschlag
Gemalto SafeNet	Stellen Sie sicher, dass die Schlüsselverwendungseigenschaft in der Zertifikatanforderungsdatei auf 0xa0 festgelegt ist, sodass das Zertifikat zum Signieren und Verschlüsseln verwendet werden kann. Darüber hinaus müssen Sie dem gMSA-Konto Lesezugriff auf den privaten Schlüssel mithilfe des lokalen Zertifikat-Manager-Tools gewähren (siehe schritte oben).
nCipher nShield	Stellen Sie sicher, dass jeder HGS-Knoten Zugriff auf die Sicherheitsumgebung hat, die die Signatur- und Verschlüsselungsschlüssel enthält. Möglicherweise müssen Sie dem gMSA außerdem Lesezugriff auf den privaten Schlüssel mithilfe des lokalen Zertifikat-Managers gewähren (siehe schritte oben).
Utimaco CryptoServers	Stellen Sie sicher, dass die Schlüsselverwendungseigenschaft in der Zertifikatanforderungsdatei auf 0x13 festgelegt ist, sodass das Zertifikat für die 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) auszustellen, müssen Sie sicherstellen, dass Ihre Zertifikatanforderung die Mindestanforderungen für die Verwendung dieser Schlüssel durch den HGS enthält.

Signaturzertifikate

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

Verschlüsselungszertifikate

CSR-Eigenschaft	Erforderlicher Wert
Algorithmus	RSA
Schlüsselgröße	Mindestens 2048 Bits
Schlüsselverwendung	Verschlüsselung/Verschlüsselung/Datenverschlüsselung

Vorlagen für Active Directory-Zertifikatdienste

Wenn Sie ADCS-Zertifikatvorlagen (Active Directory Certificate Services) zum Erstellen der Zertifikate verwenden, wird empfohlen, eine Vorlage mit den folgenden Einstellungen zu verwenden:

ADCS-Vorlageneigenschaft	Erforderlicher Wert
Anbieterkategorie	Schlüsselspeicheranbieter
Algorithmusname	RSA
Minimale Schlüsselgröße	2048
Zweck	Signatur und Verschlüsselung
Schlüsselverwendungserweiterung	Digitale Signatur, Schlüsselverschlüsselung, Datenverschlüsselung ("Verschlüsselung von Benutzerdaten zulassen")

Zeitabweichung

Wenn die Zeit Ihres Servers erheblich von der Zeit anderer HGS-Knoten oder Hyper-V-Hosts in Ihrem geschützten Fabric abgedrift ist, können Probleme mit der Gültigkeit des Zertifikats des Nachweisgeberzertifikats auftreten. Das Nachweis-Signaturgeberzertifikat wird im Hintergrund im HGS erstellt und erneuert und zum Signieren von Integritätszertifikaten verwendet, die vom Nachweisdienst für überwachte Hosts ausgestellt wurden.

Führen Sie den folgenden Befehl in einer PowerShell-Eingabeaufforderung mit erhöhten Rechten aus, um das Zertifikat für den Nachweis signierer 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, zur Taskplanerbibliothek>Microsoft>Windows>HGSServer navigieren und den Task attestationSignerCertRenewalTask ausführen.

Wechseln der Nachweismodi

Wenn Sie mit dem Cmdlet Set-HgsServer vom TPM-Modus in den Active Directory-Modus oder umgekehrt wechseln, kann es bis zu 10 Minuten dauern, bis jeder Knoten in Ihrem HGS-Cluster mit der Erzwingung des neuen Nachweismodus beginnt.

Dies ist ein normales Verhalten.

Es wird empfohlen, dass Sie keine Richtlinien entfernen, die Hosts aus dem vorherigen Nachweismodus zulassen, bis Sie überprüft haben, ob alle Hosts den Nachweis erfolgreich mithilfe des neuen Nachweismodus bestätigen.

Bekanntes Problem beim Wechsel vom TPM in den AD-Modus

Wenn Sie Ihren HGS-Cluster im TPM-Modus initialisiert haben und später in den Active Directory-Modus wechseln, gibt es ein bekanntes Problem, das andere Knoten in Ihrem HGS-Cluster daran hindert, in den neuen Nachweismodus zu wechseln. Um sicherzustellen, dass alle HGS-Server den richtigen Nachweismodus erzwingen, führen Sie Set-HgsServer -TrustActiveDirectory auf jedem Knoten Ihres HGS-Clusters aus.

Dieses Problem tritt nicht auf, wenn Sie vom TPM-Modus in den AD-Modus wechseln und der Cluster ursprünglich im AD-Modus eingerichtet wurde.

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

Speicherabbildverschlüsselungsrichtlinien

Wenn Sie versuchen, Verschlüsselungsrichtlinien für Speicherabbilder zu konfigurieren und die Standardmäßigen HGS-Speicherabbildrichtlinien (Hgs_NoDumps, Hgs_DumpEncryption und Hgs_DumpEncryptionKey) oder das Dumprichtlinien-Cmdlet (Add-HgsAttestationDumpPolicy) nicht angezeigt werden, ist es wahrscheinlich, dass Das neueste kumulative Update nicht installiert ist.

Um dieses Problem zu beheben, aktualisieren Sie Ihren HGS-Server auf das neueste kumulative Windows-Update, und aktivieren Sie die neuen Nachweisrichtlinien.

Stellen Sie sicher, dass Sie Ihre Hyper-V-Hosts auf dasselbe kumulative Update aktualisieren, bevor Sie die neuen Nachweisrichtlinien aktivieren, da Hosts, auf denen die neuen Speicherabbildverschlüsselungsfunktionen nicht installiert sind, den Nachweis wahrscheinlich fehlschlägt, sobald die HGS-Richtlinie aktiviert wurde.

Fehlermeldungen des Endorsement Key-Zertifikats

Wenn Sie einen Host mit dem Cmdlet Add-HgsAttestationTpmHost registrieren, werden aus der bereitgestellten Plattformbezeichnerdatei zwei TPM-IDs extrahiert: das Endorsement Key-Zertifikat (EKcert) und der öffentliche Endorsement Key (EKpub). Das EKcert identifiziert den Hersteller des TPM und gewährleistet, dass das TPM authentisch ist und über die normale Lieferkette hergestellt wird. Das EKpub identifiziert dieses bestimmte TPM eindeutig und ist eine der Maßnahmen, die HGS verwendet, um einem Host Zugriff zum Ausführen von abgeschirmten VMs zu gewähren.

Wenn Sie einen TPM-Host registrieren, erhalten Sie eine Fehlermeldung, wenn eine der beiden Bedingungen erfüllt ist:

Die Plattformbezeichnerdatei enthält kein Endorsement Key-Zertifikat.
Die Plattformbezeichnerdatei enthält ein Endorsement Key-Zertifikat, aber dieses Zertifikat ist auf Ihrem System nicht vertrauenswürdig.

Bestimmte TPM-Hersteller schließen EKcerts nicht in ihre TPMs ein.

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

Wenn Sie die Fehlermeldung 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-Speicher des lokalen Computers vorhanden ist. Alle anwendbaren Zwischenzertifikate müssen auch im speicher "TrustedTPM_IntermediateCA" auf dem lokalen Computer installiert werden. Nach der Installation der Stamm- und Zwischenzertifikate sollten Sie in der Lage sein, erfolgreich auszuführen Add-HgsAttestationTpmHost .

Gruppenverwaltete Dienstkontoberechtigungen (Group Managed Service Account, gMSA)

Das HGS-Dienstkonto (gMSA, das in IIS für den Anwendungspool des Schlüsselschutzdiensts verwendet wird) muss die Berechtigung Sicherheitsüberwachung generieren erteilt werden, die auch als SeAuditPrivilegebezeichnet wird. Wenn diese Berechtigung fehlt, ist die erste HGS-Konfiguration erfolgreich, und IIS wird gestartet. Der Schlüsselschutzdienst ist jedoch nicht funktionsfähig und gibt den HTTP-Fehler 500 ("Serverfehler in /KeyProtection Application") zurück. Sie können auch die folgenden Warnmeldungen im Anwendungsereignisprotokoll sehen.

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 keines der Key Protection Service-Cmdlets (z. B. Get-HgsKeyProtectionCertificate) funktioniert und stattdessen Fehler zurückgibt.

Um dieses Problem zu beheben, müssen Sie gMSA die Option "Generieren von Sicherheitsüberwachungen" (SeAuditPrivilege) gewähren. Dazu können Sie entweder die lokale Sicherheitsrichtlinie SecPol.msc auf jedem Knoten des HGS-Clusters oder Gruppenrichtlinie verwenden. Alternativ können Sie SecEdit.exe Tool verwenden, um die aktuelle Sicherheitsrichtlinie zu exportieren, die erforderlichen Änderungen in der Konfigurationsdatei (bei der es sich um einen Nur-Text handelt) vorzunehmen und sie dann wieder zu importieren.

Hinweis

Beim Konfigurieren dieser Einstellung setzt die Liste der Sicherheitsprinzipien, die für eine Berechtigung definiert sind, die Standardeinstellungen vollständig außer Kraft (sie wird nicht verkettet). Achten Sie daher beim Definieren dieser Richtlinieneinstellung darauf, dass Sie zusätzlich zu dem gMSA, den Sie hinzufügen, beide Standardinhaber dieser Berechtigung (Netzwerkdienst und Lokaler Dienst) einschließen.