Compartir vía

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

  • Artículo

En este artículo se describen las soluciones a problemas comunes que se producen al implementar o operar un servidor del Servicio de protección de host (HGS) en un tejido protegido.

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

Si no está seguro de la naturaleza del problema, pruebe primero a ejecutar los diagnósticos de tejido protegido en los servidores HGS y los hosts de Hyper-V para reducir 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 están configurados incorrectamente, HGS no puede atender solicitudes de hosts de Hyper-V que deseen atestiguar o desbloquear protectores de clave para máquinas virtuales blindadas. En las secciones siguientes se tratan 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 usada por 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 respaldadas por software

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

  1. Abra el administrador de certificados local (certlm.msc).
  2. ExpandaCertificadospersonales> 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 gMSA para HGS que se encontró anteriormente y, a continuación, seleccione Aceptar.
  6. Asegúrese de que 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, debe descargar el módulo de PowerShell de 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 de Guarded Fabric Tools y conceder a la cuenta de 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 respaldadas por el proveedor

Si las claves privadas del certificado están respaldadas por un módulo de seguridad de hardware (HSM) o un proveedor de almacenamiento de claves personalizado (KSP), el modelo de permisos depende 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 controlan 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 una clave privada a cuentas de usuario específicas; 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 proporcionar al equipo acceso a las claves y HGS es capaz de aprovechar esa conexión.

Sugerencias para HSM

A continuación se indican las opciones de configuración sugeridas para ayudarle a usar correctamente las claves respaldadas por 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. Póngase en contacto con el fabricante de HSM para obtener información precisa sobre su dispositivo específico si tiene más preguntas.

HSM Brand/Series Sugerencia
Gemalto SafeNet Asegúrese de que la propiedad De uso de clave del archivo de solicitud de certificado está establecida en 0xa0, lo que permite que el certificado se use 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 administrador de certificados local (consulte los pasos anteriores).
nCipher nShield Asegúrese de que cada nodo de HGS tiene acceso al mundo de la seguridad que contiene las claves de firma y cifrado. Además, 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 De uso de clave del archivo de solicitud de certificado está establecida en 0x13, lo que permite que el certificado se use 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), debe asegurarse de que la solicitud de certificado incluya los requisitos mínimos para el uso de esas claves por parte de HGS.

Certificados de firma

Csr (propiedad) Valor necesario
Algoritmo RSA
Tamaño de la clave Al menos 2048 bits
Uso de la clave Firma/Firma/DigitalSignature

Certificados de cifrado

Csr (propiedad) Valor necesario
Algoritmo RSA
Tamaño de la clave Al menos 2048 bits
Uso de la clave Cifrado, cifrado y cifrado de datosEncipherment

Plantillas de Servicios de certificados de Active Directory

Si usa plantillas de certificado 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 ADCS Valor necesario
Categoría de proveedor Proveedor de almacenamiento de claves
Nombre del algoritmo RSA
Tamaño mínimo de clave 2048
Objetivo Firma y cifrado
Extensión de uso de claves Firma digital, cifrado de claves, cifrado de datos ("Permitir cifrado de datos de usuario")

Desfase de tiempo

Si el tiempo del servidor se ha desviado significativamente del de otros nodos de HGS o hosts de Hyper-V en el tejido protegido, 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 certificados de estado emitidos a hosts protegidos 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 el Programador de tareas (taskschd.msc), navegando a biblioteca> del programador de tareasMicrosoft>Windows>HGSServer y ejecutando la tarea denominada AttestationSignerCertRenewalTask.

Cambio de los modos de atestación

Si cambia HGS del modo TPM al modo de 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 un comportamiento normal.

Se recomienda no quitar ninguna directiva que permita hosts del modo de atestación anterior hasta que haya comprobado que todos los hosts atestiguan correctamente el nuevo modo de atestación.

Problema conocido al cambiar del modo TPM a AD

Si ha inicializado el clúster de HGS en modo TPM y, posteriormente, cambia al modo de 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 -TrustActiveDirectory en cada nodo del clúster de HGS.

Este problema no se aplica si cambia del modo TPM al modo AD y el clúster se configuró originalmente en modo AD.

Para comprobar el modo de atestación del servidor HGS, ejecute Get-HgsServer.

Directivas de cifrado de volcado de memoria

Si está intentando configurar directivas de cifrado de volcado de memoria y no ve las directivas de volcado de HGS predeterminadas (Hgs_NoDumps, Hgs_DumpEncryption y Hgs_DumpEncryptionKey) ni el cmdlet de directiva de volcado (Add-HgsAttestationDumpPolicy), es probable que no tenga instalada la actualización acumulativa más reciente.

Para corregir esto, actualice el servidor HGS a la actualización acumulativa más reciente de 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 probablemente producirán un error de atestación una vez que se active la directiva de 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). 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:

  • El archivo de identificador de plataforma no contiene un certificado de clave de aprobación.
  • 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 TPMs.

Si sospecha que este es el caso con el TPM, confirme con el OEM que los TPMs no deben tener un EKcert y use la -Force marca para registrar manualmente el host con 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 ha recibido 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 "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 ejecutarse Add-HgsAttestationTpmHost correctamente.

Privilegios de cuenta de servicio administrada de grupo (gMSA)

A la cuenta de servicio de HGS (gMSA que se usa para el grupo de aplicaciones de Key Protection Service en IIS) se le debe conceder el privilegio Generar auditorías de seguridad , también conocido como SeAuditPrivilege. Si falta este privilegio, la configuración inicial de HGS se realiza correctamente y IIS se inicia, pero el servicio de protección de claves no es funcional y devuelve el error HTTP 500 ("Error del 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) funciona y, en su lugar, devuelve 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 cada nodo del clúster de HGS o directiva de grupo. Como alternativa, podría usar SecEdit.exe herramienta 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 configuración, la lista de principios de seguridad definidos para un privilegio invalida completamente los valores predeterminados (no se concatena). Por lo tanto, al definir esta configuración de directiva, asegúrese de incluir ambos titulares predeterminados de este privilegio (servicio de red y servicio local) además de la gMSA que va a agregar.