Вопрос или проблема
Я реализую проект по миграции доменов (множество одноузловых доменов объединяются в один глобальный AD) в моей компании.
Я мигрировал пользователей, компьютеры и группы (используя Quest on-demand migration tool), и я проверил, что история SID записывается правильно в учетные записи пользователей и групп. Я вижу, что атрибут SIDHistory заполнен для пользователей и групп с правильными значениями.
Учетная запись пользователя, мигрированная в новый домен, пытается получить доступ к файловому серверу в старом домене. В журнале файлового сервера старого домена я вижу:
Объект сетевого ресурса был проверен на возможность предоставления клиенту желаемого доступа.
Объект:
Идентификатор безопасности: NEWDOMAIN\admig2
Имя учетной записи: admig2
Домен учетной записи: NEWDOMAIN
Идентификатор входа: 0x1B7Dxxxx
Сетевая информация:
Тип объекта: Файл
IP-адрес источника: 10.ab.cd.ef
Порт источника: 49782
Информация о ресурсе:
Имя ресурса: \\*\SHARE
Путь к ресурсу: \??\D:\SHARE
Относительное имя объекта: \
Информация о запросе на доступ:
Маска доступа: 0x80
Доступы: ReadAttributes
Результаты проверки доступа:
ReadAttributes: Не предоставлено
Я выполнил следующие команды как в старом, так и в новом доменах:
старый домен
netdom trust <fqdn старого домена> /domain:<fqdn нового домена> /enablesidhistory:yes
netdom trust <fqdn старого домена> /domain:<fqdn нового домена> /quarantine:no
новый домен
netdom trust <fqdn нового домена> /domain:<fqdn старого домена> /enablesidhistory:yes
netdom trust <fqdn нового домена> /domain:<fqdn старого домена> /quarantine:no
Уже прошло несколько часов, поэтому все должно было реплицироваться везде. Тем не менее, я получаю ту же ошибку при попытке доступа к файловому ресурсу с учётными данными мигрированного пользователя: доступ запрещен, обратитесь к администратору.
Кроме отключения SIDfiltering и миграции групп пользователя, есть ли еще области, которые мне нужно проверить и о которых я забыл упомянуть выше? Спасибо.
Результат одного из тестов:
Я считаю, что исключил NTLM как причину – это не оно. Когда я создаю новую папку для R/W для всех и в списке управления доступом даю разрешение OLDDOMAIN\admig2 на эту новую папку, NEWDOMAIN\admig2 может получить доступ к нему. Это все еще сервер с доменом OLDDOMAIN. Меня смущают эти симптомы. Да, OLDDOMAIN\Пользователи домена — это локальная доменная группа и NEWDOMAIN\admig2 не является её участником, но именно здесь должна сработать SidHistory, и из-за старого SID, являющегося членом OLDDOMAIN\Пользователи домена, я считаю, что это всё равно должно работать, но это не так. Или …?
Я продолжу тесты завтра.
Объяснение и решение проблемы следующие:
- Файловый ресурс в исходном домене, на уровне корневой папки, использовал OLDDOMAIN\Пользователи домена в качестве группы пересечения
- членства новых-доменных-пользователей и старых-доменных-групп связаны до тех пор, пока старая-доменная-группа также мигрирована
- OLDDOMAIN\Пользователи домена никогда не были и никогда не будут подлежать миграции, это очевидно
Группа Пользователи домена — это встроенная группа, специфичная для каждого домена, и её SID не мигрируется и не реплицируется между доменами. Это означает, что даже при миграции истории SID, пользователи, перемещенные в домен NEWDOMAIN, не будут членами домена OLDDOMAIN\Пользователи домена
Решение было довольно простым, создать универсальную (это может быть глобальная) группу AD в новом домене NEWDOMAIN и настроить её как правильную группу пересечения на сервере с доменом старого домена.
Почему это настроено таким образом в старом домене, не только вне моего понимания.
Ответ или решение
Перенос домена и сохранение SIDHistory являются важными аспектами, которые могут внести значительные изменения в IT-инфраструктуру компании. Подобные проекты требуют тщательной подготовки и глубокого понимания методологий управления учетными записями и ресурсами между доменами. Рассмотрим проблему, указанную в вашем проекте миграции домена, и предложим возможное решение.
Теория (Theory):
Доменные миграции обычно предполагают интеграцию нескольких локальных доменов в одну глобальную Active Directory. При миграции учетных записей пользователей, компьютеров и групп с помощью инструментов, таких как Quest On-Demand Migration Tool, ключевым моментом является сохранение истории идентификаторов безопасности (SIDHistory). SIDHistory позволяет новым учетным записям пользователей сохранять доступ к ресурсам в старом домене, опираясь на старые SID. Это особенно важно в обстановке, где ресурсы в старом домене необходимо поддерживать доступными для новых учетных записей пользователей.
Однако, несмотря на корректную запись SIDHistory, могут возникнуть проблемы с доступом к файловым серверам старого домена. Это часто происходит из-за несовпадения групповых членств между доменами, особенно когда такие группы, как Domain Users, не мигрируют и остаются специфичными для каждого домена.
Пример (Example):
В вашем случае пользователи, перенесенные в новый домен (NEWDOMAIN), пытаются получить доступ к файловому серверу в старом домене (OLDDOMAIN). Несмотря на успешную миграцию SIDHistory, в журнальных логах сервера старого домена регистрируется отказ в доступе. Это связано с тем, что группы, такие как OLDDOMAIN\Domain Users, которые использовались как промежуточные (транзитные) группы для доступа, не переносятся в новом домене. Таким образом, даже если SIDHistory корректно сохранена, новые пользователи не будут признаны членами OLDDOMAIN\Domain Users на сервере старого домена.
Применение (Application):
Чтобы решить эту проблему, каждая компания должна учитывать нюансы работы с группами при миграции доменов. В вашем случае было предложено создать новую универсальную (или глобальную) AD-группу в новом домене NEWDOMAIN и настроить ее как транзитную группу на файловом сервере старого домена. Это обеспечит, чтобы учетные записи пользователей из NEWDOMAIN могли пройти проверку доступа для ресурсов, использующих группы из OLDDOMAIN.
Этот подход представляет собой простое, но эффективное решение проблемы доступа. Создание универсальной или глобальной группы в NEWDOMAIN позволяет обеспечить бесшовное отображение групп OLDDOMAIN\Domain Users без необходимости их непосредственного переноса между доменами. Это также уменьшает риск возникновения конфликтов безопасности и несоответствий в политике доступа между доменами.
Дополнительные рекомендации:
-
Анализ групповых политик: Проверьте политики и группы доступа в обоих доменах. Убедитесь, что все критически важные группы из старого домена имеют свои эквиваленты в новом.
-
Тестирование доступа: Проводите регулярное тестирование доступа пользователей к критически важным ресурсам после миграции. Это позволит оперативно выявлять и устранять возможные проблемы.
-
Журналы и мониторинг: Обратите внимание на журнальные логи обоих доменов для своевременного выявления проблем с доступом. Часто ошибки в логах могут указать на недостающие разрешения или неверные настройки.
-
Обучение пользователей: Проводите обучение пользователей и администраторов обновленным процедурам безопасности и доступа в новом домене, чтобы избежать ошибок, связанных с привычками работы в старой инфраструктуре.
Перенос домена и управление SIDHistory могут быть сложными, но при правильном подходе и внимании к деталям, все проблемы могут быть успешно решены. Важно учитывать уникальность каждой IT-инфраструктуры и адаптировать подходы в соответствии с конкретными требованиями и ограничениями организации.