В настоящее время мы работаем над так называемым проектом по выделению, т.е. часть более крупной компании OLDCO была продана отдельно, и новая организация создает новый домен Active Directory NEWCO. На этапе перехода контроллеры домена OLDCO и контроллеры домена NEWCO, а также клиенты совместно используют пространство IP-адресов. Домен NEWCO пока доверяет домену OLDCO, поэтому можно, например, пройти аутентификацию на клиентском компьютере NEWCO, используя учетную запись пользователя OLDCO.
Очевидно, что к концу переходной фазы OLDCO AD исчезнет, возможно, из-за разделения сетей, которое произойдет только в отдаленном будущем.
Сейчас мы ищем способ убедиться, что мы можем протестировать приложения на их зависимость от OLDCO. Т.е. если мы переместили приложение X на новые серверы, которые являются членами домена NEWCO, как мы можем быть уверены, что больше не используем ресурсы OLDCO, возможно, не заметив этого.
Мы думали о реализации некоторых правил брандмауэра, которые можно легко включать и выключать, которые временно предотвращали бы любой доступ к контроллерам OLDCO comain с любых перенесенных серверов приложений, как лучшую имитацию того, что «их больше нет», но будет ли это правильным тестом?
Например, не будучи слишком уверенным во внутреннем устройстве AD, я понятия не имею, могут ли контроллеры домена NEWCO кэшировать какие-либо данные из домена OLDCO, пока существует доверие, и этот кеш может истечь в момент времени, когда контроллеры домена OLDCO будут исчезли, и проблемы будут возникать еще долгое время после успешных испытаний.
Кто-нибудь успешно выполнил подобный проект раньше и, возможно, любую другую идею, как моделировать, например, вырезание в лесу AD?
Это сложный ход.
Активируйте успешный аудит входа в учетную запись в свой контроллер домена OLDCO. В журнале безопасности вы увидите все попытки входа в систему для контроллера домена после этого, поэтому в конце вы увидите, аутентифицируется ли что-то еще против него, поскольку учетные данные не кэшируются из вашего контроллера домена NEWCO.
Имейте в виду, что он может создавать много журналов. Убедитесь, что у вас есть большая буква C, или вы можете переместить журнал в другое место.
Для такого хода вам тоже нужно подумать о нескольких вещах;
Если вы используете Exchange, вы можете использовать связанный почтовый ящик для миграции. Готовьтесь к этому.
Экземпляр SQL необходимо протестировать, если вы используете аутентификацию Windows, так как вся пользовательская информация для ведения журнала не подходит для домена newco. Чтобы протестировать эту часть, проще подключить другой сервер sql на newco и перенести данные, чтобы проверить, хорошо ли работает ваше приложение вне производственной среды.
Для файловых ресурсов вам нужно будет проверить группу безопасности для каждой папки, чтобы реплицировать ее. Поскольку старая группа безопасности, определенная в общей папке, больше не будет работать, когда домен oldco упадет.
Вы используете радиус или сервер сертификатов? и т.д...
Как видите, вам нужно сделать много документации, чтобы правильно спланировать свой переезд.
Стандартные контроллеры домена, не предназначенные только для чтения, не содержат кэширования, о котором вы беспокоитесь. Только правильно интегрированные контроллеры домена, существующие в кэше топологии репликации, информация друг о друге, например, актуальные векторы (UTDV) и другие особенности NTDS, которые можно увидеть с помощью ntdsutil.
Если вы тестируете трафик Север-Юг (внутренний-внешний), я бы подумал о тестировании с использованием правил брандмауэра для имитации отключения от рассматриваемых ресурсов.
Если вы тестируете трафик с востока на запад (внутренний-внутренний), я бы подумал о включении расширенных политик аудита на контроллере домена с использованием объектов групповой политики (GPO). Вас больше всего интересует Audit account logon events и Audit logon events настройки доступны в Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy. Ваш объект групповой политики должен быть связан с фильтрацией безопасности группы контроллеров домена BUILTIN.
Затем вы можете собирать события в средстве просмотра событий со следующими идентификаторами:
Я предоставляю фрагмент PowerShell, который вы можете запустить локально (как администратор) на рассматриваемых контроллерах домена для всех совпадающих событий за последние двенадцать (12) часов:
Get-EventLog -LogName Security -After ((Get-Date).AddHours(-12)) | Where-Object { $_.EventId -in 4624, 4625, 4648, 4634, 4647, 4672, 4678, 4679, 4770, 4771, 4774, 4776, 4778 } | Select TimeWritten, Source, EventID, InstancedId, Message | Sort TimeWritten -Descending | Format-Table Auto