Solución de problemas del servicio de protección de host

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este artículo se describen las soluciones a los problemas comunes que se encuentran al implementar o usar un servidor del Servicio de protección de host (HGS) en un tejido de protección. Si no está seguro de la naturaleza del problema, primero intente ejecutar los diagnósticos de tejidos guardados en los servidores HGS y los hosts de Hyper-V para restringir las posibles causas.

Certificados

HGS requiere varios certificados para funcionar, incluido el certificado de firma y cifrado configurado por el administrador, así como un certificado de atestación administrado por el propio HGS. Si estos certificados no están configurados correctamente, HGS no podrá atender las solicitudes de los hosts de Hyper-V que deseen atestiguar o desbloquear protectores de claves para máquinas virtuales blindadas. Las secciones siguientes cubren problemas comunes relacionados con los certificados configurados en HGS.

Permisos de certificado

HGS debe poder acceder a las claves públicas y privadas de los certificados de cifrado y firma agregados a HGS mediante la huella digital del certificado. En concreto, la cuenta de servicio administrada de grupo (gMSA) que ejecuta el servicio HGS necesita acceso a las claves. Para buscar la gMSA que usa HGS, ejecute el siguiente comando en un símbolo del sistema de PowerShell con privilegios elevados en el servidor HGS:

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

La forma de conceder acceso a la cuenta de gMSA para usar la clave privada depende de dónde se almacene la clave: en la máquina como un archivo de certificado local, en un módulo de seguridad de hardware (HSM) o mediante un proveedor de almacenamiento de claves de terceros personalizado.

Concesión de acceso a claves privadas con respaldo de software

Si usa un certificado autofirmado o un certificado emitido por una entidad de certificación que no está almacenado en un módulo de seguridad de hardware o en un proveedor de almacenamiento de claves personalizado, puede cambiar los permisos de clave privada mediante los pasos siguientes:

  1. Abrir el administrador de certificados local (certlm.msc)
  2. Expanda Certificados personales y busque el certificado de firma o cifrado que desea actualizar.
  3. Haga clic con el botón derecho en el certificado y seleccione Todas las tareas Administrar claves privadas.
  4. Seleccione Agregar para conceder a un nuevo usuario acceso a la clave privada del certificado.
  5. En el selector de objetos, escriba el nombre de la cuenta de gMSA para HGS que se encontró anteriormente y, a continuación, seleccione Aceptar.
  6. Asegúrese de que la gMSA tiene acceso de lectura al certificado.
  7. Seleccione Aceptar para cerrar la ventana de permisos.

Si ejecuta HGS en Server Core o administra el servidor de forma remota, no podrá administrar claves privadas mediante el administrador de certificados local. En su lugar, deberá descargar el módulo de PowerShell Guarded Fabric Tools, que le permitirá administrar los permisos en PowerShell.

  1. Abra una consola de PowerShell con privilegios elevados en el equipo Server Core o use la comunicación remota de PowerShell con una cuenta que tenga permisos de administrador local en HGS.
  2. Ejecute los siguientes comandos para instalar el módulo de PowerShell Guarded Fabric Tools y conceder a la cuenta gMSA acceso a la clave privada.
$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

Concesión de acceso a HSM o claves privadas personalizadas con respaldo del proveedor

Si las claves privadas del certificado están protegidas por un módulo de seguridad de hardware (HSM) o un proveedor de almacenamiento de claves personalizado (KSP), el modelo de permisos dependerá del proveedor de software específico. Para obtener los mejores resultados, consulte la documentación del proveedor o el sitio de soporte técnico para obtener información sobre cómo se administran los permisos de clave privada para el dispositivo o software específico. En todos los casos, la gMSA usada por HGS requiere permisos de lectura en las claves privadas del certificado de cifrado, firma y comunicaciones para que pueda realizar operaciones de firma y cifrado.

Algunos módulos de seguridad de hardware no admiten la concesión de acceso a cuentas de usuario específicas a una clave privada; en su lugar, permiten que la cuenta de equipo acceda a todas las claves de un conjunto de claves específico. Para estos dispositivos, normalmente es suficiente con conceder al equipo acceso a las claves y HGS podrá aprovechar esa conexión.

Sugerencias para HSM

