La conmutación por error del controlador de dominio falla unidireccionalmente

La conmutación por error del controlador de dominio falla unidireccionalmente

El problema que tengo es que si desconecto uno de mis dos controladores de dominio grabables, nadie parece "conmutar por error" al usar el otro controlador de dominio como se supone que debe hacerlo: aplicaciones que ejecutamos dentro de nuestra red que usan AD para autenticación. simplemente siga solicitando un nombre de usuario y contraseña y nunca lo autentique, y los usuarios externos que dependen de un DC de solo lectura en otro segmento de la red tampoco pueden autenticarse en nuestro sitio web de acceso remoto.

Actualmente tengo tres controladores de dominio en mi dominio: DC1, DC2 y RO1. DC1 y RO1 son Server 2019, DC2 es Server 2012R2. Ambos DC grabables son servidores DNS integrados en AD, con sus adaptadores de red configurados para apuntar entre sí.

DC1 y DC2 están en la misma subred. RO1 es un controlador de solo lectura en un segmento de red diferente para admitir una solución de acceso remoto administrada por la organización superior a mí (que administra la red general a la que me conecto).

En el pasado, si desconectara uno u otro DC local, los usuarios locales conmutarían por error al que todavía estuviera ejecutándose (como se esperaba), al igual que los usuarios remotos cuando el RODC busca el activo para autenticarse.

El DC1 actual es una incorporación relativamente nueva que reemplaza a uno llamado DC. DC1 se puso en línea y se unió a DC y DC2, y todo parecía estar bien. Transferí todos los roles de FSMO que tenía DC a su reemplazo, DC1: la consulta de netdom fsmo muestra que todos los roles están en el nuevo DC1. Degradamos y desconectamos DC para retirarlo, ya que era una máquina Server 2012 y estamos migrando de ellas. Se limpiaron algunos registros DNS erróneos que afirmaban que el antiguo DC todavía existía, pero aparte de eso, todo siguió como antes. Sin embargo, en el último ciclo de parches, teníamos DC2 desconectado mientras DC1 y RO1 permanecían activos, pero descubrimos los problemas relacionados con la autenticación mencionados anteriormente. Los usuarios externos no pudieron autenticarse en absoluto, y los usuarios que ya habían iniciado sesión encontraron que nuestras aplicaciones de autenticación de AD de repente les pedían que iniciaran sesión nuevamente (sin éxito).

Desafortunadamente, no estoy seguro de por qué es así. DC1, el nuevo controlador, es definitivamente reconocido por el Dominio. La replicación ocurre bien: Repadmin /showrepl es exitoso y /replsum no reporta errores. Todas las máquinas internas involucradas pueden resolver sus nombres de host y hacer ping entre sí. Si hago ping al dominio, puedo obtener DC grabable, igual que si hago un seguimiento del dominio. Puedo realizar ediciones en DC1 y verlas en DC2, y viceversa (y los cambios como la política de grupo realizados específicamente en DC1 definitivamente existen en la red general). Puedo tomar el RODC y decirle que cargue registros de DC1 y DC2 sin problemas.

Sin embargo, si desconecto DC2, es cuando las cosas se ponen feas. El ping o Tracert a nuestro dominio falla, a los usuarios externos se les niega el acceso y los usuarios internos ven que nuestras aplicaciones autenticadas por AD fallan y solicitan constantemente un nombre de usuario y contraseña. Lo contrario hacenoSin embargo, esto sucede: si desconecto el nuevo DC1, los usuarios locales a veces tienen un ligero retraso como si su máquina estuviera intentando contactar con DC1 antes de conmutar por error a DC2 y autenticarse exitosamente, y los usuarios externos entran bien.

No hay nada muy obvio en los registros de eventos y todo lo que se me ocurre aparece configurado correctamente. No estoy seguro de dónde avanzar a partir de aquí. ¿Alguien ha tenido síntomas similares que haya podido corregir?

Respuesta1

El problema acabó estando relacionado con la configuración del firewall gestionada exclusivamente por la organización que gestiona la red a la que nos conectamos. Algunas reglas de entrada/salida no se aplicaron correctamente, lo que provocó que los hosts no pudieran realizar correctamente la conmutación por error al nuevo controlador de dominio en caso de que el anterior se hubiera desconectado.

información relacionada