Fallo de autenticación Kerberos con una confianza externa entre dominios y NTLM deshabilitado (diagnóstico de SID-History)
Al migrar usuarios de Active Directory con SID-History, es posible que se autentiquen correctamente, pero no puedan acceder a recursos situados en el dominio de origen de confianza.
En nuestro laboratorio, la autenticación Kerberos parecía funcionar a primera vista. Se podían obtener tickets Kerberos entre realms, la confianza externa entre dominios estaba en buen estado y el filtrado de SID se había deshabilitado. Sin embargo, Windows no conseguía el ticket de servicio Kerberos necesario para el servidor de archivos de destino. Por ello, recurría a NTLM. Como NTLM estaba deshabilitado, el acceso fallaba.
Este artículo explica cómo identificar esta situación y una posible solución.
Síntomas
Un usuario migrado se autentica correctamente en el dominio de destino.
El usuario también tiene el atributo SID-History esperado, y el token de acceso contiene los valores esperados de SID-History después del inicio de sesión.
Sin embargo, falla el acceso a un recurso situado en el dominio de origen de confianza.
Por ejemplo:
dir \\dc01.source.com\shtest
Si NTLM está deshabilitado, Windows muestra un error similar a:
Authentication failed because NTLM authentication has been disabled.
Si NTLM está habilitado, Windows muestra un error similar a:
The system cannot contact a domain controller to service the authentication request. Please try again later.
Entorno
El problema se observó en un laboratorio con:
- Dos bosques independientes de Active Directory.
- Un dominio por bosque.
- Una confianza externa bidireccional entre dominios.
- El filtrado de SID (cuarentena) deshabilitado.
- SID-History migrado correctamente.
- NTLM deshabilitado.
- Autenticación Kerberos.
Al sustituir la confianza externa entre dominios por una confianza entre bosques, el problema de autenticación desapareció inmediatamente sin más configuración.
Investigación inicial
La primera hipótesis fue que SID-History no funcionaba correctamente.
Sin embargo, todas estas comprobaciones dieron resultado:
- El atributo SID-History contenía los valores esperados.
- SID-History aparecía en el token de inicio de sesión del usuario (
whoami /groups). - La confianza estaba en buen estado.
- El filtrado de SID estaba deshabilitado.
- Se había obtenido un ticket Kerberos entre realms.
Por ejemplo, el comando siguiente terminó correctamente:
klist get krbtgt/SOURCE.COM
El fallo solo se producía al solicitar el ticket de servicio Kerberos:
klist get cifs/dc01.source.com
Este comando devolvía:
Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x6fb
klist failed with 0xc000018b
Al no obtener un ticket de servicio Kerberos, Windows intentaba usar NTLM. Como NTLM estaba deshabilitado, el acceso fallaba.
Causa
Durante el diagnóstico observamos que, con la confianza externa entre dominios, Kerberos no lograba asociar el nombre de entidad de seguridad de servicio (SPN) solicitado:
cifs/dc01.source.com
con el realm Kerberos correspondiente.
Aunque la confianza funcionaba y los tickets Kerberos entre realms se obtenían correctamente, Windows no conseguía el ticket de servicio final para el servicio solicitado.
Solución
Al añadir una asignación explícita de host a realm, el problema se resolvió inmediatamente.
Por ejemplo:
ksetup /addhosttorealmmap dc01.source.com SOURCE.COM
Después de purgar los tickets Kerberos existentes:
klist purge
la solicitud del ticket de servicio se completó correctamente:
klist get cifs/dc01.source.com
El acceso SMB funcionó entonces mediante Kerberos sin recurrir a NTLM.
Cómo comprobar las asignaciones de host a realm
Las asignaciones de host a realm se almacenan localmente en el equipo.
Pueden comprobarse en el Registro:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm
Por ejemplo:
SOURCE.COM
SpnMappings = dc01.source.com
Aunque ksetup permite crear y quitar estas asignaciones, es posible que el propio comando no muestre siempre las asignaciones existentes. Por ello, recomendamos comprobar el Registro.
Para eliminar una asignación:
ksetup /delhosttorealmmap dc01.source.com SOURCE.COM
También puede asignar un sufijo DNS para abarcar varios servidores:
ksetup /addhosttorealmmap .source.com SOURCE.COM
Utilice una asignación para todo el sufijo únicamente si el espacio de nombres DNS completo pertenece al realm Kerberos indicado. Una asignación incorrecta o demasiado amplia puede dirigir las solicitudes Kerberos al realm equivocado.
Implementación de la asignación mediante directiva de grupo
Si tiene varios clientes o servidores, implemente la asignación de forma centralizada mediante esta ruta de directiva:
Computer Configuration
Administrative Templates
System
Kerberos
Define host name-to-Kerberos realm mappings
Pasos de diagnóstico
Si Kerberos recurre a NTLM a través de una confianza externa entre dominios, estas comprobaciones pueden ayudar a encontrar el problema:
- Compruebe que SID-History se haya migrado correctamente.
- Confirme que el filtrado de SID esté deshabilitado para la confianza externa entre dominios.
- Compruebe que puede obtener un ticket Kerberos entre realms:
klist get krbtgt/SOURCE.COM
- Solicite el ticket de servicio Kerberos:
klist get cifs/dc01.source.com
- Si el ticket entre realms se obtiene, pero la solicitud del ticket de servicio falla con
0xC000018B, pruebe una asignación explícita de host a realm mediante ksetup.
Confianza entre bosques frente a confianza externa entre dominios
En nuestras pruebas, el mismo escenario de autenticación funcionó inmediatamente después de sustituir la confianza externa entre dominios por una confianza entre bosques.
Las confianzas entre bosques proporcionan un enrutamiento automático de sufijos de nombre entre bosques, mientras que las confianzas externas entre dominios utilizan mecanismos Kerberos diferentes.
En el entorno investigado, la asignación explícita del host de destino al realm Kerberos correspondiente resolvió el problema de obtención del ticket de servicio con una confianza externa entre dominios.
Resumen
Si los usuarios migrados con SID-History se autentican, pero el acceso a recursos falla porque Windows recurre a NTLM, es posible que el problema no sea SID-History.
Compruebe si Kerberos puede obtener el ticket de servicio necesario. Si:
klist get krbtgt/SOURCE.COM
funciona, pero:
klist get cifs/server.source.com
falla con 0xC000018B, una asignación explícita de host a realm puede resolverlo:
ksetup /addhosttorealmmap server.source.com SOURCE.COM
Este procedimiento resolvió el problema en nuestro laboratorio con una confianza externa de Active Directory y permitió seguir usando Kerberos sin recurrir a NTLM.
Si está diagnosticando problemas de Kerberos, SID-History o confianza durante una migración, Sys-Manage CopyRight2 puede ayudarle a migrar Active Directory con SID-History, incluidos los casos entre dominios o bosques en los que es preciso validar cuidadosamente la autenticación.
Para trasladar estaciones de trabajo y entornos de usuario, consulte también la migración de equipos y perfiles de usuario.