Несколько часов назад несколько наших рядовых серверов не смогли пройти аутентификацию на двух контроллерах домена, которые они должны были использовать. Рядовые серверы и контроллер домена расположены в одном центре обработки данных и находятся на отдельном «сайте» в AD. При запуске DCDiag проблем не возникает, и мы подтвердили, что серверы и контроллеры домена имеют сетевое соединение друг с другом. При запуске nslookup на рядовых серверах в каждом случае отображается правильный DC, указанный в качестве сервера имен.
Кажется, что аутентификация LDAP работает, однако аутентификация Kerberos перестала работать. По сути, все ключевые внутренние службы остановлены.
Вот подробности некоторых проблем, с которыми мы сталкиваемся с рядовыми серверами:
Exchange - служба топологии не может найти контроллеры домена. Таким образом не удается запустить банк данных Exchange.
SharePoint - проверка подлинности не выполняется на уровне IIS и между IIS и SQL (эта ферма работала несколько лет).
Дополнительное устранение неполадок:
NLTEST / DCLIST: имя домена - не найден контроллер домена для получения списка контроллеров домена
NLTEST / Сервер: имя сервера - оба контроллера домена успешно завершены.
NLTEST / DSGetDC: домен - команды выполнены успешно.
NLTEST / dsgetsite - успешно завершается.
GPUpdate - Пользователь не найден. Домена не существует
Выход nslookup -type=SRV _kerberos._tcp.dc._msdcs.subdomain.mydomain.com на сервере обмена:
Server: colo-dc-001.subdomain.mydomain.com
Address: 10.11.2.20
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
priority = 0
weight = 100
port = 88
svr hostname = branchf-dc-001.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
priority = 0
weight = 100
port = 88
svr hostname = colo-dc-001.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
priority = 0
weight = 100
port = 88
svr hostname = hq-dc-003.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
priority = 0
weight = 100
port = 88
svr hostname = colo-dc-002.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
priority = 0
weight = 100
port = 88
svr hostname = hq-dc-004.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
priority = 0
weight = 100
port = 88
svr hostname = branchc-dc-002.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
priority = 0
weight = 100
port = 88
svr hostname = branchm-dc-001.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
priority = 0
weight = 100
port = 88
svr hostname = branchs-dc-001.subdomain.mydomain.com
branchf-dc-001.subdomain.mydomain.com internet address = 10.10.2.22
colo-dc-001.subdomain.mydomain.com internet address = 10.11.2.20
hq-dc-003.subdomain.mydomain.com internet address = 10.1.2.20
colo-dc-002.subdomain.mydomain.com internet address = 10.11.2.21
hq-dc-004.subdomain.mydomain.com internet address = 10.1.2.21
branchc-dc-002.subdomain.mydomain.com internet address = 10.5.2.21
branchm-dc-001.subdomain.mydomain.com internet address = 10.6.2.21
branchs-dc-001.subdomain.mydomain.com internet address = 10.7.2.22
Мы можем подключиться по протоколу RDP к любому из серверов, на которых размещены указанные выше службы, но эти службы не будут работать.
Системные журналы на рядовых серверах содержат некоторые сообщения об ошибках о невозможности найти контроллер домена.
Итак, в основном сеть вроде бы работает и контроллеры домена работают, но рядовые серверы прямо в том же сегменте сети не могут их найти. Где искать проблему?
Эта проблема была вызвана изменением групповой политики, которое было предназначено для рабочих станций конечных пользователей, но было ошибочно применено к некоторым рядовым серверам. Изменение групповой политики включило DirectAccess.
Для наших серверов на объекте хостинга применение этой политики привело к заключению, что эти серверы находятся в ненадежной сети. Таким образом, они включили брандмауэр Windows, который не позволял им обнаруживать наши контроллеры домена или связываться с ними.
Мы откатили изменения, внесенные групповой политикой, удалили рядовые серверы из домена и добавили их обратно в домен, и это устранило проблему.
Я бы начал смотреть DNS. Для меня это действительно пахнет DNS.
Похоже, что чего-то не хватает в _msdcs.domain.com зона прямого просмотра?
Если вы запустите nslookup -type=SRV _kerberos._tcp.dc._msdcs.domain.com что вы получаете за выход?
Обнюхивайте трафик на контроллерах домена или на рядовых серверах, когда вы выполняете неудачные диагностические команды, и публикуйте вывод здесь, если проблема не является явно очевидной. В NLTEST /DCLIST:domain.com Команда, например, должна заставить клиент выдать некоторый DNS-запрос в поисках LDAP-сервера на своем сайте, за которым следует пара привязок RPC.