Cuando nuestras cuentas gMSA se rotan automáticamente, vemos errores de inicio de sesión durante aproximadamente 1 a 10 minutos. Esto es particularmente evidente para las cuentas de clientes de gMSA que se conectan al servidor MS SQL, pero creo que también ocurre con otras cuentas de gMSA. El servidor MS SQL no se ejecuta como una cuenta gMSA, pero nuestra aplicación utiliza gMSA para establecer una conexión de cliente a SQL. De forma predeterminada, ManagedPasswordIntervalInDays es cada 30 días, por lo que vemos esto todos los meses al mismo tiempo.
Cuando reviso los registros del controlador de dominio, no veo ningún error de inicio de sesión para el usuario gMSA, pero el servidor SQL registra el siguiente error
El protocolo de enlace SSPI falló con el código de error 0x8009030c, estado 14 al establecer una conexión con seguridad integrada; la conexión se ha cerrado. Motivo: Error en AcceptSecurityContext. El código de error del sistema operativo indica la causa del fallo. El intento de inicio de sesión falló [CLIENTE: xxxx]
Por lo que he encontrado, este error generalmente indica una combinación incorrecta de nombre de usuario y contraseña.
Esto ocurre en varios clientes y, eventualmente, cada uno comienza a conectarse nuevamente después de entre 1 y 10 minutos. No todos los clientes comienzan a conectarse al mismo tiempo, pero parece ser aleatorio dentro de esa ventana de tiempo.
Inicialmente pensé que podría estar relacionado con la replicación AD de la contraseña cambiada, por lo que modificamos el intervalo de replicación entre sitios predeterminado a USE_NOTIFY para replicar inmediatamente. Si el problema fuera la replicación, esperaría ver fallas de inicio de sesión en los DC y no veo fallas de inicio de sesión en los DC. También pensé que tal vez el servidor SQL esté almacenando en caché el token de autenticación, pero si ese fuera el caso, esperaría ver que todos los clientes se resolvieran al mismo tiempo (es decir, cuando el servidor SQL se actualizara), ya que cada cliente comienza a trabajar nuevamente. en otro momento, no parece estar en el lado del servidor SQL, sino más bien en el lado del cliente. Tal vez almacenar en caché la contraseña de gMSA o tal vez algo relacionado con el tiempo de espera y los reintentos.
Respuesta1
Estábamos generando el mismo error debido a un problema de SPN que provocó que gMSA se autenticara en el servidor SQL a través de NTLM en lugar de Kerberos. Si inicia sesión en el servidor SQL y verifica las sesiones, sys.dm_exec_connectionsdebería ver una lista de sesiones con NTLM
(también puedes usar klist sessionsdesde el cli para ver las sesiones)
Pudimos correlacionar nuestros errores con los cambios de contraseña con herramientas de análisis de registros, por lo que supimos que ese era el culpable. No sé con qué frecuencia SCM actualiza su copia de la contraseña, pero si el servicio se autentica en el servidor SQL y usa Kerberos, creo que los cambios de contraseña deben ser independientes de la duración/renovación de la sesión de Kerberos, por lo que el error generado es una pista sólida de que la contraseña se envía al host del servidor SQL a través de NTLM. Una vez que solucionamos nuestro problema de SPN (que se debió a un registro DNS A adicional), las sesiones cambiaron a la autenticación Kerberos.
Respuesta2
Descubrí que esto se debía a la forma en que estaba configurado el servicio de Windows. El servicio de Windows se configuró como un servicio estándar usando una cuenta de usuario normal que resultó ser una cuenta gMSA en lugar del servicio de Windows usando una cuenta administrada.
Esto se puede verificar con:
>sc.exe qmanagedaccount ServiceName
[SC] QueryServiceConfig2 SUCCESS
ACCOUNT MANAGED : FALSE
Esto se puede cambiar ejecutando
sc.exe managedaccount ServiceName TRUE
Después de cambiar el tipo de cuenta de servicio de Windows que se administrará, las pruebas iniciales muestran que los inicios de sesión ahora se realizan correctamente durante la rotación de contraseñas de gMSA.