С чего и как правильно начинать поэтапную миграцию AD в облако?

Question

[User .]

Добрый день,

Выслушаю мнение и советы людей имеющих опыт работы с AD о том как и конкретно с каких этапов правильно начинать процесс миграции AD в облако.

Comments

[Alexey Dmitriev]

Что значит миграция AD в облако?
Это может быть перенос контроллеров домена в виртуальные машины в облаке, либо все-таки что-то типа Azure AD?

[Kelv13]

Я бы посоветовал начать с конца - оценить тот результат, который должен быть достигнут и уточнить, будет ли это работать в полном объеме и так, как Вам надо.

Очень часто сталкиваюсь с тем, все отлично, намного удобнее, чем раньше, дешевле, недежнее, но одна нужная фича - не работает...

Answer 1

[Вадим Чопоров]

Я бы начал с того, что нужно определить, что вы хотите на выходе? Какие цели вы преследуете? Вы говорите о чем, о возможности авторизоваться, используя ваши доменные аккаунты в облаке/сервисе, или о полноценном переносе AD DS (domain services)? У различных облачных провайдеров различные варианты.
Самый общий ответ, исходя из данных вопроса:
Поднимите VPN туннель, или другим способом постройте сетевую связь с облаком, заведите там контроллер, дождитесь окончания репликации данных, и все, у вас в облаке контроллер вашего домена, с вашей AD.

Comments

[User .]

О полноценном переносе, планируется полностью исключить использование физических контроллеров в организации. Большей информацией я к сожалению не владею.

[Вадим Чопоров]

Если говорим об Azure - Azure AD DS, это сервис который максимально похож на классический AD. Azure AD - это другой продукт, который имеет с классическим AD DS только название и то, что это база юзеров для настройки прав и аутентификации, это важно понимать.
Опять повторю - вам нужно выяснить, для чего нужна миграция в облако, и какой функционал должен быть сохранен в процессе миграции? Если вы решите использовать сервис Azure AD DS, то будьте готовы к тому, что политики вы потеряете, объекты компьтеров так же, забудьте про расширения схемы (здравствуй эксчендж)) ) и т.д. Т.е. как по мне - не стоит юзать это, если вы не поднимаете с нуля свежий домен в Azure (и тут опять же ограничения). Если вы хотите использовать все то же, что и имеете в полноценном онпремном AD, без головной боли, то стоит делать как я и писал выше, просто на машинках облачные контроллеры, и реплицироваться туда.

Answer 2

[Сергей Горностаев]

AD - это не тот сервис, который стоит выносить в облако.

Comments

[User .]

К своему стыду признаюсь что я в AD имею очень скудные познания, но задачу поставил не я а вот решать возможно ее потребуется именно мне), и самое главное что я понятия не имею о технических деталях но тем не менее очень нужно ответить 'да'). Поэтому пробую как всегда разбить мою возможно будущую задачу на более мелкие и попробовать предвидеть/представить возможные проблемы.

Answer 3

[Mnemonic0]

Вам сюда:
https://habr.com/ru/company/microsoft/blog/475738/

Answer 4

[nApoBo3]

Azure AD. Там есть все необходимые мануалы. Но надо понимать, что это не совсем тоже самое, что локальный AD.

Comments

[User .]

В чем именно будет принципиальная разница между физическим сервером?

[nApoBo3]

JavaUser Spring, это разные продукты, например они работают с разным типом аутентификации. Они не являются взаимозаменяемыми.

Answer 5

[Евгений]

Возьмите тестовый тенант в Azure и попробуйте в тестовой среде мигрировать. Будте готовы, что Azure - недоразвитая AD, т.е. там не будет некоторых сервисов, которые есть on-prem. Cкачайте с сайта Microsoft утилиту Adfix и запустите ее. Она Вам покажет узкие места, например, дубликаты аккаунтов.

Answer 6

[Denys Dmytrenko]

Вижу тут несколько варианта подходящих под описание "миграция AD в облако".
1. Достаточно простой. Гибридизация текущей AD, Синк пользователей в Azure AD С помощью Azure AD Connect. При этом вы сохраняете локальные AD DC (как минимум один). С которым и будет синкаться Azure AD тенант.
2. Вариация первого варианта - Сначала выполяем все шаги из п.1, затем убиваем локальный AD и превращаем ваших пользователей в cloud-only. Вуаля, ваша AD теперь "в облаке" - В Azure AD.
3. Другая вариация первого варианта - то что товарищи упоминали выше - поднимаем новый DC виртуалкой в Azure (предварительно построив VPN и пр.), Получаем еще один гибридный вариант. При необходимости убиваем on-premise DC(s).
4. И последний, бонусный вариант:) Миграция в упомянутый выше Azure AD DS. Azure AD. Подробности реализации и его ограничения\возможности - читайте по линке.

Что-то добавить или порекомендовать один невозможно не имея более конкретно сформированных задач\целей.