El controlador de dominio degradado aún autentica usuarios

10

¿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

  1. server1 (Windows Server 2008): DC degradado recientemente, servidor de archivos
  2. server3 (Windows Server 2008 R2): nuevo DC
  3. 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

  1. 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 .
  2. Verificación de entradas DNS con nslookup. nslookup -type=srv _kerberos._udp.mydomain.localdevuelve entradas para server3 y server4, nada sobre server1 .
  3. Limpieza de metadatos. Después de usar ntdsutilpara limpiar los metadatos como se describe en este artículo de TechNet , el ntdsutilcomando list servers in sitedevuelve solo dos entradas, que se ven bien:
    1. 0 - CN = SERVIDOR 4, CN = Servidores, CN = Predeterminado-Primer sitio, CN = Sitios, CN = Configuración, DC = midominio, DC = local
    2. 1 - CN = SERVER3, CN = Servidores, CN = Default-First-Site, CN = Sitios, CN = Configuración, DC = midominio, DC = local
  4. 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 .
  5. 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.
  6. Volver a registrarse con DNS y reiniciar netlogon . Una publicación en el foro sugirió ejecutar ipconfig /registerdnsy net stop netlogon && net start netlogonen los nuevos servidores para resolver un problema relacionado. No pareció ayudar.
  7. 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?

Eric Eskildsen
fuente

Respuestas:

12

Es un servidor de archivos: ¿los usuarios se conectan para acceder a los archivos? Eso es probablemente lo que estás viendo. Esos aparecerían en los registros de seguridad.

Publique algunas entradas de registro (en su totalidad: volcado de texto o captura de pantalla) del servidor1 que muestre el comportamiento que le preocupa.

/ Editar - Gracias por confirmar. Inicio de sesión tipo 3 es "Red". Se ve con mayor frecuencia al acceder a archivos o impresoras compartidos en la computadora que registró el evento.

mfinni
fuente
Gracias: cargué capturas de pantalla de los registros de seguridad de los servidores para realizar una edición. Aparentemente, no tengo suficiente reputación para cargar imágenes, por lo que el enlace está escrito en texto.
Eric Eskildsen
Lo extraño para mí es que solo server1 registra algo sobre los inicios de sesión y los cierres de sesión. Estoy de acuerdo en que deberían aparecer en un servidor de archivos, pero ¿los DC no los registran cuando los usuarios están autenticados?
Eric Eskildsen
1
Registre las entradas en su totalidad, por favor. Muestre el evento de registro real con todo el texto, no una lista de todas las entradas de registro, del servidor1.
mfinni
3
Comentario rápido para cualquier lector con el problema de los nuevos DC que no registran eventos de auditoría: Resulta que los archivos corruptos audit.csv anulaban la configuración de auditoría de la Política de grupo como se describe aquí . Después de eliminar los archivos CSV y ejecutar auditpol /cleary gpupdate /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!
Eric Eskildsen
1
Suena bien, me alegra que lo hayas entendido Definitivamente querrá pasar un tiempo leyendo sobre el cuidado y la alimentación de los controladores de dominio, las mejores prácticas, etc. MS también tiene muchos buenos artículos y capacitación disponibles.
mfinni
2

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.

línea fuerte
fuente
1
Exactamente correcto: resultó que el DC degradado estaba registrando la autenticación solo para archivos compartidos. Lo que me confundió fue que los nuevos DC no registraban eventos de autenticación en absoluto . El problema terminó siendo que los archivos audit.csv en los nuevos controladores de dominio estaban corruptos, pero siguiendo las instrucciones sobre cómo eliminar esos archivos en estas publicaciones de TechNet resolvió eso.
Eric Eskildsen