Visión general
Tuvimos este problema en algunos servidores virtuales migrados de un proveedor "en la nube" a nuestro centro de datos interno. La causa raíz fueron los permisos a la %SystemRoot%\System32\catroot2
carpeta. Hubo una serie de diferencias entre los permisos en esa carpeta en un servidor en buen estado frente a los del servidor migrado. Creo que la clave fue que TrustedInstaller
no tenía full access
.
Síntomas adicionales
Al observar el registro de la aplicación en el visor de eventos, vimos una serie de errores:
Source: CAPI2
EventId: 257
Text: The Cryptographic Services service failed to initialize the Catalog Database. The ESENT error was: -1032.
Source: ESENT
EventId: 490
Text: Catalog Database (416) Catalog Database: An attempt to open the file "C:\Windows\system32\CatRoot2\{127D0A1D-4EF2-11D1-8608-00C04FC295EE}\catdb" for read / write access failed with system error 5 (0x00000005): "Access is denied. ". The open file operation will fail with error -1032 (0xfffffbf8).
La pista está en el texto del error ESENT; es decir, problema de permisos al acceder a un archivo en la carpeta catroot2.
Resolución
Dele a la cuenta de Trusted Installer control total sobre la carpeta catroot2 y sus elementos secundarios.
En caso de que eso no sea suficiente, en comparación, la ejecución icacls %systemroot%\system32\catroot2
en un servidor en buen estado da esto:
C:\Windows\system32\catroot2 NT SERVICE\CryptSvc:(F)
NT SERVICE\CryptSvc:(OI)(CI)(IO)(F)
NT SERVICE\TrustedInstaller:(I)(F)
NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
BUILTIN\Users:(I)(RX)
BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)
NB: para agregar Trusted Installer, deberá buscar en las cuentas de computadoras locales nt service\trustedinstaller
.
Después de reemplazar los permisos catroot2
, asegúrese de hacer clic en la replace permissions on child objects & containers
casilla de verificación para asegurarse de que los elementos secundarios también tengan sus permisos resueltos.
No se requiere reiniciar para la corrección en sí (aunque, obviamente, una vez que las actualizaciones comiencen a funcionar nuevamente, es probable que deba reiniciarlas).