Миграция домена с SAMBA 3 на ActiveDirectory (опыт миграции домена без простоя)

В недавно опубликованной статье TerAnYu описал как производил миграцию домена с Samba на Active Directory. Способ был выбран, на мой взгляд, очень интересный, но, к сожалению, при миграции небольшого домена (автор упоминает в тексте статьи о 70 пользователях офиса) многие интересные проблемы остались «за кадром».
Я, в свою очередь, постараюсь абстрагироваться от скриптов дампа/восстановления пользователей и сконцентрироваться на описании возникших проблем и их решения. Быть может описанный опыт поможет кому-нибудь сократить трудозатраты на подготовку миграции.

И, конечно, я слукавил — простой будет, но самый минимальный.

Почему отказались от Samba

Чтобы предупредить все дальнейшие вопросы про Samba отвечу:
Изначально заложенная (нами в нашей инсталляции, а не разработчиками) в домен на Samba архитектура имела некоторые просчёты, которые проявили себя при масштабировании домена. Когда встала необходимость полной реструктуризации домена, взвесив все «за» и «против», руководство приняло решение вместо реорганизации Samba мигрировать на Active Directory.
Этот вопрос далее считаю закрытым.

Концепция

Опишу вкратце концепцию миграции:

1. Составляется перечень ВСЕХ сервисов, использующих домен (для авторизации или как хранилище другой информации)
2. Подготавливаются новые комплекты конфигураций для работы этих сервисов с Active Directory.
3. Данные исходного домена на Samba сохраняются в дамп.
4. Подготавливается первый контроллер нового домена на Windows 2003 server (после миграции вы сможете без проблем мигрировать домен на контроллеры с более новой ОС, но следующий шаг сработает только на 2003-м сервере). Новому серверу утилитой newsid устанавливается SID домена на Samba (при повышении роли этот SID станет SID’ом домена Active Directory)
5. Настраивается DNS.
6. В созданном домене заводятся объекты безопасности (пользователи/группы/компьютеры) в порядке возрастания их RID. В домене с единственным DC RID назначаются строго по-порядку (у меня при большом количестве тестовых прогонов импорта не было ни одного случая доказывающего обратное)
7. Осуществляется синхронизация паролей пользователей из старого домена в новый.
8. В новый домен переводятся рабочие станции и сервера.
9. На сервисах, использующих домен, меняется конфигурация на заранее подготовленную и протестированную.

Теперь рассмотрим каждый этап по-порядку.

Перечень сервисов, использующих домен.

Этот перечень должен быть все зависимости собираетесь ли вы куда-то мигрировать или нет. Всегда важно знать кто и как использует Ваш домен. Список должен содержать информацию о:

1. Хосте(ах) на которых работает сервис.
2. О протоколе и методе проверки подлинности, используемом при подключении к домену.
3. Об учётных данных, с которыми сервис авторизуется в домене.
4. О формате хранимых в LDAP данных сервиса (если сервис сохраняет, свои данные в LDAP)

Этот список потребуется Вам при перенастройке сервисов.

Новые комплекты конфигураций

Они потребуются и подготовить их следует заранее (мы ведь не хотим, чтобы бизнес простаивал!).
Что изменится? Вполне логично, что просле переезда у Вас останется ещё большое количество linux систем, которые необходимо
будет интегрировать в новый домен (быть может от большей части этих систем вы и не собираетесь избавляться)

1. Ваши сервисы больше не смогут проверять пароль пользователя, сверив его хэш, с хранящимся в LDAP — они больше не получат из LDAP никакого хэша. Придётся переделывать всё (я имею ввиду сервисы, которые не станут работать с kerberos) на проверку пароля с помощью LDAP bind. Я настоятельно рекомендую везде где это возможно задействовать для авторизации kerberos — это облегчит жизнь пользователям и снизит нагрузку на Ваши контроллеры домена.
2. Теперь в Вашем домене могут быть вложенные группы, поэтому при проверке членства пользователя в группе придётся учесть возможность наличия вложенных групп.
3. Имеет смысл перевести Ваши сервисы на использование kerberos (если это не было сделано ранее).
4. Для хранящихся в LDAP данных придётся поискать другие атрибуты, либо заняться расширением схемы Active Directory (настоятельно не рекомендую использовать первый попавшийся атрибут с подходящим форматом — старайтесь думать чем ваше решение может обернуться в дальнейшем). Благо назначение атрибутов Active Directory хорошо задокументировано — не поленитесь потратить время на изучение документации.

