Ситуация, с которой я столкнулся, такова: мы планируем использовать ряд серверных приложений, размещенных на машинах Amazon EC2, в основном Microsoft Team Foundation Server. Эти службы сильно зависят от Active Directory. Поскольку наши серверы находятся в облаке Amazon, само собой разумеется (но я буду), что все наши пользователи удалены.
Похоже, что мы не можем настроить VPN на нашем экземпляре EC2, поэтому пользователям придется присоединиться к домену непосредственно через Интернет, тогда они смогут пройти аутентификацию и после аутентификации использовать этот токен для доступа к таким ресурсам, как TFS. .
на экземпляре DC я могу закрыть все порты, кроме тех, которые необходимы для присоединения / аутентификации к домену. Я также могу отфильтровать IP-адрес на этой машине только по тем адресам, по которым, как мы ожидаем, будут находиться наши пользователи (это небольшая группа)
Я полагаю, что на серверах веб-приложений все, что нам нужно открыть, это порт 80 (или 8080 в случае TFS).
Одна из проблем, с которой я столкнулся, заключается в том, какое доменное имя использовать для этого Active Directory. Должен ли я выбрать "ourDomainName.com" или "OurDomainName.local". Если я выберу последнее, это не означает, что мне придется заставить всех наших пользователей изменить свой DNS-адрес, чтобы он указывал на наш сервер, чтобы он мог разрешить доменное имя (думаю, я мог бы также распространить файл хоста)
Возможно, есть еще одна альтернатива, которую я полностью упускаю.
У вас есть две ортогональные проблемы.
re: naming - я бы никогда не назвал доменное имя Active Directory после вашего домена второго уровня (например, "OurDomainName.com"). Здесь это было предметом религиозных споров, о которых вы можете узнать по адресу:
Я бы не стал использовать ".local" (хотя Microsoft делает - ".local" имеет "багаж", связанный с ним из-за протокола ZeroConf).
Лично я использую соглашение «ad.domain.com». Предполагая, что вы делегируете DNS для поддомена «ad» DNS-серверу, работающему на ваших контроллерах домена, вы можете без проблем сосуществовать с пространством имен AD с открытым пространством имен DNS.
re: security - вы можете рассмотреть возможность использования политики IPSEC на ваших контроллерах домена, если не на всех компьютерах, входящих в ваш домен, для аутентификации и шифрования связи между вашими клиентскими компьютерами и контроллерами домена. Первоначально присоединиться к домену будет несколько сложно, но определенно возможно. Если ваши клиенты работают на базе Windows 7, вы, вероятно, могли бы использовать новый Автономное присоединение к домену функционал, чтобы сделать это еще проще.