Контроллер домена считает, что его в публичной сети

У нас есть основной контроллер домена Server 2008 R2, у которого , похоже, возникает амнезия, когда речь заходит о том, в какой сети он находится. (Только) сетевое соединение определяется при запуске как «Публичная сеть».

Тем не менее, если я отключу, а затем снова включу соединение, оно с радостью обнаружит, что оно на самом деле является частью доменной сети.

Это потому, что доменные службы AD не запускаются при первоначальном определении сетевого расположения?

Эта проблема вызывает некоторые проблемы с правилами брандмауэра Windows (которые, как я знаю, могут быть решены другими способами), поэтому мне просто интересно узнать, знает ли кто-нибудь, почему это происходит.

У вас есть шлюз по умолчанию для этого соединения? Он отвечает на запросы ping?

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)

• Перезапускайте службу NLA вручную после каждой перезагрузки (но: «IPCONFIG / RENEW» должен быть предпочтительным)!

Еще одна причина также может быть, когда на контроллере домена настроены два или более 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

Я видел подобное поведение, стоявшее на сервере 2008 R2 AD. Меня привлекло несколько сетевых адаптеров, хотя они не использовались. Как только я отключил неиспользуемые сетевые карты и перезагрузился, проблема исчезла.

Точная функция Windows, с которой вы столкнулись, называется NLA (Network Location Awareness). Я не знаю достаточно об этом, чтобы претендовать на звание эксперта, но я знаю, что есть некоторая интересная информация о том, как все это работает или должно работать.

В моем случае сервер был DMZ и многие правила брандмауэра блокировали сервер для общения с контроллерами домена. В этом случае вам потребуется открыть брандмауэры (аппаратное обеспечение FW), чтобы позволить серверам обмениваться данными. Также для запуска теста подключите сервер к сети, где правила брандмауэра разрешают связь между клиентом и серверами.

После установки нового контроллера домена вы можете обнаружить, что для «WINDOWS FIREWALL» неправильно установлено значение «DOMAIN: ON». Это результат неправильной установки по умолчанию, предоставленной Microsoft. Чтобы это исправить, очистите настройки DNS IP6 в сетевом подключении от «:: 0» до автоматического. Также очистите серверы пересылки IP6 с DNS-сервера.