Пожалуйста, терпите меня, я разработчик программного обеспечения и мало знаю о доменах Active Directory и Windows Server.
Я запускаю приложение интрасети .NET MVC на IIS (Windows Server 2016 Стандартный), который использует проверку подлинности Windows (Согласовать, NTLM, в этой последовательности). В нашем домене используется несколько контроллеров домена (я прочитал этот ответ чтобы проверить, почему требуется несколько контроллеров домена и что больше нет понятия «основной» и «резервный»). Вчера во время некоторых миграций контроллеров домена наши пользователи не могли пройти аутентификацию в приложении. Мне сказали, что во время проблем с аутентификацией контроллер домена «по умолчанию», который используется IIS / приложением, был отключен в течение некоторого времени во время процесса миграции, и что IIS не контактировал ни с одним другим контроллером домена в домене.
В нашем приложении нет жестко заданного IP-адреса или имени хоста для контроллера домена. Итак, как IIS / приложение определяет, какой DC он должен использовать для аутентификации Windows?
Могу ли я изменить или настроить IP-адрес где-нибудь в приложении или в IIS? И, что наиболее важно, могу ли я настроить IP / имя хоста любого другого контроллера домена для использования в качестве резервного, чтобы это не повторилось в будущем?
Я уже задавал этот вопрос о Stacked Overflow раньше, и мне сказали, что это не имеет ничего общего с программированием и было перенаправлено на Server Fault. Поэтому я полагаю, что не могу ничего решить кодовым образом. Хотя я не являюсь экспертом по AD / администратором домена, я все же открыт для новых знаний и приобретения опыта в этой области. Это обязательно поможет моей карьере в будущем.
Если вам нужна дополнительная информация, не стесняйтесь спрашивать.
Заранее спасибо.
Это отличный вопрос, и я не уверен на 100%, как это делает IIS, но вот некоторая информация, которая может вас направить.
Обычно контроллеры домена Active Directory на сайте выбираются на основе конфигурации сайтов и служб. Клиент попытается запросить домен с разрешением DNS на domain.com. Поскольку все контроллеры домена в домене обычно служат в качестве NS-записей с циклическим перебором в DNS домена, случайный контроллер домена будет выбран и опробован. Затем этот DC проверит сайты и службы на предмет списка подсетей и сопоставит клиента с сайтом, назначенным этой подсети. После выбора сайта обычно можно выбрать как минимум два контроллера домена. Я не уверен, как выбирается конкретный DC на сайте, но я предполагаю, что это основано на загрузке или циклическом переборе. Как только система извлекает этот DC из этого процесса, она имеет тенденцию придерживаться этого DC для будущей аутентификации, пока не произойдет ошибка и не принудительно переключит его на новый. Возможно, это проблема, с которой вы столкнулись. IIS загружен с определенным контроллером домена, и хотя этот контроллер домена больше не доступен, он все равно пытается запросить его. Сброс процесса или веб-сервера очистил бы эту кешированную аутентификацию.
Меня бы удивило, что у Microsoft не было бы более надежного метода переключения при отказе, однако похоже, что многие другие люди сталкивались с подобными проблемами: https://community.spiceworks.com/topic/407295-webserver-with-domain-authentication-doesn-t-failover-when-one-dc-is-gone
Я бы дважды проверил, что ваш сервер IIS настроен на использование нескольких контроллеров домена в качестве источников DNS, а подсети и сайты ваших сайтов и служб настроены правильно. Я также хотел бы исследовать различные методы аутентификации, которые IIS использует, и посмотреть, соответствует ли другой более точно вашим потребностям.
Дважды проверьте, что другие контроллеры домена действительно подключены к сети и работают правильно. Я сталкивался с ситуациями, когда я предполагал, что все контроллеры домена на сайте работают правильно, но оказалось, что это не так, когда перезагрузка одного приводила к сбою сайта. Возможно, диск C: заполнен или службы запускались неправильно. Распространенная проблема заключается в том, что контроллер домена настроен на использование себя в качестве основного DNS, а AD запускается до службы DNS, что приводит к сбою DNS и AD на нем. Исправление состоит в том, чтобы указать контроллеры домена на его узлы как на основные.