A continuación se muestran opciones de configuración sugeridas para ayudarle a usar correctamente las claves basadas en HSM con HGS en función de las experiencias de Microsoft y sus asociados. Estas sugerencias se proporcionan para su comodidad y no se garantiza que sean correctas en el momento de la lectura, ni están aprobadas por los fabricantes de HSM. Si tiene más preguntas, póngase en contacto con el fabricante de HSM para obtener información precisa relativa a su dispositivo específico.

HSM Brand/Series Sugerencia
Gemalto SafeNet Asegúrese de que la propiedad Uso de clave del archivo de solicitud de certificado está establecida en 0xa0, lo que permite que el certificado se utilice para la firma y el cifrado. Además, debe conceder a la cuenta de gMSA acceso de lectura a la clave privada mediante la herramienta de administrador de certificados local (consulte los pasos anteriores).
nCipher nShield Asegúrese de que cada nodo de HGS tiene acceso al mundo de seguridad que contiene las claves de firma y cifrado. Es posible que tenga que conceder a la gMSA acceso de lectura a la clave privada mediante el administrador de certificados local (consulte los pasos anteriores).
Utimaco CryptoServers Asegúrese de que la propiedad Uso de clave del archivo de solicitud de certificado está establecida en 0x13, lo que permite que el certificado se utilice para el cifrado, descifrado y firma.

Solicitudes de certificado

Si usa una entidad de certificación para emitir los certificados en un entorno de infraestructura de clave pública (PKI), deberá asegurarse de que la solicitud de certificado incluye los requisitos mínimos para el uso de esas claves por parte de HGS.

Firma de certificados

Propiedad CSR Valor requerido
Algoritmo RSA
Tamaño de clave Al menos 2048 bits
Uso de claves Signature/Sign/DigitalSignature

Certificados de cifrado

Propiedad CSR Valor requerido
Algoritmo RSA
Tamaño de clave Al menos 2048 bits
Uso de claves Cifrado/Cifrado/Cifrado de datosEncipherment

Servicios de certificados de Active Directory plantillas

Si usa plantillas de Servicios de certificados de Active Directory (ADCS) para crear los certificados, se recomienda usar una plantilla con la siguiente configuración:

Propiedad de plantilla de ADCS Valor requerido
Categoría del proveedor Proveedor de almacenamiento de claves
Nombre del algoritmo RSA
Tamaño mínimo de clave 2048
Finalidad Firma y cifrado
Extensión de uso de claves Firma digital, cifrado de claves, cifrado de datos ("Permitir cifrado de datos de usuario")

Desviación de tiempo

Si el tiempo del servidor se ha desviado significativamente del de otros nodos HGS o hosts de Hyper-V en el tejido de protección, puede encontrar problemas con la validez del certificado de firmante de atestación. El certificado de firmante de atestación se crea y renueva en segundo plano en HGS y se usa para firmar los certificados de mantenimiento emitidos a los hosts resguardados por el servicio de atestación.

Para actualizar el certificado de firmante de atestación, ejecute el siguiente comando en un símbolo del sistema de PowerShell con privilegios elevados.

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

Como alternativa, puede ejecutar manualmente la tarea programada abriendo Programador de tareas (taskschd.msc), navegando a Programador de tareas Library Microsoft Windows > HGSServer y ejecutando la tarea denominada >.

Cambiar los modos de atestación

Si cambia HGS del modo TPM al modo Active Directory o viceversa mediante el cmdlet Set-HgsServer, cada nodo del clúster de HGS puede tardar hasta 10 minutos en empezar a aplicar el nuevo modo de atestación. Este es el comportamiento normal. Se recomienda no quitar ninguna directivas que permitan hosts del modo de atestación anterior hasta que haya comprobado que todos los hosts están atestiguando correctamente mediante el nuevo modo de atestación.

Problema conocido al cambiar del modo TPM al modo ad

Si ha inicializado el clúster de HGS en modo TPM y posteriormente cambia al modo Active Directory, hay un problema conocido que impide que otros nodos del clúster de HGS cambien al nuevo modo de atestación. Para asegurarse de que todos los servidores HGS están aplicando el modo de atestación correcto, ejecute Set-HgsServer -TrustActiveDirectorySet-HgsServer -TrustActiveDirectory del clúster de HGS. Este problema no se aplica si va a cambiar del modo TPM al modo ad y el clúster se ha configurado originalmente en modo ad.

Puede comprobar el modo de atestación del servidor HGS ejecutando Get-HgsServer.

