¿Por qué un controlador de dominio degradado sigue autenticando a los usuarios?
Cada vez que los usuarios inician sesión en estaciones de trabajo con cuentas de dominio, este DC degradado los autentica. Su registro de seguridad muestra sus inicios de sesión, cierres de sesión e inicios de sesión especiales. Los registros de seguridad de nuestros nuevos DC muestran algunos inicios y cierres de sesión de máquinas, pero nada que ver con los usuarios del dominio.
Antecedentes
- server1 (Windows Server 2008): DC degradado recientemente, servidor de archivos
- server3 (Windows Server 2008 R2): nuevo DC
- server4 (Windows Server 2008 R2): nuevo DC
Registros
Eventos de registro de seguridad: http://imgur.com/a/6cklL .
Dos eventos de muestra del servidor1 :
Audit Success,3/31/2014 11:06:14 AM,Microsoft-Windows-Security-Auditing,4624,Logon,"An account was successfully logged on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
New Logon:
Security ID: MYDOMAIN\auser
Account Name: auser
Account Domain: MYDOMAIN
Logon ID: 0x8b792ce
Logon GUID: {54063226-E9B7-D357-AD58-546793C9CA59}
Process Information:
Process ID: 0x0
Process Name: -
Network Information:
Workstation Name:
Source Network Address: 192.168.20.143
Source Port: 52834
Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
[ ... ]
Audit Success,3/31/2014 11:06:06 AM,Microsoft-Windows-Security-Auditing,4624,Logon,"An account was successfully logged on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
New Logon:
Security ID: MYDOMAIN\anotheruser
Account Name: anotheruser
Account Domain: MYDOMAIN
Logon ID: 0x8b74ea5
Logon GUID: {7E74986A-7A4D-B6E0-5D6F-D8CF78E8C718}
Process Information:
Process ID: 0x0
Process Name: -
Network Information:
Workstation Name:
Source Network Address: 192.168.20.203
Source Port: 53027
Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
Ejemplo de evento de cambio de política de auditoría del servidor3 (también hay eventos de cambio de política de auditoría en el registro con cambios marcados como "Éxito agregado"):
System audit policy was changed.
Subject:
Security ID: SYSTEM
Account Name: SERVER3$
Account Domain: MYDOMAIN
Logon ID: 0x3e7
Audit Policy Change:
Category: Account Logon
Subcategory: Kerberos Authentication Service
Subcategory GUID: {0cce9242-69ae-11d9-bed3-505054503030}
Changes: Success removed
Intento de soluciones
- Arreglando entradas DNS.
dcdiag /test:dnsal principio devolvió errores después de que el servidor1 fue degradado. Hubo entradas de servidor de nombres desactualizadas en nuestras zonas de búsqueda directa, por ejemplo. Terminé abriendo el Administrador de DNS y eliminando manualmente las entradas problemáticas, también asegurándome de que las entradas LDAP y Kerberos apuntaran a los nuevos servidores. Por ejemplo, __ldap.Default-First-Site .__ sites.dc .__ msdcs.mydomain.local_ apunta a server3.mydomain.local . - Verificación de entradas DNS con
nslookup.nslookup -type=srv _kerberos._udp.mydomain.localdevuelve entradas para server3 y server4, nada sobre server1 . - Limpieza de metadatos. Después de usar
ntdsutilpara limpiar los metadatos como se describe en este artículo de TechNet , elntdsutilcomandolist servers in sitedevuelve solo dos entradas, que se ven bien:- 0 - CN = SERVIDOR 4, CN = Servidores, CN = Predeterminado-Primer sitio, CN = Sitios, CN = Configuración, DC = midominio, DC = local
- 1 - CN = SERVER3, CN = Servidores, CN = Default-First-Site, CN = Sitios, CN = Configuración, DC = midominio, DC = local
- Eliminar el servidor1 de los sitios y servicios de Active Directory. Después de degradar el servidor1 , noté que permanecía en los Sitios y Servicios de Active Directory, aunque ya no figuraba como un catálogo global. Lo eliminé de acuerdo con las instrucciones de este artículo de Microsoft KB .
- Transferencia de roles maestros de operaciones al servidor 3 . Los roles de maestro de operaciones están un poco más allá de mi conocimiento, pero solía
ntdsutiltransferirlos todos al servidor3 esta mañana. No hubo errores, pero los reinicios y las pruebas mostraron que el servidor1 todavía estaba haciendo toda la autenticación. - Volver a registrarse con DNS y reiniciar netlogon . Una publicación en el foro sugirió ejecutar
ipconfig /registerdnsynet stop netlogon && net start netlogonen los nuevos servidores para resolver un problema relacionado. No pareció ayudar. - Asegurarse de que el GPO ganador en los nuevos controladores de dominio permita la auditoría de eventos de inicio de sesión y de inicio de sesión de cuenta.
Otros conductores
- El mismo problema se describe en esta serie de publicaciones en el foro . No hay resolución
- También se describe en esta pregunta en Experts Exchange . El comentario marcado como respuesta dice: "Si el [sic] ya no es un DC, entonces no hay forma de que pueda procesar ninguna solicitud de autenticación". Esa sería mi reacción, pero la ejecución
dcdiagen el servidor1 confirma que el servidor1 no se considera un DC. Sin embargo, sigue siendo el único servidor que autentica a todos.
¿Que está pasando aqui?
auditpol /clearygpupdate /forceen los nuevos DC, todo está funcionando. ¡Le debo a @mfinni por señalarme en la dirección de la configuración de auditoría de GPO cuando estaba en todo tipo de persecuciones de ganso salvaje en la resolución de problemas!Un DC degradado de ninguna manera continuará autenticando los inicios de sesión de dominio. Lo que está viendo son eventos locales de inicio de sesión. Cuando inicie sesión en un servidor miembro con credencial de dominio, verá los eventos de inicio de sesión localmente, además de los eventos de validación de credenciales correspondientes en DC.
Cuando inicia sesión en el servidor miembro con credencial local, aún ve eventos de inicio de sesión localmente, pero no verá ningún evento de validación de credenciales en DC.
fuente