У меня есть клиент, сотрудники которого полностью состоят из удаленных сотрудников, использующих компьютеры / ноутбуки Apple и Windows 7.
В настоящий момент пользователи не проходят аутентификацию в домене, но организация хотела бы двигаться в этом направлении по нескольким причинам. Это машины, принадлежащие компании, и компания стремится иметь некоторый контроль над деактивацией учетной записи, групповой политикой и небольшим предотвращением потери данных (отключение удаленных носителей, USB и т. Д.). Они обеспокоены тем, что для доступа к AD требуется проверка подлинности VPN. было бы громоздко, особенно на пересечении уволенного сотрудника и кешированных учетных данных на удаленной машине.
Большинство служб в организации основаны на Google (почта, файлы, чат и т. Д.), Поэтому единственными службами домена являются DNS и аутентификация для их Cisco ASA VPN.
Заказчик хотел бы понять, почему это неприемлемо чтобы сделать контроллеры домена общедоступными. Кроме того, что является более приемлемая доменная структура для распределенной удаленной рабочей силы?
Редактировать:
Центрифуги используется для нескольких клиентов Mac.
Я отправляю это как ответ в основном потому, что у каждого есть свое собственное «образованное мнение», основанное на опыте, информации третьих лиц, слухах и племенных знаниях в ИТ, но это скорее список цитат и прочтений «напрямую» от Microsoft. Я использовал цитаты, потому что уверен, что они не фильтруют должным образом все мнения, высказанные их сотрудниками, но, тем не менее, это должно оказаться полезным, если вам нужно authoritative ссылки прямо из Microsoft.
Кстати, Я также думаю, что ОЧЕНЬ ЛЕГКО сказать DOMAIN CONTROLLER == ACTIVE DIRECTORY, что не совсем так. Прокси-серверы AD FS и другие средства (аутентификация на основе форм для OWA, EAS и т. Д.) Предлагают способ «открыть» саму AD в Интернете, чтобы клиенты могли хотя бы пытаться пройти аутентификацию через AD, не подвергая сами контроллеры домена. Зайдите на чей-нибудь сайт OWA и попытайтесь войти в систему и AD. воля получить запрос на аутентификацию на внутреннем контроллере домена, так что AD технически "открыт" ... но защищен через SSL и проксируется через сервер Exchange.
Рекомендации по развертыванию Windows Server Active Directory на виртуальных машинах Windows Azure
Прежде чем вы начнете «Azure - это не AD» ... вы МОЖЕТЕ развернуть ADDS на виртуальной машине Azure.
Но процитируем соответствующие биты:
Никогда не открывайте STS напрямую в Интернете.
В целях безопасности разместите экземпляры STS за брандмауэром и подключите их к корпоративной сети, чтобы предотвратить выход в Интернет. Это важно, потому что роль STS выдает маркеры безопасности. В следствии, к ним следует относиться с таким же уровнем защиты, что и к контроллеру домена. Если STS скомпрометирован, злоумышленники могут выдавать токены доступа, потенциально содержащие утверждения по их выбору, приложениям проверяющей стороны и другим STS в доверяющих организациях.
эрго ... не открывайте контроллеры домена напрямую в Интернет.
Active Directory - Тайна UnicodePwd AD LDS
Предоставление доступа к контроллеру домена через Интернет обычно является плохой практикой, независимо от того, идет ли это воздействие напрямую из производственной среды или через сеть периметра. Естественной альтернативой является размещение сервера Windows Server 2008 с ролью служб Active Directory облегченного доступа к каталогам (AD LDS) в сети периметра.
Active Directory-как-услуга? Azure, Intune намекают на будущее AD в облаке
В конце концов, не существует отличного «короткого» ответа, который отвечал бы целям избавления офиса от сервера AD в обмен на альтернативу Azure. В то время как Microsoft благодушно разрешает клиентам размещать доменные службы Active Directory на серверах Server 2012 и 2008 R2 в Azure, их полезность настолько хороша, насколько хорошо вы можете подключиться к VPN для своих сотрудников. DirectAccess, хотя и является очень многообещающей технологией, имеет свои собственные досадные ограничения.
Развертывание 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, где он участвует в красной команде, тестировании на проникновение, исследованиях безопасности, проверке кода и разработке инструментов.
Я уверен, что вы можете найти множество других примеров. Я искал статьи о контроллерах домена и взломе в надежде получить описание того, как быстро будет найден DC и т. Д., Но я думаю, что пока этого достаточно.
Если вы пытаетесь убедить руководство, хорошим началом будет следующее:
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, которые утверждают, что могут развертывать приложения на компьютерах Mac и * nix, но я еще не видел этого в производственной среде. Я также считаю, что вы можете настроить Mac для подключения к OS X Server, который будет аутентифицироваться в вашем каталоге на основе AD, но я могу ошибаться.
При этом могут быть разработаны некоторые творческие решения, такие как предложение Эвана об использовании OpenVPN в качестве услуги и отключение сертификата машины, если / когда придет время отпустить этого сотрудника.
Похоже, что все основано на Google, так что Google действует как ваш ldap-сервер? Я бы порекомендовал своему клиенту сохранить это, если это вообще возможно. Я не знаю характера вашего бизнеса, но для веб-приложений, таких как сервер git или redmine, даже при внутренней настройке можно выполнить аутентификацию с помощью 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 и уязвим для Heartbleed.
Я бы предостерегал 5 вещей:
Будьте обеспокоены другими службами, которые обращаются к сети, такими как сервер терминалов, службы DNS, CIFS и особенно IIS с его ужасными показателями безопасности.
Используйте LDAPS с сертификатом безопасности, чтобы избежать передачи учетных данных домена в открытом виде по сети. Это происходит автоматически после установки служб сертификации (используйте отдельный компьютер для PKI).
Поместите анализатор пакетов на интерфейс и наблюдайте за своим трафиком, исправляйте любые пароли в открытом виде, независимо от того, используется брандмауэр или нет, если вы не используете VPN или LDAPS, некоторые устаревшие системы будут отправлять пароли в открытом виде.
Знайте, что атаки MITM могут заставить собственные механизмы аутентификации перейти на более раннюю версию и раскрыть пароли для более слабой аутентификации NTLM.
Помните о некоторых уязвимостях перечисления пользователей, которые все еще могут существовать.
Тем не менее, Active Directory имеет отличный послужной список в области безопасности. Кроме того, MS Active Directory не хранит пароли, только хэши, которые также могут снизить серьезность взлома.
Вы можете воспользоваться более простой инфраструктурой безопасности, вам не нужно устанавливать специальные DNS-серверы или использовать domain.local, и вы можете использовать свой фактический домен в общедоступном Интернете, например domain.com.
По моему профессиональному мнению, публичное развертывание технологий безопасности, таких как Active Directory, дает существенные преимущества, тогда как другие технологии, такие как Exchange, DNS и веб-серверы, просто не приносят никакой пользы и несут весь риск.
Примечание: если вы развернете Active Directory, он будет включать DNS-сервер. ОБЯЗАТЕЛЬНО отключите рекурсию на своих DNS-серверах (по умолчанию включено), иначе вы обязательно будете участвовать в атаках типа «отказ в обслуживании».
Привет,
-Брайан
Dell (через покупку Quest (через покупку Vintela)) имеет кроссплатформенное решение, которое часто развертывается на предприятиях F500 для эта явная цель.
Что нужно учитывать ...
И убедитесь, что ваш брандмауэр способен обрабатывать чрезвычайно высокие скорости повторной передачи, если у вас есть пользователи на ограниченных восходящих каналах, подключаясь из шумных центров Wi-Fi и т. Д.