Directivas de cifrado de volcado de memoria

Si intenta configurar directivas de cifrado de volcado de memoria y no ve las directivas de volcado de memoria predeterminadas (Hgs_NoDumps, Hgs_DumpEncryption y Hgs_DumpEncryptionKey) ni el cmdlet de directiva de volcado de memoria (Add-HgsAttestationDumpPolicy), es probable que no tenga instalada la actualización acumulativa más reciente. Para solucionar este problema, actualice el servidor HGS a la última actualización acumulativa Windows y active las nuevas directivas de atestación. Asegúrese de actualizar los hosts de Hyper-V a la misma actualización acumulativa antes de activar las nuevas directivas de atestación, ya que los hosts que no tienen instaladas las nuevas funcionalidades de cifrado de volcado de memoria probablemente producirán un error de atestación una vez activada la directiva HGS.

Mensajes de error de certificado de clave de aprobación

Al registrar un host mediante el cmdlet Add-HgsAttestationTpmHost, se extraen dos identificadores de TPM del archivo de identificador de plataforma proporcionado: el certificado de clave de aprobación (EKcert) y la clave de aprobación pública (EKpub). El EKcert identifica al fabricante del TPM, lo que proporciona garantías de que el TPM es auténtico y se fabrica a través de la cadena de suministro normal. EKpub identifica de forma única ese TPM específico y es una de las medidas que HGS usa para conceder a un host acceso para ejecutar máquinas virtuales blindadas.

Recibirá un error al registrar un host de TPM si se cumple alguna de las dos condiciones:

  1. El archivo de identificador de plataforma no contiene un certificado de clave de aprobación
  2. El archivo de identificador de plataforma contiene un certificado de clave de aprobación, pero ese certificado no es de confianza en el sistema.

Algunos fabricantes de TPM no incluyen EKcerts en sus TPM. Si sospecha que este es el caso del TPM, confirme con el OEM que los TPM no deben tener un EKcert y use la marca para registrar manualmente el host con -Force HGS. Si el TPM debe tener un EKcert pero no se encontró uno en el archivo de identificador de plataforma, asegúrese de que usa una consola de PowerShell de administrador (con privilegios elevados) al ejecutar Get-PlatformIdentifier en el host.

Si recibe el error de que su EKcert no es de confianza, asegúrese de que ha instalado el paquete de certificados raíz de TPM de confianza en cada servidor HGS y de que el certificado raíz del proveedor de TPM está presente en el almacén de TrustedTPM_RootCA del equipo local. Los certificados intermedios aplicables también deben instalarse en el almacén TrustedTPM_IntermediateCA en el equipo local. Después de instalar los certificados raíz e intermedio, debería poder Add-HgsAttestationTpmHost ejecutarse correctamente.

Privilegios de cuenta de servicio administrada de grupo (gMSA)

La cuenta de servicio HGS (gMSA usada para el grupo de aplicaciones de Key Protection Service en IIS) debe tener el privilegio Generar auditorías de seguridad, también conocida como . Si falta este privilegio, la configuración inicial de HGS se realiza correctamente e IIS se inicia; sin embargo, el servicio de protección de claves no es funcional y devuelve el error HTTP 500 ( Error de servidor en la aplicación /KeyProtection ” ). También puede observar los siguientes mensajes de advertencia en el registro de eventos de la aplicación.

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)

o

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)

Además, puede observar que ninguno de los cmdlets de Key Protection Service (por ejemplo, Get-HgsKeyProtectionCertificate)funcionan y, en su lugar, devuelven errores.

Para resolver este problema, debe conceder a gMSA la opción Generar auditorías de “ seguridad ” (SeAuditPrivilege). Para ello, puede usar la directiva de seguridad local SecPol.msc en todos los nodos del clúster de HGS o directiva de grupo. Como alternativa, puede usarSecEdit.exeherramienta para exportar la directiva de seguridad actual, realizar las modificaciones necesarias en el archivo de configuración (que es un texto sin formato) y, a continuación, volver a importarla.

Nota

Al configurar esta opción, la lista de principios de seguridad definidos para un privilegio invalida totalmente los valores predeterminados (no concatena). Por lo tanto, al definir esta configuración de directiva, asegúrese de incluir los dos titulares predeterminados de este privilegio (servicio de red y servicio local) además de la gMSA que va a agregar.