@Slipeer25 мар 2013 в 09:53

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

7 мин

12K

Комментарии 25

@TerAnYu 25 мар 2013 в 10:25

Спасибо, более грамотно чем у меня :)
И да, здесь хоть как-то рассказано что можно переносить пароли пользователей, с этим у меня были проблемы, пришлось всем один делать (хотя можно было разные и разослать его на корпоративную почту).

@Slipeer 25 мар 2013 в 10:38

При нашем количестве пользователей так просто не получилось бы. Да и «не комильфо», когда пароль пользователя знает кто-нибудь кроме пользователя (пусть даже и на короткое время, пусть даже и администратор).

@GreyCat 25 мар 2013 в 23:27

А можно для тех, кто не очень в теме пояснить, откуда вообще взялась такая задача и что дает такой переход? Обычно все вроде как раз наоборот мигрируют — в первую очередь с целью сэкономить на лицензии Windows-сервера.

@Slipeer 26 мар 2013 в 04:17

Откуда взялась задача, я вроде подробно описал в разделе «Почему отказались от Samba». Просто надо было переделывать либо на Samba, либо на что-то другое. Причём трудозатраты были соизмеримые.
Что дал такой переход: заработали в штатном режиме инструменты, которые нужны бизнесу.

Обычно все вроде как раз наоборот мигрируют — в первую очередь с целью сэкономить на лицензии Windows-сервера.

Иногда в жизни компаний наступает момент, когда они перестают экономить на мелочах, отдавая себе отчёт, что потраченные средства вернутся прибылью. К сожалению бизнесу нужны всё больше продукты от MS, либо те, которые с ними тесно интегрируются.

@Baf 26 мар 2013 в 07:06

Почему к сожалению? :)

@Slipeer 26 мар 2013 в 07:56

Потому что лично мне в них многое не нравится (я бы даже сказал мне многое неприятно в их продуктах). Но это моё личное отношение к продукту и компании и оно не мешает мне здраво оценивать преимущества того или иного продукта в конкретной ситуации.

@GreyCat 26 мар 2013 в 09:23

Ну, я ровно к тому, что обозначенная в «Почему отказались от Samba» позиция ограничивается словами про «имела некоторые просчёты, которые проявили себя при масштабировании домена». Я догадываюсь, что тема rationale на самом деле соизмерима с объемом (если не больше) данной статьи и вы прямо сейчас не очень хотите писать такой текст — но может быть как-то в будущем — интересно было бы узнать об этих «просчётах», например, чтобы не допускать их впредь. Ну и о каких-то плюсах-минусах, что дает вообще AD по сравнению с Samba — какие именно инструменты заработали в штатном режиме и т.д.

@Slipeer 26 мар 2013 в 09:52

Постараюсь объяснить в двух словах на пальцах как это было реализовано (хотя я искренне надеюсь, что вы никогда не столкнётесь с такой архитектурой):
В центральной точке был LDAP сервер, и работающая с ним Samba, которая считала себя PDC сервером.
На удалённых площадках тоже были LDAP сервера, и с ними тоже работали экземпляры Samba, и каждый из них считал себя PDC.
Пулы RID назначались администратором на каждую новую площадку (Администратор выполнял роль RID Master ;) )
«Дерево» LDAP в центре было не монолитно — оно было «склеено» из баз-бэкендов. Сделано это было для того, чтобы на удалённую площадку можно было реплицировать только данные о пользователях с этой площадки + набор пользователей с «доступом везде». В центральную точку реплицировалось всё.
Схема прекрасно работала… до набора «критической массы» — потом начались проблемы с LDAP сервером, которому при каждом запросе приходилось «склеивать» данные из большого количества баз. Собственно в этом и был просчёт.

P.S. Помидорами не кидать — схему придумал не я.
P.P.S. Я прекрасно знаю, что можно было применить расширенный фильтр (для фильтрации по dn — есть в том же OpenLDAP) в параметрах репликации и реализовать ту же схему но без «склейки» баз. Получилось бы даже более гибко. Но переделка была соизмерима с описанной миграцией, а на выходе был бы всё тот же NT4 домен.

@ComputerPers 25 мар 2013 в 10:47

По поводу «JoinDomainOrWorkgroup» на офсайте написано

Remarks
When moving a computer from a domain to a workgroup, you must remove the computer from the domain before calling this method to join a workgroup. After calling this method, restart the affected computer to apply the changes.

