Проблема, с которой я столкнулся, заключается в том, что если я отключаю один из двух моих контроллеров домена с возможностью записи, то никто не «переключается» на другой контроллер домена, как это должно быть: приложения, которые мы запускаем в нашей сети и используют AD для аутентификации, просто продолжают запрашивать имя пользователя и пароль и фактически не аутентифицируют вас, а внешние пользователи, использующие контроллер домена только для чтения в другом сегменте сети, также не могут пройти аутентификацию на нашем веб-сайте удаленного доступа.
В настоящее время в моем домене три контроллера домена: DC1, DC2 и RO1. DC1 и RO1 — это Server 2019, DC2 — это Server 2012R2. Оба доступных для записи контроллера домена — это интегрированные в AD DNS-серверы, сетевые адаптеры которых настроены так, чтобы указывать друг на друга.
DC1 и DC2 находятся в одной подсети. RO1 — это контроллер только для чтения в другом сегменте сети, который поддерживает решение удаленного доступа, управляемое организацией, находящейся выше меня (которая управляет общей сетью, к которой я подключаюсь).
Раньше, если бы я отключил один или другой локальный контроллер домена, локальные пользователи переключились бы на тот, который все еще работал (как и ожидалось), так же как и удаленные пользователи, поскольку RODC выбирал активный контроллер для аутентификации.
Текущий DC1 — относительно новое дополнение, заменившее тот, что назывался DC. DC1 был подключен к сети и присоединен к DC и DC2, и все казалось в порядке. Я перенес все роли FSMO, которые были у DC, на его замену, DC1 — netdom query fsmo показывает, что все роли находятся на новом DC1. Мы понизили и отключили DC, чтобы вывести его из эксплуатации, так как это была машина Server 2012, и мы мигрируем с них. Удалили несколько ошибочных записей DNS, которые утверждали, что старый DC все еще работает, но в остальном все работало так же, как и было. Однако в последнем цикле исправлений у нас был DC2 отключен, в то время как DC1 и RO1 оставались активными, но были обнаружены проблемы, связанные с аутентификацией, указанные выше. Внешние пользователи вообще не могли аутентифицироваться, а пользователи, которые уже вошли в систему, обнаружили, что наши приложения аутентификации AD внезапно просят их снова войти в систему (безрезультатно).
К сожалению, я не уверен, почему так происходит. DC1, новый контроллер, определенно распознается доменом. Репликация проходит нормально — Repadmin /showrepl успешно выполняется, а /replsum не сообщает об ошибках. Все вовлеченные внутренние машины могут разрешать свои имена хостов и пинговать друг друга. Если я пингую домен, я могу получить любой доступный для записи DC, так же, как если бы я выполнил tracert к домену. Я могу вносить изменения на DC1 и видеть их на DC2, и наоборот (и изменения, такие как групповая политика, внесенная на DC1, определенно существуют в большей сети). Я могу взять RODC и сказать ему загрузить записи с DC1 и DC2 без проблем.
Однако если я отключу DC2, то вот тогда все пойдет наперекосяк. Ping или Tracert к нашему домену не работают, внешние пользователи получают отказ в доступе, а внутренние пользователи видят, что наши приложения с аутентификацией AD не работают, и постоянно требуют имя пользователя и пароль. Обратное происходитнетОднако, если я отключаю новый DC1, у локальных пользователей иногда возникает небольшая задержка, как будто их машина пытается связаться с DC1, прежде чем переключиться на DC2 и успешно пройти аутентификацию, а внешние пользователи подключаются без проблем.
В журналах событий нет ничего сверхочевидного, и все, что я могу вспомнить, настроено правильно. Я не уверен, куда двигаться дальше — были ли у кого-то похожие симптомы, которые они смогли исправить?
решение1
Проблема оказалась связана с настройками брандмауэра, которые управляются исключительно организацией, управляющей сетью, к которой мы подключаемся. Некоторые входящие/исходящие правила были применены неправильно, в результате чего хосты не могли правильно переключиться на новый контроллер домена в случае, если старый отключался.