Установка контроллера домена и Active Directory на Amazon EC2 в качестве основного AD [закрыто]
Я планирую развернуть Active Directory и контроллер домена на AWS для своей компании. Он будет использоваться в основном для следующих целей:
- Авторизация пользователей (процесс входа/выхода)
- Общий доступ к файлам / управление (сотрудники могут обмениваться файлами друг с другом)
- Развертывание GPO (для внедрения некоторых ИТ-политик, например, USB-доступ и т.д.).
В дополнение к этому, сервер будет работать как Sharepoint Server (это означает, что ему понадобится SQL и IIS).
Что я спрашиваю:.... [Please see edit]?
Если это физический сервер, то я бы сделал следующее:
- Купите компьютерный сервер.
- Установить Windows Server (если его еще нет).
- Настроить DHCP/DNS (и все остальные сетевые функции).
- Установка и настройка контроллера домена.
- Установка и настройка Active Directory.
- Настройка и применение GPO по мере необходимости.
И я буду делать все эти вещи, упомянутые выше, либо с физической машины, либо с удаленного подключения.
PS: Да, я знаю о последствиях потери доступа к контроллеру домена (т.е. отключение сети). Одним из способов смягчения этого является развертывание локального хранилища кэша в помещении, я полагаю.
EDIT Мне действительно нужно, чтобы AD/DC управлял логинами, организационной иерархией и политикой (GPO). Похоже, что это обратная сторона большинства настроек сервера. Я бы хотел использовать облачную службу в качестве основного контроллера домена, а в будущем также обеспечить локальную аутентификацию для управления службой печати/файлов (если это возможно).
Но я бы очень хотел узнать, возможно ли это? Более того, является ли это хорошей практикой?
Я не против использовать Amazon или Azure.
Размещение Active Directory (AD) за пределами сайта - это довольно нетипичная конфигурация даже с самыми последними версиями Windows. Вы не найдете много людей, которые рекомендуют его.
С точки зрения безопасности, AD не создавалась с учетом модели угроз прямого доступа к Интернету. Вам понадобится какой-то безопасный туннель от клиентов к контроллеру домена (DC), если вы хотите предотвратить прямое попадание этого DC в Интернет. Это усложнит вашу конфигурацию и, вероятно, несколько затруднит присоединение к домену. (На протяжении многих лет я слышал разговоры об использовании обязательного транспортного режима IPSEC между клиентами и контроллерами домена, но на самом деле я никогда не видел, чтобы кто-нибудь его реализовал. Точно так же DirectAccess должен решить эту проблему.)
Вы » Мы увидим снижение производительности, особенно в отношении приложения групповой политики, по сравнению с наличием локального контроллера домена. Взаимодействие между клиентами и контроллерами домена во время загрузки и входа в систему не требует значительных затрат на полосу пропускания, поскольку состоит из большого количества циклов обмена. Задержка будет убийцей. Внешний хостинг, вероятно, никогда не будет превышать задержку менее 1 мс в локальной сети.
Если у вас есть географически распределенные клиенты, удаленный размещенный AD может быть «выигрышем», если вы сможете заставить его работать. Однако, если ваши клиенты в основном централизованы, я готов поспорить, что ваши долгосрочные расходы будут меньше на размещение AD на месте. Размещение за пределами площадки не устраняет необходимости в резервных копиях, дополнительных контроллерах домена реплик или системном администрировании.
Конечно, если вы делаете что-нибудь существенное с групповой политикой, учет производительности будет "выигрышем" для локального хостинга, если только у вас нет какого-либо соединения со сверхнизкой задержкой к размещенному DC.