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