Должен ли я предоставить свой Active Directory общедоступному Интернету для удаленных пользователей?

У меня есть клиент, рабочая сила которого полностью состоит из удаленных сотрудников, использующих компьютеры и ноутбуки Apple и Windows 7.

В настоящий момент пользователи не проходят аутентификацию на домене, но организация хотела бы двигаться в этом направлении по нескольким причинам. Это машины, принадлежащие компании, и фирма стремится иметь некоторый контроль над деактивацией учетной записи, групповой политикой и легким предотвращением потери данных (отключение удаленного носителя, USB и т. Д.). Они обеспокоены тем, что для доступа к AD требуется аутентификация VPN. было бы громоздко, особенно на пересечении уволенного сотрудника и кэшированных учетных данных на удаленной машине.

Большинство служб в организации основаны на Google (почта, файл, чат и т. Д.), Поэтому единственными доменными службами являются DNS и аутентификация для их Cisco ASA VPN.

Заказчик хотел бы понять, почему недопустимо публично выставлять свои контроллеры домена. Кроме того, то , что является более приемлемой доменной структурой для распределенной удаленной рабочей силы?

Редактировать:

Centrify используется для нескольких клиентов Mac.

Я публикую это как ответ, главным образом потому, что у каждого есть свое «образованное мнение», основанное на опыте, информации третьих лиц, слухах и племенных знаниях в ИТ, но это скорее список цитат и прочтений «напрямую» от Microsoft. Я использовал кавычки, потому что уверен, что они не фильтруют должным образом все мнения, высказанные их сотрудниками, но, тем не менее, это может оказаться полезным, если вам нужны authoritativeссылки непосредственно из Microsoft.

Кстати, я также думаю, что ОЧЕНЬ ЛЕГКО сказать DOMAIN CONTROLLER == ACTIVE DIRECTORY, что не совсем так. Прокси-серверы AD FS и другие средства (аутентификация на основе форм для OWA, EAS и т. Д.) Предлагают способ «выставить» сам AD в Интернете, чтобы позволить клиентам, по крайней мере, попытаться пройти аутентификацию через AD, не раскрывая сами контроллеры домена. Перейти на чьей - то OWA - сайта и попытка входа в систему и AD будут получать запрос на аутентификацию на внутреннем интерфейсе DC, поэтому AD технически «разоблачил» ... но обеспечивается с помощью SSL и прокси через сервер Exchange.

Цитата № 1

Рекомендации по развертыванию Windows Server Active Directory на виртуальных машинах Windows Azure

Прежде чем перейти к "Azure - это не AD" ... вы МОЖЕТЕ развернуть ADDS на виртуальной машине Azure.

Но процитируем соответствующие биты:

Никогда не выставляйте STS напрямую в Интернет.

В целях обеспечения безопасности разместите экземпляры STS за брандмауэром и подключите их к корпоративной сети, чтобы предотвратить доступ к Интернету. Это важно, потому что роль STS выдает токены безопасности. В результате они должны иметь тот же уровень защиты, что и контроллер домена. Если STS скомпрометирован, злоумышленники могут выдать токены доступа, которые могут содержать утверждения их выбора для приложений проверяющей стороны и других STS в доверяющих организациях.

ergo ... не выставляйте контроллеры домена напрямую в интернет.

Цитата № 2

Active Directory - тайна UnicodePwd из AD LDS

Предоставление контроллера домена Интернету обычно является плохой практикой, независимо от того, происходит ли это воздействие непосредственно из производственной среды или через сеть периметра. Естественной альтернативой является размещение сервера Windows Server 2008 с ролью облегченных служб каталогов Active Directory (AD LDS), работающего в демилитаризованной зоне.

Цитата № 3 - не от MS ... но полезно еще заглядывать в будущее

Active Directory как услуга? Azure, Intune намекают на будущее облачного AD

В конце концов, нет отличного «короткого» ответа, который отвечает целям избавления от офиса сервера AD в обмен на альтернативу Azure. В то время как Microsoft удовлетворена тем, что позволяет клиентам размещать доменные службы Active Directory на блоках Server 2012 и 2008 R2 в Azure, их полезность ничем не уступает возможности подключения к VPN, которую вы можете собрать для своего персонала. DirectAccess, будучи очень многообещающей технологией, связывает свои руки из-за своих собственных досадных ограничений.

Цитата № 4

Разверните AD DS или AD FS и Office 365 с помощью единого входа и виртуальных машин Windows Azure.

Контроллеры домена и серверы AD FS никогда не должны быть подключены напрямую к Интернету и должны быть доступны только через VPN

Active Directory (AD) не была разработана для такого развертывания.

Модели угроз, использованные при разработке продукта, предполагают развертывание «за брандмауэром» с некоторым количеством враждебных субъектов, отфильтрованных на границе сети. Несмотря на то, что вы, безусловно, можете усилить защиту Windows Server от публичной сети, для правильной работы Active Directory требуется состояние безопасности, которое явно более слабое, чем у хоста, защищенного для общедоступных сетей. Много услуг , должны быть выставлены от контроллера домена (DC) для AD работать должным образом.

