Esto esloco, así que por favor tengan paciencia conmigo. Esta NO es una contraseña incorrecta.
Tengo una cuenta de servicio SQL que NO se autentica. Soy un servidor experimentado y he probado todos los conceptos básicos con un par de colegas expertos (incluso si están orientados a Cisco).
Guión:
- Active Directory en 3 sitios cada uno con 2 DC y 1 DC raíz en Server 2008 R2
- No hay problemas de DNS y la replicación del sitio es perfecta. Cualquier cambio de cuenta ocurre en segundos.
- SQL 2016 R2 recién creado implementado en 2 servidores Server 2012 R2 en el dominio que reside en una unidad organizativa en la que también reside SQL 2005 en Server 2008 R2.
- TODOS los servidores SQL están en su propia VLAN, los DC en otra. No hay problemas de firewall entre ellos, aunque no podemos ver ningún registro ya que están alojados por terceros en clústeres ESX con contratos de Cisco entre VLAN.
- El servidor SQL 2005 no tiene problemas para autenticarse con los DC en la otra VLAN.
La configuración de una cuenta de servicio AD SQL establecida en los nuevos servidores SQL falla debido al error 1069: el servicio no se inició debido a un error de inicio de sesión.
El evento en los registros de eventos en los DC (cualquiera de los 2 que autentique la cuenta) indica lo siguiente:
La autenticación previa de Kerberos falló. Información de cuenta: ID de seguridad: DOMINIO\sqlsvcaccount$ Nombre de cuenta: sqlsvcaccount$ (no es el nombre real de la cuenta) Información de servicio: Nombre del servicio: krbtgt/DOMAIN (no es nuestro nombre de dominio, por supuesto) Información de red: Dirección del cliente: ::ffff:10.30 .xx (nuestra dirección IPv4) Puerto del cliente: 49464 Información adicional: Opciones de ticket: 0x40810010 Código de falla: 0x18 Tipo de autenticación previa: 2
Información del certificado: Nombre del emisor del certificado:
Número de serie del certificado:
Huella digital del certificado:
Ahora, 0x18 normalmente es una contraseña incorrecta, pero como se mencionó, las cuentas están bien y cuando se desactivan las vuelvo a habilitar, restablezco la contraseña yadda yadda. Puedo hacer RunAs en una aplicación en el nuevo servidor SQL y funciona bien.
Establecí una política de grupo de computadoras para permitir derechos de cuenta de servicio para servicios, etc. y ejecuté un gpresult para confirmar que se aplicó el GPO.
Realizar una copia de seguridad de archivos y directorios DOMINIO\sqlsvcaccount$ Iniciar sesión como un trabajo por lotes DOMINIO\sqlsvcaccount$ Iniciar sesión como un servicio DOMINIO\sqlsvcaccount$
Incluso tenía un GPO de computadora restringido y puse la cuenta de dominio como administrador local (lo que habría negado la necesidad del GPO de servicios).
Creé una nueva unidad organizativa de usuario para la cuenta de servicio con la herencia bloqueada y moví la cuenta de servicio allí, nuevamente gpupdate /force y ejecuté gpresult nuevamente en html y todo se ve bien.
También reiniciar varias veces entre cosas, lo habitual.
Ejecutamos Wireshark, que nunca mostró nada incorrecto, movimos el servidor SQL a la misma VLAN que el DC y, como se mencionó anteriormente, el servidor SQL 2005 en DB VLAN no tiene problemas de autenticación.
Finalmente, creé una nueva unidad organizativa de computadora, bloqueé la herencia de políticas e intenté todo esto nuevamente, pero todavía no me gustó intentar iniciar SQL Server o el servicio del Agente.
Probé la herramienta de administración de SQL para editar servicios como debería ser e incluso solo Windows Services.msc.
Lo último que empezamos a mirar fueron los cifrados y si el servidor 2012 está intentando autenticarse usando RC4 y deshabilitando los cifrados. Pero todavía no he hecho demasiado con esto.
Muuuuuuuuuy ¿Alguien tiene alguna idea de lo que podría estar pasando? Agradezco CUALQUIER comentario u otra vía que pueda probar.
¿Hay una caja virtual de cerveza para cualquiera que tenga la respuesta?
Respuesta1
Cuentas de servicio administradas(MSA) resolvió esto. Server 2012 AD usa gMSA, así que eso me desconcertó:
En AD (con opciones avanzadas) en Novacroft hay una unidad organizativa llamada Cuentas de servicio administradas. Encontrará sus MSA creados allí una vez creados con Powershell.
Entonces, para instalar una cuenta de servicio:
- Creas la cuenta (sin $) usando Powershell.
- Luego asocie la cuenta a un servidor, nuevamente usando Powershell.
- En el servidor de destino, instale Powershell y el módulo AD en funciones y herramientas AD. Instale también .NET 3.5
- En el servidor de destino dentro de Powershell, importe la cuenta al host.
- Luego configure los servicios (ahora necesita agregar $ al final) y deje la contraseña en blanco.
Bonito y fácil, ¿eh (si sabes cómo)? Crédito a NedPyle [MSFT] Artículo completoAQUÍ Espero que esto ayude a alguien :-)