Дамп домена Samba

Тут начинаются интересные моменты.
Samba не контролирует уникальности SID. Поэтому в большом, распределённом домене Вы можете получить несколько объектов безопасности с одинаковым SID. Как-правило это следствие ошибки администратора и эту ошибку надо исправлять немедленно! Наличие нескольких объектов безопасности с одинаковым SID недопустимо (но, к сожалению, в доменах Samba я не раз сталкивался с таким явлением)
В типовой (по мануалу из интернета) инсталляции samba RID начинают выдаваться с 1000. К сожалению, описанным выше методом Вы не сможете мигрировать объекты безопасности с RID меньше чем примерно 1034 (каюсь — запамятовал точное число, но его легко выяснить — поставьте чистый контроллер нового домена и посмотрите последний RID). При создании домена Active Directory создаётся ряд служебных объектов безопасности и они «занимают» эти самые первые RID
В этих двух описанных случаях решение одно:
Вы ведь заранее выгрузили и проанализировали дамп домена на Samba? До часа X еще далеко? Значит есть время не спеша разобраться во всех конфликтных ситуациях и исправить их с минимальными простоями для бизнеса.

Подготавливается первый контроллер нового домена

Во-первых — постарайтесь, чтобы на сервере до повышения роли не было посторонних локальных групп и пользователей (иначе они увеличат числа изначально занятых RID) — это может случиться, если вы будете использовать какой-нибудь типовой образ сервера.
Во-вторых надо достать newsid. На официальном сайте её удалили, но, как говорится, что попало в интернет…
Да, подготавливать новый домен вы можете рядом с существующем (я крайне это рекомендую), вы же не намерены сохранять старое NETBIOS имя домена?!

Настройка DNS

При переводе ПК в новый домен (да и при синхронизации паролей) Вам потребуется, чтобы имена в обоих доменах корректно разрешались на любом компьютере в вашей инфраструктуре. Имеет смысл настроить Conditional Forwarding на DNS серверах, обслуживающих оба домена.

Воссоздание объектов безопасности в новом домене.

Время на импорт

Тут хорошо иметь дамп домена, отсортированный по RID.
Выбор средства для импорта дампа — за Вами. Я изначально набросал скрипт на VBScript, но в итоге пришлось переписать всё на C# — иначе получалось очень медленно (перед часом X я проводил тестовую миграцию не один раз для выявления потенциальных проблем). Импорт всех данных прошёл у меня примерно за половину суток (это с некоторыми ухищрениями — о них далее).
Когда домен старый и когда домен большой велика вероятность фрагментации пула RID (в Вашем дампе домена, отсортированном по RID могут быть большие пропуски: пользователи/группы/компьютеры были заведены, а затем удалены) — логично решение:
Создавать пользователя, получать его RID, удалять пользователя. Если RID-1 равно RID следующего пользователя из дампа — заводить пользователя из дампа, иначе повторять цикл «накрутки» RID.
Решение логичное, но оченькатастрофически медленное.
Размер пула RID по-умолчанию — 500. Есть хороший механизм invalidateRidPool, который заставляет сервер запросить у RID Master новый пул.
Использование invalidateRidPool позволило нам значительно сократить время на «прокрутку» RID, а также облегчило следующую проблему.

Чистка «мусора»