Да и вообще ОС не позволяет сменить домен без перезагрузки. Или у Вас есть другие данные?

@Slipeer 25 мар 2013 в 10:59

Всё правильно — не позволяет.
Просто начиная с XP/2003 можно сменить домен AAAAA на домен BBBBB с одной перезагрузкой.
На VBScript примерно так:

Const DOMAIN_JOIN_IF_JOINED = 32
Const NETSETUP_ACCT_DELETE = 2
Set objNetwork = CreateObject("WScript.Network")
strComputer = objNetwork.ComputerName
Set objComputer = GetObject("winmgmts:{impersonationLevel=Impersonate}!\\" & strComputer & "\root\cimv2:Win32_computerSystem.Name='" & strComputer & "'")
intReturn = objComputer.JoinDomainOrWorkgroup(<имя нового домена>, <пароль учётки в правом введения ПК в новый домен>, <учётная запись нового домена с правом введения ПК в домен>,  <organizationalUnit для размещения объекта ПК в новом домене> , JOIN_DOMAIN  + DOMAIN_JOIN_IF_JOINED)
Set objWhs = WScript.CreateObject("WScript.Shell")
objWhs.Run "shutdown /r /t:15"

На 2000-х придётся:

сначала выводить в рабочую группу
перезагружаться
авторизоваться локально с какой-то учётной записью
вводить в новый домен
опять перезагружаться

@Rinoa 25 мар 2013 в 19:26

Во-вторых надо достать newsid. На официальном сайте её удалили, но, как говорится, что попало в интернет…

А вот это разве не она?

@Slipeer 25 мар 2013 в 19:30

Конечно она! ;)
Только попробуйте её скачать с указанной страницы.
Хотя бы ссылку на закачку найдите.

@Rinoa 25 мар 2013 в 19:33

Ого! извиняюсь, не обратил внимание на то, что ссылка неактивна.

@Slipeer 25 мар 2013 в 19:34

Да ничего… одно лучше, чем «минисуют», даже не комментируя.

@NoOne 26 мар 2013 в 03:21

Какой у вас все-таки объем парка машин? Серверов и рабочих мест, чтобы можно было оценить.

@Slipeer 26 мар 2013 в 04:06

>25000 объектов компьютеров в домене.
Пользователей раза в 1,5 -2 больше.

@Baf 26 мар 2013 в 07:08

Паша, ты молодец!

Правильно что взялся это всё описать — это будет как полезно, так и плюс в твою карму работника. Если хочешь, не против могу твой цикл статей разбавить описанием как мы готовили образ для автоматической установки сотен домен контроллеров. Или не стоит? Черновик валяется давно, но его нужно основательно допиливать для «паблика»

Скоро тебя оторвут с руками :)

@Slipeer 26 мар 2013 в 08:00

Боюсь что здесь это никому не нужно…
P.S. И не надо мне ничего отрывать. ;)

@TerAnYu 26 мар 2013 в 13:35

Да и фиг с остальными, кто столкнётся с такой задачей хоть будет знать откуда и как копать (ну по крайней мере в каком направлении), даже если это уже и пережёвано, лишним не будет.
Мне вот интересно как это автоматизировать, ведь лень — двигатель прогресса :)
Даёшь множество статей разных и интресных!

@Slipeer 26 мар 2013 в 13:45

Мне вот интересно как это автоматизировать

Всмысле?
В описанном мною плане всё просто автоматизируется ;)
Или Вы про:

как мы готовили образ для автоматической установки сотен домен контроллеров

?
Это уже нужно Baf пытать — он готовил образ, я и без этого завален работой был.

@TerAnYu 26 мар 2013 в 14:35

Я про «цикл статей разбавить описанием как мы готовили образ для автоматической установки сотен домен контроллеров».

@foxmuldercp 26 мар 2013 в 19:36

на какой версии? в 12м сервере это вроде уже стало попроще с configmgr'ами всякими…

@Slipeer 27 мар 2013 в 04:00

События, о которых идёт речь имели место достаточно давно (более полугода назад). Переходить тогда на AD на 2012-м сервере в таких масштабах было бы очень большой глупостью.

@bugaga0112358 27 мар 2013 в 01:40

Пишите!
Будем ждать =)

@Slipeer 26 мар 2013 в 13:45

промазал

Зарегистрируйтесь на Хабре, чтобы оставить комментарий