У нас есть Server 2008 R2 Первичный Контроллер домена, у которого, кажется, амнезия, когда дело доходит до определения того, в какой сети он находится. (Единственное) сетевое соединение при запуске определяется как «общедоступная сеть».
Тем не менее, если я отключу, а затем снова включу соединение, он с радостью обнаружит, что на самом деле это часть доменной сети.
Это потому, что доменные службы AD не запускаются при первоначальном определении сетевого расположения?
Эта проблема вызывает некоторые проблемы с правилами брандмауэра Windows (которые, как мне известно, могут быть решены другими способами), поэтому мне в основном просто любопытно узнать, знает ли кто-нибудь, почему это происходит.
Будет ли сеть контроллер домена классифицируется как доменная сеть не зависит от конфигурации шлюза.
Поведение ложной классификации сети может быть вызвано NLA (осведомленность о местоположении в сети) услуга starts before the domain is available. В этом случае выбирается публичная или частная сеть и впоследствии не корректируется.
Как проверить, дана ли данная неисправная ситуация
Когда контроллер домена после перезагрузки находится в общедоступной сети, перезапустите службу NLA или отключите / повторно подключите сеть. После этого контроллер домена должен быть в доменной сети.
Как решить это
Это может помочь установить службу NLA на отложенный запуск. Лучше проверьте, почему домен должен присутствовать долго. Похоже, что домену требуется больше времени для запуска при наличии нескольких сетевых карт.
Когда это не помогает
Когда ни ускорение загрузки домена, ни задержка NLA-справки и ошибка вызвана длительной загрузкой домена (см .: «как проверить ...»), то есть еще кое-что, что можно сделать .
Сдвинуть загрузку службы NLA до конца запуска службы, изменить порядок загрузки в реестре (опасно)
Следующая запись реестра устанавливает зависимости для NSI RpcSs TcpIp Dhcp Eventlog NTDS DNS:
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc]
"DependOnService"=hex(7):4e,53,49,00,52,70,63,53,73,00,54,63,70,49,70,00,44,68,\
63,70,00,45,76,65,6e,74,6c,6f,67,00,4e,54,44,53,00,44,4e,53,00,00
Выполнять «IPCONFIG / RENEW» из планировщика при запуске с задержкой в 1 или 2 минуты (лучше, чем запуск службы NLA)
Еще одна причина может заключаться в том, что на контроллере домена настроено два или более IP-адресов (на той же или на других сетевых картах), а дополнительные сети не настроены в DNS.
Воспроизведение поведения
На тестовом контроллере домена (один DC!) Я удалил запись шлюза по умолчанию и установил DNS Server к delayed start. При этом домену требовалось много времени для загрузки, и сеть была классифицирована как public. После отключения и повторного подключения сетевого кабеля сеть была правильно классифицирована как domain network.
редактировать
с благодарностью из комментариев Daniel Fisher lennybacon и Joshua Hanley:
Как добавить зависимость для NlaSvc в DNS и NTDS
бегать sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS из CMD (используйте sc.exe, если вы запускаете его в PowerShell). Если вы хотите дважды проверить существующие зависимости перед добавлением DNS и NTDS, используйте sc qc nlasvc
У вас есть шлюз по умолчанию для этого соединения? Отвечает ли он на запросы ping?
Windows использует шлюзы для идентификации сетей; если у него не настроен шлюз или если он не может успешно проверить связь, он не сможет идентифицировать сеть, к которой он подключен, и будет считать, что это общедоступная.
Я видел подобное поведение при установке сервера AD 2008 R2. Что меня поразило, так это то, что было включено более одной сетевой карты, даже если она не использовалась. Как только я отключил неиспользуемые сетевые карты и перезагрузился, проблема исчезла.
Точная функция Windows, с которой вы столкнулись, называется NLA (Network Location Awareness). Я знаю об этом недостаточно, чтобы претендовать на звание эксперта, но я знаю, что в интертубах есть интересная информация о том, как все это работает или должно работать.
В моем случае сервер находился в DMZ, и многие правила брандмауэра блокировали сервер для взаимодействия с контроллерами домена. В этом случае вам нужно будет открыть брандмауэры (аппаратное ПО), чтобы серверы могли обмениваться данными. Также, чтобы запустить тест, подключите сервер к сети, где правила брандмауэра разрешают связь между клиентом и серверами.
После установки нового контроллера домена вы можете обнаружить, что «WINDOWS FIREWALL» неправильно настроен на «DOMAIN: ON». Это результат неправильной установки по умолчанию, предоставленной Microsoft. Чтобы исправить это, сбросьте настройки IP6 DNS для сетевого подключения с ":: 0" обратно на автоматический. Также удалите серверы пересылки IP6 с DNS-сервера.