Pregunta Controlador de dominio degradado sigue autentificando usuarios


¿Por qué un controlador de dominio degradado sigue autentificando 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 y inicios de sesión especiales. Los nuevos registros de seguridad de los DC muestran algunos inicios de sesión de máquinas y cierres de sesión, pero nada que ver con los usuarios del dominio.

Fondo

  1. servidor 1 (Windows Server 2008): DC recientemente degradado, servidor de archivos
  2. servidor3 (Windows Server 2008 R2): Nuevo DC
  3. servidor 4 (Windows Server 2008 R2): Nuevo DC

Troncos

Eventos de registro de seguridad: http://imgur.com/a/6cklL.

Dos eventos de muestra de servidor 1:

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

Muestra Cambio de la política de auditoría evento de servidor3 (también hay Cambio de la política de auditoría eventos en el registro con cambios marcados "É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

Soluciones intentadas

  1. Arreglando entradas de DNS.  dcdiag /test:dns al principio devolvió errores después de servidor 1 fue degradado. Hubo entradas de servidor de nombres obsoletas en nuestras zonas de búsqueda directa, por ejemplo. Terminé abriendo el Administrador de DNS y eliminando las entradas de problemas manualmente, también asegurándome de que las entradas de LDAP y Kerberos apuntaban a los nuevos servidores. Por ejemplo, __ldap.Default-First-Site .__ sites.dc .__ msdcs.mydomain.local_ apunta a server3.mydomain.local.
  2. Verificando entradas de DNS con nslookup.  nslookup -type=srv _kerberos._udp.mydomain.local devuelve entradas para servidor3 y servidor 4-nada acerca de servidor 1.
  3. Limpieza de metadatos. Después de usar ntdsutil para limpiar los metadatos como se describe en este artículo de TechNet, la ntdsutil mando list servers in site devuelve solo dos entradas, que se ven bien:
    1. 0 - CN = SERVIDOR4, CN = Servidores, CN = Primer sitio predeterminado, CN = Sitios, CN = Configuración, DC = mydomain, DC = local
    2. 1 - CN = SERVIDOR3, CN = Servidores, CN = Primer sitio predeterminado, CN = Sitios, CN = Configuración, DC = mydomain, DC = local
  4. Borrando servidor 1 de Sitios y Servicios de Active Directory. Despues de degradar servidor 1Noté que permanecía en los sitios y servicios de Active Directory, aunque ya no estaba listado como un catálogo global. Lo borré de acuerdo con las instrucciones de este artículo de Microsoft KB.
  5. Transfiriendo funciones de maestro de operaciones a servidor3. Los roles de maestro de operaciones están un poco más allá de mi conocimiento, pero los usé ntdsutil transferirlos todos a servidor3 esta mañana. No hubo errores, pero reinicios y pruebas mostraron que servidor 1 Todavía estaba haciendo toda la autenticación.
  6. Volver a registrarse con DNS y reiniciar netlogon. Una publicación en el foro sugirió correr ipconfig /registerdns y net stop netlogon && net start netlogon en los nuevos servidores para resolver un problema relacionado. No parecía ayudar.
  7. Asegurarse de que el GPO ganador en los nuevos controladores de dominio permita la auditoría para el inicio de sesión y los eventos de inicio de sesión de la cuenta.

Otras pistas

  • El mismo problema se describe en esta serie de mensajes del foro. No hay resolución.
  • También se describe en esta pregunta en el intercambio de expertos. El comentario marcado como respuesta dice: "Si su [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 corriendo. dcdiagen servidor 1 confirma que servidor 1 No se considera un DC. Sin embargo, sigue siendo el único servidor que autentica a todos.

¿Que está pasando aqui?


10
2018-03-31 14:24


origen




Respuestas:


Es un servidor de archivos. ¿Los usuarios se conectan a él para obtener acceso 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) desde server1 que muestra el comportamiento que le preocupa.

/ Editar - Gracias por confirmar. El tipo de inicio de sesión 3 es "Red". La mayoría de las veces se ve cuando se accede a archivos o impresoras compartidas en la computadora que registró el evento.


11
2018-03-31 14:32



Gracias: cargué capturas de pantalla de los registros de seguridad de los servidores para imgur en una edición. Aparentemente no tengo suficiente reputación para subir imágenes, por lo que el enlace está escrito en texto. - Eric Eskildsen
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 del registro, desde server1. - mfinni
Lo haré ¡Gracias de nuevo por la ayuda! - Eric Eskildsen
Comentarios rápidos para cualquier lector con el problema de que los nuevos controladores de dominio no registren eventos de auditoría: resulta que los archivos corruptos audit.csv anularon 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 /clear y gpupdate /force En los nuevos centros de distribución, todo está funcionando. ¡Debo a @mfinni por indicarme la configuración de la auditoría de GPO cuando estaba en todo tipo de persecuciones de ganso salvaje en la resolución de problemas! - Eric Eskildsen
Suena bien, me alegra que lo hayas bajado. 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


Un DC degradado de ninguna manera continuará autentificando los inicios de sesión de dominio. Lo que estas viendo es local eventos 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, sigue viendo eventos de inicio de sesión localmente, pero no verá ningún evento de validación de credenciales en DC.


1
2018-04-01 17:16



Exactamente correcto: resultó que el DC degradado estaba registrando la autenticación solo para los recursos compartidos de archivos. Lo que me confundió fue que los nuevos DC no estaban registrando eventos de autenticación en absoluto. El problema terminó siendo que el audit.csv los archivos en los nuevos controladores de dominio estaban dañados, pero siguiendo las instrucciones para eliminar esos archivos en estas publicaciones de TechNet Resuelto eso. - Eric Eskildsen