Freigeben über

Problembehandlung beim Host Guardian-Dienst

  • Artikel

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

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

Wenn Sie sich nicht sicher sind, wie das Problem vorliegt, versuchen Sie zunächst, die geschützte Fabric-Diagnose auf Ihren HGS-Servern und Hyper-V-Hosts auszuführen, um die potenziellen Ursachen einzugrenzen.

Zertifikate

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

Zertifikatberechtigungen

HGS muss sowohl auf die öffentlichen als auch auf die privaten Schlüssel der Verschlüsselungs- und Signaturzertifikate zugreifen können, die HGS durch den Zertifikatfingerabdruck hinzugefügt wurden. Insbesondere benötigt das gruppenverwaltete Dienstkonto (Group Managed Service Account, gMSA), das den HGS-Dienst ausführt, Zugriff auf die Schlüssel. Um das von HGS verwendete gMSA zu finden, 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 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 mit einem benutzerdefinierten Drittanbieter für Schlüsselspeicher.

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

Wenn Sie ein selbstsigniertes Zertifikat oder ein von einer Zertifizierungsstelle ausgestelltes Zertifikat verwenden, das 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 Sie den lokalen Zertifikat-Manager (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" 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 in der Objektauswahl den gMSA-Kontonamen für das zuvor gefundene HGS ein, und wählen Sie dann OK aus.
  6. Stellen Sie sicher, dass das gMSA Lesezugriff auf das Zertifikat hat.
  7. Klicken Sie auf OK, um das Fenster mit den Berechtigungen zu schließen.

Wenn Sie HGS auf Server Core ausführen oder den Server remote verwalten, können Sie private Schlüssel nicht über den lokalen Zertifikat-Manager 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 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.
  2. Führen Sie die folgenden Befehle aus, um das Guarded Fabric Tools PowerShell-Modul 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 softwaregestützte private Schlüssel

Wenn die privaten Schlüssel Ihres Zertifikats durch ein Hardwaresicherheitsmodul (Hardware Security Module, HSM) oder einen benutzerdefinierten Schlüsselspeicheranbieter (Key Storage Provider, KSP) gesichert werden, hängt das Berechtigungsmodell von Ihrem jeweiligen Softwareanbieter ab. Die besten Ergebnisse finden Sie in der Dokumentation Ihres Anbieters oder auf der Supportwebsite. Dort erhalten Sie Informationen dazu, wie Berechtigungen für private Schlüssel für Ihr bestimmtes Gerät/Ihre spezifische Software behandelt werden. In allen Fällen erfordert die von HGS verwendete gMSA Leseberechtigungen für die privaten Schlüssel des Verschlüsselungs-, Signatur- und Kommunikationszertifikats, damit Signatur- und Verschlüsselungsvorgänge ausgeführt werden können.

Einige Hardwaresicherheitsmodule unterstützen nicht das Gewähren bestimmter Benutzerkonten auf einen privaten Schlüssel; Vielmehr ermöglichen sie dem Computerkonto zugriff auf alle Schlüssel in einem bestimmten Schlüsselsatz. Für solche Geräte reicht es in der Regel aus, 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 vorgeschlagenen Konfigurationsoptionen, die Ihnen bei der erfolgreichen Verwendung HSM-gestützter Schlüssel mit HGS basierend auf den Erfahrungen von Microsoft und seinen Partnern helfen. Diese Tipps werden für Ihren Komfort bereitgestellt und sind nicht garantiert, zum Zeitpunkt der Lektüre korrekt zu sein, noch werden sie 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 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 Sicherheitswelt mit den Signatur- und Verschlüsselungsschlüsseln hat. Darüber hinaus können Sie gMSA 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 zum Verschlüsseln, Entschlüsseln und Signieren 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 enthält.

Signaturzertifikate

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

Verschlüsselungszertifikate

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

Active Directory-Zertifikatdienste-Vorlagen

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

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 von anderen HGS-Knoten oder Hyper-V-Hosts in Ihrem geschützten Fabric abweicht, können Probleme mit der Gültigkeit des Signaturgeberzertifikats für Nachweise vorliegen. Das Signaturgeberzertifikat für Nachweise wird im Hintergrund von HGS erstellt und erneuert und wird verwendet, um Integritätszertifikate zu signieren, 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 Signaturgeberzertifikat für Nachweise zu aktualisieren.

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

Alternativ können Sie den geplanten Vorgang manuell ausführen, indem Sie den Task Scheduler (taskschd.msc) öffnen, zu Task Scheduler Library>Microsoft>Windows>HGSServer navigieren und die Aufgabe "AttestationSignerCertRenewalTask" ausführen.

Wechseln zwischen Nachweismodi

Wenn Sie mit dem Cmdlet Set-HgsServer vom TPM-Modus in den Active Directory-Modus wechseln oder umgekehrt, 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, dass alle Hosts erfolgreich den neuen Nachweismodus verwenden.

Bekanntes Problem beim Wechsel vom TPM- in den 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 in den neuen Nachweismodus wechseln. Um sicherzustellen, dass alle HGS-Server den richtigen Nachweismodus erzwingen, führen Sie Set-HgsServer -TrustActiveDirectory sie auf jedem Knoten Ihres HGS-Clusters aus.

Dieses Problem gilt nicht, 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.

Verschlüsselungsrichtlinien für Speicherabbilder

Wenn Sie versuchen, Speicherabbild-Verschlüsselungsrichtlinien zu konfigurieren und die standardmäßigen HGS-Speicherabbildrichtlinien (Hgs_NoDumps, Hgs_DumpEncryption und Hgs_DumpEncryptionKey) oder das Speicherabbildrichtlinien-Cmdlet (Add-HgsAttestationDumpPolicy) nicht angezeigt werden, 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 Nachweisrichtlinien.

Stellen Sie sicher, dass Sie Ihre Hyper-V-Hosts auf dasselbe kumulative Update aktualisieren, bevor Sie die neuen Nachweisrichtlinien aktivieren, da Hosts, die nicht über die installierten neuen Speicherabbildverschlüsselungsfunktionen verfügen, wahrscheinlich einen Nachweis fehlschlagen, sobald die HGS-Richtlinie aktiviert ist.

Fehlermeldungen zum Endorsement Key-Zertifikat

Wenn Sie einen Host mithilfe des Add-HgsAttestationTpmHost-Cmdlets registrieren, werden zwei TPM-IDs aus der bereitgestellten Plattform-ID-Datei extrahiert: das Bestätigungsschlüsselzertifikat (EKcert) und der öffentliche Bestätigungsschlüssel (EKpub). Das EKcert identifiziert den Hersteller des TPM und gewährleistet, dass das TPM authentisch ist und über die normale Lieferkette hergestellt wird. Der EKpub identifiziert dieses spezifische TPM eindeutig und ist eine der Maßnahmen, die HGS verwendet, um einem Host Zugriff zum Ausführen abgeschirmter VMs zu gewähren.

Sie erhalten eine Fehlermeldung, wenn Sie einen TPM-Host registrieren, wenn eine der beiden Bedingungen zutrifft:

  • Die Plattform-ID-Datei enthält kein Bestätigungsschlüsselzertifikat.
  • Die Plattform-ID-Datei enthält ein Bestätigungsschlüsselzertifikat, dieses Zertifikat ist jedoch 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, vergewissern Sie sich bei 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 soll, aber in der Plattform-ID-Datei nicht 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 Paket für vertrauenswürdige TPM-Stammzertifikate auf jedem HGS-Server installiert haben und dass das Stammzertifikat für Ihren TPM-Anbieter im Speicher "TrustedTPM_RootCA" 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, Add-HgsAttestationTpmHost erfolgreich auszuführen.

Berechtigungen für gruppenverwaltete Dienstkonten (gMSA)

Das HGS-Dienstkonto (gMSA, das für den Schlüsselschutzdienst-Anwendungspool in IIS verwendet wird) muss die Berechtigung Generieren von Sicherheitsüberwachungen erhalten, die auch als SeAuditPrivilege bezeichnet wird. Wenn diese Berechtigung fehlt, ist die anfängliche HGS-Konfiguration erfolgreich und IIS wird gestartet, der Schlüsselschutzdienst ist jedoch nicht funktionsfähig und gibt DEN HTTP-Fehler 500 ("Serverfehler in /KeyProtection-Anwendung") zurück. Sie können auch die folgenden Warnmeldungen 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)

or

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 stellen Sie möglicherweise fest, 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 "Generieren von Sicherheitsüberwachungen" (SeAuditPrivilege) erteilen. Dazu können Sie entweder die lokale Sicherheitsrichtlinie SecPol.msc auf jedem Knoten des HGS-Clusters oder gruppenrichtlinien verwenden. Alternativ können Sie das Tool SecEdit.exe verwenden, um die aktuelle Sicherheitsrichtlinie zu exportieren, die erforderlichen Änderungen in der Konfigurationsdatei (unverschlüsselt) vorzunehmen und sie dann wieder zu importieren.

Notiz

Bei der Konfiguration dieser Einstellung überschreibt die Liste der für ein Berechtigung definierten Sicherheitsprinzipien die Standardwerte vollständig (nicht verkettet). Achten Sie daher beim Definieren dieser Richtlinieneinstellung darauf, dass sie zusätzlich zu der von Ihnen hinzugefügten gMSA beide Standardinhaber dieser Berechtigung (Netzwerkdienst und lokaler Dienst) enthalten.