К сожалению, после «накрутки» RID в Active Directory Остаётся очень много tombstone из-за них ntds.dit приобретает колоссальные размеры и его репликация на удалённые площадки начинает выглядеть головной болью. Как от них избавиться и облегчить ntds.dit? Только естественным путём.
tombstoneLifetime задаёт время жизни удалённого объекта в Active Directory (не путать с объектами в Recucle Bin — это разные вещи) минимальное значение, которое может быть установлено — 2 дня (значение по-умолчанию — 180 дней), т.е. из база будут удаляться удалённые объекты старше двух дней. Если установить tombstoneLifetime = 2 и подождать два дня… удалится только первые 5000 tombstones. Tombstones удаляются в результате выполнения процедуры Garbage Collection. Процедура эта самостоятельно запускается раз в 12 часов и удаляет не более 5000 объектов за раз. Чтобы очистить большее количество tombstones потребуется выполнить несколько раз Garbage Collection: сократив интервал запуска, либо вызвав процедуру принудительно.
После этого обязательно верните значение tombstoneLifetime и сделайте offline дефрагментацию ntds.dit

Синхронизация паролей пользователей из старого домена в новый.

Вариантов «как это сделать» несколько:

• В Samba существует возможность задать свой скрипт проверки сложности пароля. К сожалению, в скрипт не передаётся логин пользователя, но это легко исправить (это ведь Open Source!)
• Samba хранит NT и LM (для паролей короче 14 символов) хэши паролей — если позволяет ситуация — у Вас есть возможность узнать пароли своих пользователей.
• Можно установить пользователям пароль-по-умолчанию и установить галку «требовать смену пароля при следующем входе» (я крайне это не рекомендую делать)
• Можно обойти всех пользователей

В общем выбирать Вам. Я предпочитаю первый вариант.

Собственно миграция.

Все предыдущие этапы никак не влияли на работу домена. Это была только подготовка, которую можно проводить месяцами, не мешая работе бизнеса. Оставшиеся два этапа придётся делать в согласованный с бизнесом интервал простоя. При соответствующей подготовке и наличии необходимого количества рук простой реально сократить до нескольких ночей (в зависимости от размеров домена, может быть и до нескольких часов).
Тут важно знать простой в работе каких сервис и каких пользователей критичен, а какие могут подождать — в общем Вам надо знать бизнес процессы Вашей компании.
Проверьте ещё раз настройки нового домена: IP-подсети, сайты, политики, настройка синхронизации времени с внешнего источника на вашем эмуляторе PDC.
Проверьте что с ваших рабочих станций корректно разворачиваются DNS имена обоих доменов.

Перевод в новый домен рабочих станций и серверов

Если OC на членах домена XP/2003 и выше — проблем особых не будет — они легко переводятся сразу в новый домен с помощью JoinDomainOrWorkgroup
Для 2000-х придётся сделать промежуточную перезагрузку (вывести из домена-перезагрузить-ввести в домен)
Здесь Вы можете воспользоваться любой доступной Вам системой централизованного управления, либо написать собственные скрипты (они получатся довольно простые). Не забудьте, что для перевода ПК из домена в домен Вам потребуется учётная запись с соответствующими привилегиями как в домене, так и на самих ПК.
Да, не забудьте в настройка DHCP сервера изменить адреса DNS-ов на новые (Вы ведь намерены использовать AD-интегрированные зоны MS DNS не так ли?) Сам DHCP сервер можно сразу не мигрировать (вы потеряете не много функционала) — его можно будет безболезненно заменить на продукт от Microsoft позже.

Смена конфигурации на сервисах, использующих домен.

Вы же подготовили новые файлы конфигурации(инструкции по перенастройке), протестировали новые настройки на макете — так что проблем возникнуть не должно.

Итог.

Потратив много времени на подготовку, около 3-4 дней на импорт объектов безопасности можно перевести компанию с Samba на Active Directory за 1 — несколько ночей.

Если у Вас есть другое видение/опыт подобной миграции — поделитесь пожалуйста — очень интересно проанализировать свои действия, узнать, что можно было бы сделать лучше.
Естественно я затронул только общие проблемы и особенности — двух одинаковых компаний не бывает и везде будут свои уникальные загвоздки.