Миграция не проходит одномоментно, она всегда протянута во времени и требует к себе особого внимания на каждом этапе. При подготовке к пилоту, тестовому переносу и в процессе основной миграции нельзя упускать из виду даже незначительные детали. Маленькое уточнение, вроде регистра имени домена, может сыграть ключевую роль в ошибке запуска.
Если не обращать внимание на точность следования алгоритмам, можно собрать снежный ком из ошибок. Эффективным подходом к устранению сбоев будет оперативное реагирование. Быстрое фрагментарное вмешательство не нанесет ущерба инфраструктуре и сэкономит общее время переноса данных.
Где ждать подвоха
Список ошибок далеко не ограничивается теми примерами, которые мы приведем. Учитывая скорость изменений информационной среды, можно предполагать, что всегда могут появиться новые и решиться старые проблемы миграции. Но для их решения всегда потребуется скрупулезный подход и высокая квалификация.
1. Репликация исходного Active Directory
Важность на этапе подготовки переноса представляет не только целевой каталог, совместимый с ОС и поддерживающий необходимые интеграции, но и исходный Active Directory. Его проверка должна в обязательном порядке включать оценку репликации, от которой зависит полнота полученных данных.
Для оценки состояния репликации используют инструменты repadmin /showrepl и dcdiag. Через них генерируются отчеты об успехе последней репликации для каждого контроллера домена. Длительные задержки или регулярные ошибки служат признаком проблемы с сетью, DNS или конфигурацией службы каталогов. Подобная проблема может привести к частичной потере данных на новых контроллерах домена и невозможности их переноса.
2. Ошибка на уровне инструментов и данных
Сбои могут происходить при некорректном заполнении полей или превышении лимитов на контроллере домена. Например, в поле «Телефон» проставлен дефис или спецсимвол, который целевой каталог не принимает. При строгих настройках правил миграции есть риск, что карточка пользователя не будет создана.
Может произойти и ситуация, при который превышен лимит контроллера домена. По умолчанию серверный лимит LDAP рассчитан на 1000 объектов в пределах одной выгрузки. Для миграции это критично, так как перенос каталога строится на LDAP-выгрузках (мигратор формирует запросы к контроллеру домена и получает выборку объектов, которые трансформируются в целевой формат). Если инструмент не реализует LDAP paging, он получает только первую страницу, интерпретируя ее как полную выборку и не выгружая оставшуюся часть объектов.
3. Миграция паролей
Одной из самых критичных ошибок можно назвать перенос аутентификационных данных. Проблема возникает, когда для этой задачи применяется устаревший инструментарий, в частности, связка ADMT и PES, несовместимые с современными политиками безопасности.
PES использует алгоритм шифрования, который признан криптографически ненадежным. В современных средах его поддержка на стеке Kerberos и других компонентах безопасности систематически отключается или деактивирована по умолчанию. Когда шифр отключен на контроллерах домена или целевых серверах, механизм аутентификации не может корректно обработать пароль, перенесенный через PES. В результате учетные данные интерпретируются как неверные.
Для решения проблемы можно использовать инструмент, который не опирается на RC4 и применяет более современные алгоритмы для передачи паролей. Вторым путем будет принудительная смена паролей при первом входе в систему после миграции.
4. Неучтенные зависимости
Ошибка проявляет себя на финальном этапе миграции, когда формально учетные записи присутствуют на новом домене, а фактического доступа к рабочим ресурсам нет. Например, прекращают работать интеграции и лицензии. Доступ к внутренним порталам и лицензиям на ПО часто привязан к конкретному UPN или SID. Но при смене домена эти привязки автоматически не обновляются и происходит сбой.
От привязки к SID страдают и права доступа к файловым ресурсам. Если целевая система не поддерживает SID History или он некорректно настроен, разрешения на уровне NTFS/сетевых шар перестают работать.
Для минимизации рисков до старта миграции проводят аудит зависимостей с фиксацией типов привязки и составляется план переноса, учитывающий действия по обновлению прав доступа. Такие шаги помогут перевести проблему из разряда «внезапных сбоев» в управляемые риски.
5. Сбой после процесса
Возможная ошибка кроется на этапе декомиссии, когда старая инфраструктура выходит из эксплуатации. При миграции в другой домен у пользователя появляется новый SID, но для мгновенного начала работы со старыми файлами используют SID History. Проблема появится, если оставить все SIDs. При входе система собирает Kerberos-токен, куда входят все группы и все SIDs. Если их много, токен становится слишком большим. Тогда пользователь не сможет войти, а приложения будут выдавать ошибки.
Когда все права на файловых ресурсах будут переписаны на новые SIDs, нужно удалить SID History. Тогда злоумышленник не сможет получить права админа, используя SID администратора из другого домена.
Выводы
Для успеха проект миграции нужно рассматривать как управляемый процесс с четкими контрольными точками: аудит, учет лимитов, отказ от устаревших механизмов, инвентаризация зависимостей, тестирование и постмиграционная проверка. Такой подход обеспечивает стабильность и безопасность инфраструктуры, что особенно ценно для бесперебойной работы бизнеса. Ведь в итоге мы получим предсказуемые сроки реализации проекта и полный контроль на каждом этапе миграции.
Изображение на обложке: Pragmatic Tools, генерация через ChatGPT
Комментарии