Предложение Zoredache в комментариях, в частности ссылка на что-то вроде OpenVPN, работающего в качестве общесистемной службы с аутентификацией сертификата, может быть просто подходящим. DirectAccess, как уже упоминали другие, это именно то, что вам нужно, за исключением того, что он не имеет кроссплатформенной поддержки, которую вы хотели бы.

В качестве отступления: я поиграл с идеей использования IPSEC в транспортном режиме на основе сертификатов для прямого показа AD в Интернете, но на самом деле у меня никогда не было на это времени. Microsoft внесла изменения в сроки Windows Server 2008 / Vista, которые якобы сделали это возможным, но я никогда не использовал это на практике.

Что все остальные сказали. Я особенно нервничаю по поводу попыток грубой силы, упомянутых Кристофером Карелом. Презентация на последнем Def Con была на тему:

Таким образом, вы думаете, что ваш контроллер домена безопасен?

ДЖУСТИН ХЕНДРИКС ИНЖЕНЕР БЕЗОПАСНОСТИ, MICROSOFT

Контроллеры домена являются жемчужиной организации. Как только они падают, все в домене падает. Организации делают все возможное, чтобы защитить свои контроллеры домена, однако они часто не могут должным образом защитить программное обеспечение, используемое для управления этими серверами.

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

Джастин Хендрикс работает в команде безопасности Office 365, где занимается красной группировкой, тестированием на проникновение, исследованием безопасности, анализом кода и разработкой инструментов.

Я уверен, что вы можете найти много других примеров. Я искал статьи о контроллерах домена и хакерских операциях в надежде получить описание того, как быстро будет найден контроллер домена, и т. Д., Но я думаю, что сейчас это подойдет.

Если вы пытаетесь убедить руководство, хорошим началом будет следующее:

It goes against Microsoft's Best Practices for Active Directory Deployment.

Обновление : см. Эту техническую статью о защите контроллеров домена от атак и раздел под названием Perimeter Firewall Restrictions:

Perimeter firewalls should be configured to block outbound connections
from domain controllers to the Internet. 

И раздел под названием, в Blocking Internet Access for Domain Controllersкотором говорится:

Launching web browsers on domain controllers should be prohibited not only
by policy, but by technical controls, and domain controllers should not be
permitted to access the Internet

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

A gaping hole would be created, possibly resulting in severe data loss and/or loss of company secrets.

Кэшированные учетные данные как раз и кешируются. Они работают на локальном компьютере, когда он не может подключиться к домену , но если эта учетная запись отключена, они не будут работать для любого сетевого ресурса (svn, vpn, smb, fbi, cia и т. Д.), Поэтому им не нужно беспокоиться об этом. , Также помните, что пользователи уже имеют полные права на любые файлы в папке своего профиля на локальном компьютере в любом случае (и, вероятно, на съемном носителе), поэтому отключенные учетные данные или нет они могут делать с этими данными так, как им нравится. Они также не будут работать на локальном компьютере, когда он подключится к сети.

Вы имеете в виду службы, которые предоставляет Active Directory или контроллер домена, например LDAP? Если это так, LDAP часто отключается безопасно для целей проверки подлинности и запросов к каталогам, но простое отключение брандмауэра Windows (или открытие всех необходимых портов для общего доступа - тоже самое в этом примере) может вызвать серьезные проблемы.

AD по-настоящему не управляет компьютерами Mac, поэтому потребуется отдельное решение (например, OS X Server). Вы можете присоединить Mac к домену, но это немного больше, чем авторизация с сетевыми учетными данными, назначение администраторов домена в качестве локальных администраторов на Mac и т. Д. Нет групповой политики. MS пытается выйти на новый уровень с новыми версиями SCCM, которые утверждают, что могут развертывать приложения на компьютерах macs и * nix, но я еще не видел этого в производственной среде. Я также полагаю, что вы можете настроить Mac для подключения к OS X Server, который будет аутентифицироваться в вашем каталоге на основе AD, но я могу ошибаться.

При этом могут быть разработаны некоторые творческие решения, такие как предложение Эвана использовать OpenVPN в качестве службы и отключение сертификата компьютера, если / когда придет время уволить этого сотрудника.

Похоже, все основано на Google, поэтому Google действует как ваш ldap-сервер? Я бы порекомендовал моему клиенту сохранить это, если это вообще возможно. Я не знаю природу вашего бизнеса, но для веб-приложений, таких как git или redmine server, даже когда внутренняя настройка может проходить аутентификацию с OAuth, используя преимущества учетной записи Google.

И, наконец, для такой настройки Roadwarrior практически потребуется VPN для успешной работы. После того, как машины доставлены в офис и настроены (или настроены удаленно с помощью сценария), им необходим способ получения любых изменений в конфигурации.

Макам понадобился бы отдельный подход к управлению в дополнение к VPN, очень жаль, что они больше не делают настоящие Mac-серверы, но у них действительно были некоторые достойные реализации политик в OS X Server в последний раз, когда я проверял (пару лет назад ).

