Active Directory в облаке и филиалы через VPN?



@vittmann

Привествую!

Суть. Планирую развертывание AD для компании.

  • Основное требование к AD – аутентификация, т.к. основной парк машин это MacOS.
  • Процент машин на Windows в будущем может вырасти (сейчас минимален), соотвественно, может появится необходимость в GPO (но не в ближайшем будущем). Обеспечение локального входа на машины.
  • Также синхронизация юзеров/груп в MDM-систему (управление маками) + интеграция с IdM (для входа тем же кредами на веб ресурсы) + плюс еще ряд систем, которые могут интегрироваться с LDAP/AD. Всяких сетевых шар не планируется.

Пока филиалы – это офисы в том же городе (3 шт, общее кол-во юзеров, работающих одновременно, до 250 человек) ,с хорошими каналами связи (до 500Mбит/c в обе стороны) и дублированием провайдеров.
Кроме того ,есть удаленщики и рассматривается ввод в домен техники, за которой они работают (в основном, корпоративные ноуты). Таких еще может набраться до 100 одновременно работающих юзеров.
В будущем планируется открытие филиалов в других городах (потенциально – в других странах, Европа, к примеру). Но откровенно плохих каналов не будет, ибо в целом для работы офиса нужна хорошая связь.

Пришла идея развернуть AD в облаке (VMware Cloud, дата-центр в том же городе что и филиалы) на 2х виртуализированных DC. Канал 100/50 (страна/мир.) Доступ организовать путем создания VPN с каждого Mikrotik на филиале до виртуального маршрутизатора в облаке (а дальше маршрутизировать его до сети с домен контроллерами). Собственно, пришла она из-за отсутствия желания покупать в каждый офис железо под DC и лицензию на WinServer.

На каждом филиале клиентам по DHCP отдавать в качестве DNS ip адреса контроллеров + ip самого микротика (что бы пережить без неудобств те моменты, когда/если VPN падает-тупит и не доступен основной DNS. Рабочие станции тогда будут юзать DNS Mikrotik-а). На самих машинах создавать мобильную учетную запись каждому юзеру (для кеширования креденшиалов и возможности залогиниться на машину, даже если связь с AD на данный момент нарушена).

Как правило, в любой доке/книге про AD обязательно упоминается, что мол-де при распределенной территориально/географически структуре предприятия надо обязательно ставить в каждом филиале свой DC (в, основном, в контексте того, что wan канал он тонкий и вообще нестабильный). Т.е. эта идея явно не следует рекомендациям MS.

  • Насколько это сейчас эта рекомендация имеет ту же ценность, когда каналы и широкие и стабильные и вообще никто не мешает иметь по 2-3 штуки в офисе и автопереключение, при падении любого из них?
  • Какой объем трафика примерно генерируется при обращении к контроллеру домена при авторизации? Надо бы закладывать пиковые моменты (утром все пришли и активно логинятся на машины), да как его высчитать?
  • Какие вообще требования к производительности серверов DC в зависимоси от кол-ва юзеров?
  • Может ли помочь приоритезация трафика и DNS, может и по портам, через которые клиентские машины обращаются к DC? (но вероятно после установления соединения могут обратные коннекшены от DC к рабочим станциям будут на рандомные порты, тут не приоритезируешь)
  • Насколько вообще идея не размещать контроллеры в филиалах жизнеспособна? Есть еще подводные камни?


Решения вопроса 0


Ответы на вопрос 2



@SignFinder

Нормальный план – замечаний нет.
К вопросам:
1. Рекомендации размещения DC в каждом филиале устаревшие. Им следуют в основном в в двух случаях – при нестабильном канале и при наличии важных и работающих 24 часа в сутки сервисах, которым нужна AD – фабрики и т.п.
Для примера – один из бывших проектов, которыми занимался – транснациональная корпорация. Имеет по 2 DC в Франкфурте и ЮАР, которые накрывают собой все офисы в паре десятков стран на всем африканском континенте.
2. Трафик к контроллерам небольшой, 250 человек наверно мегабит в 5 влезут в пике. Репликация у вас будет в датацентре – так что этого трафика во внешних каналах не будет.
3. Для DC обычно хорошим тоном считается иметь достаточно ОЗУ, чтобы разместить ntds.dit весь в ОЗУ.
Вам хватит 4-8GB ОЗУ и каких-то core i3.
4. Приоритетизация по умолчанию не нужна.



@elbrus56

Тенденция последних лет – это использование ADDS только для хранения каталога. Вовсе не обязательно заворачивать на него аутентификацию и заставлять устройства быть привязанными к домену, сейчас это решается с помощью Azure AD, Okta, Cisco Duo + MDM, которые также позволят настроить вам Federation к другим веб-службам. То, что вы пытаетесь реализовать – задача, которая в итоге была решена именно этими сервисами.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *