Определить приложения, которые настроены для подключения к определенному контроллеру домена
Я работаю с Домен Windows с множеством контроллеров домена (DC). Я хочу удалить некоторые из них, но я знаю, что есть некоторые приложения, которые жестко запрограммированы для использования определенного контроллера домена для аутентификации. Однако я не знаю, что это за приложения. Как я могу определить, какие приложения можно настроить на использование одного контроллера домена домена, чтобы я мог предотвратить сбой, когда этот контроллер домена переходит в автономный режим?
Выключите каждый DC на пару дней и дождитесь криков.
Серьезно, это единственный способ.
Кто бы ни хотел общаться с Active Directory, должен найти контроллер домена, используя правильный процесс. Но некоторые разработчики приложений определенно достаточно глупы, чтобы захотеть статически определенный DC; ну, это их вина, и они должны за это заплатить.
Но у вас, как у администратора AD, нет абсолютно никакого способа узнать, обращается ли приложение к определенному DC, потому что оно действительно искало его надлежащим образом или потому, что кто-то настроил его статически.
К сожалению, единственный выход - отключить каждый DC и проверить, не перестает ли что-нибудь работать.
Другой метод, чтобы попытаться идентифицировать эти серверы, может заключаться в запуске чего-то вроде сетевого монитора на контроллерах домена и запуска захвата, фильтрации трафика аутентификации. Затем вы можете выполнить дополнительную фильтрацию по IP-адресам ваших серверов, чтобы сузить отображаемые результаты. Хитрость заключается в том, чтобы определить, какой аутентификационный трафик связан с вашими приложениями. Искать AS Request Cname трафик, содержащий имя пользователя, как на скриншоте ниже, и исследуйте его. По общему признанию, мне никогда не приходилось этого делать, но это, безусловно, один из методов, который я бы попробовал.
Единственное, что вы можете сделать, это удалить запись A и другие мнемоники DNS. Это приведет к тому, что обычные записи DNS для DC не будут зарегистрированы и не будут возвращены для нормальной аутентификации или подключений групповой политики. Затем запустите захват пакета, чтобы определить, откуда может исходить любой трафик.
Как оптимизировать расположение контроллера домена или глобального каталога, который находится за пределами сайта клиента
http://support.microsoft.com/kb/306602
Обычно это делается для топологии «ступица и спица». Для распределенного сайта вы не хотите, чтобы DC регистрировал записи DNS, чтобы к нему могли подключаться только клиенты этого сайта. После того, как вы настроите это, обычный трафик аутентификации должен быть минимизирован для контроллера домена.
- Добавьте новые контроллеры домена в свою среду (та же версия ОС или новая версия ОС, если вы уверены в совместимости приложений).
- Маскируйте старые контроллеры домена в DNS, это означает, что удалите все, что зарегистрировано службой NetLogon (ну, не все, записи GUID используются для репликации, поэтому мы должны сохранить этот).
- Подождите, пока истечет срок действия кешей клиентов и ТАДА! Каждый запрос LDAP, который вы видите, достигает замаскированного контроллера домена, каждый запрос аутентификации исходит от приложений и серверов, не использующих DCLocator и в конечном итоге имеющих жестко запрограммированную конфигурацию. Поскольку скрытые контроллеры домена все еще работают и реплицируются, это не влияет на использование жестко запрограммированных приложений.