К сожалению, DirectAccess доступен только в Win7 + Enterprise Edition, потому что он создан специально для вашего запроса. Но не зная вашего издания и видя, что у вас MacOS, это не сработает.

/ Edit - похоже, что некоторые сторонние поставщики утверждают, что у них есть клиенты DA для Unices: http://www.centrify.com/blogs/tomkemp/what_is_microsoft_directaccess_and_unix_linux_interoperability.asp

Есть доступные решения MDM, которые могут работать для удовлетворения ваших потребностей; мы катим один из них (MAAS360) клиенту, который находится в аналогичной позиции.

Это, очевидно, будет значительным риском для безопасности. Кроме того, это, вероятно, не сработает так, как вам бы хотелось. Если случайные люди в Интернете могут попытаться войти в вашу среду AD, вероятно, все ваши пользователи будут заблокированы. Навсегда. А снятие требований о блокировке означает, что довольно просто выполнить проверку методом грубой силы для простых паролей.

Что еще более важно, у вас не должно быть проблем с реализацией вашей цели (конечные пользователи входят в ноутбук с учетными данными домена), не делая серверы AD напрямую доступными. А именно, машины Windows могут кэшировать последние X успешных входов в систему, чтобы те же учетные данные работали при отключении. Это означает, что конечные пользователи могут входить в систему и выполнять полезную работу без необходимости прикасаться к вашим серверам AD. Очевидно, что им потребуется использовать VPN для подключения к другим основным корпоративным ресурсам, и они могут одновременно обновлять настройки AD / GPO.

Ewwhite,

Ваш вопрос чрезвычайно актуален и заслуживает тщательного рассмотрения.

Все специалисты по безопасности рекомендуют уровни безопасности перед любым сетевым ресурсом, включая межсетевые экраны SPI, IDS, межсетевые экраны на основе хоста и т. Д. По возможности всегда следует использовать межсетевой экран с прокси-периметральным шлюзом, например ISA (теперь TMG).

Тем не менее, Microsoft Active Directory 2003+ не имеет открытых уязвимостей. Технология LDAP и ее алгоритмы хеширования, как правило, очень безопасны. Возможно, он более безопасен, чем SSL VPN, если этот SSL VPN работает с OpenSSL и уязвим для сердечных приступов.

Я хотел бы предостеречь 5 вещей:

1. Позаботьтесь о других службах, с которыми сталкивается сеть, таких как сервер терминалов, службы DNS, CIFS и особенно IIS с его ужасной защитой.

2. Используйте LDAPS с сертификатом безопасности, чтобы избежать передачи учетных данных домена в виде открытого текста по сети. Это происходит автоматически после установки служб сертификации (используйте отдельную машину для PKI)

3. Поместите анализатор пакетов в интерфейс и следите за своим трафиком, исправляйте любые пароли в виде открытого текста, потому что брандмауэр или нет, если вы не используете VPN или LDAPS, некоторые устаревшие системы будут отправлять пароли в виде открытого текста.

4. Знайте, что атаки MITM могут заставить собственные механизмы аутентификации понижать версию и выставлять пароли для более слабой аутентификации NTLM.

5. Знайте о некоторых уязвимостях перечисления пользователей, которые могут все еще существовать.

Тем не менее, Active Directory имеет большой послужной список в области безопасности. Кроме того, MS Active Directory не хранит пароли, а только хэши, которые также могут снизить степень компрометации.

Вам может быть полезна более прозрачная инфраструктура безопасности, вам не нужно устанавливать специальные DNS-серверы или использовать domain.local, и вы можете использовать свой фактический домен в общедоступном Интернете, например domain.com.

По моему профессиональному мнению, существенное преимущество заключается в публичном развертывании технологий безопасности, таких как Active Directory, где другие технологии, такие как Exchange, DNS и веб-серверы, просто не приносят никакой пользы и всех рисков.

Примечание: если вы развернете Active Directory, он будет включать DNS-сервер. Будьте уверены, чтобы отключить рекурсию на ваших DNS-серверах (по умолчанию включено), или вы будете абсолютно участвовать в атаках типа «отказ в обслуживании».

Ура,

-Брайан

Dell (через покупку Quest (через покупку Vintela)) имеет кроссплатформенное решение, которое часто используется на предприятиях F500 для этой цели .

Что нужно учитывать ...

1. Ваши пользователи всегда на связи? Если это так, то вам лучше всего подойдет гибкая хостинговая среда на основе виртуальных машин, которая может работать, когда множество активных пользователей используют LDAP.
2. Вы работаете в нескольких физических центрах обработки данных? Рассмотрите возможность географической балансировки нагрузки перед службами AD, чтобы уменьшить количество переходов между пользователями и вашими системами.
3. Кроме того, если ответ на вопрос № 2 - да, убедитесь, что вы настроили некоторые выделенные сетевые ресурсы для репликации своего леса, как показано здесь

И убедитесь, что ваше решение брандмауэра способно обрабатывать очень высокие скорости повторной передачи, если у вас есть пользователи на дросселированных восходящих каналах, подключающихся из шумных центров Wi-Fi и т. Д.