IIS: изменить контроллер домена по умолчанию для проверки подлинности Windows
Пожалуйста, терпите меня, я разработчик программного обеспечения и мало знаю Active Directory и домены Windows Server.
Я запуск приложения интрасети .NET MVC на IIS ( Windows Server 2016 Standard ), который использует проверку подлинности Windows ( Negotiate, NTLM , именно в этом порядке). В нашем домене используется несколько контроллеров домена (я прочитал этот ответ , чтобы узнать, почему несколько контроллеров домена) s обязательны, и что больше нет понятия «основной» и «резервный» DC). Вчера во время некоторых миграций контроллеров домена наши пользователи не могли пройти аутентификацию в приложении. Мне сказали, что во время проблем с проверкой подлинности контроллер домена "по умолчанию", который используется IIS / приложением, некоторое время не работал во время процесса миграции, и что IIS не контактировал ни с одним другим контроллером домена в домене.
В нашем приложении нет жестко заданного IP-адреса или имени хоста для контроллера домена. Так как же IIS / приложение определяет, какой DC он должен использовать для аутентификации Windows?
Могу ли я изменить или настроить IP-адрес где-нибудь в приложении или в IIS? И, самое главное, могу ли я настроить IP / имя хоста любого другого контроллера домена для использования в качестве резервной копии, чтобы это не повторилось в будущем?
Я уже задавал этот вопрос в Stacked Overflow раньше, и мне сказали, что это не имеет ничего общего с программирования и был перенаправлен на сбой сервера. Поэтому я полагаю, что не могу ничего решить кодовым способом. Хотя я не являюсь экспертом по 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: заполнен или службы запускались неправильно. Распространенная проблема заключается в том, что DC настроен на использование себя в качестве основного DNS, а AD запускается до службы DNS, что приводит к сбою DNS и AD на нем. Исправление состоит в том, чтобы указать контроллеры домена на его одноранговые узлы в качестве основных.