доверительные отношения между доменами в разных сетях
Доверять или не доверять?
Домены, леса и опасность доверительных отношений
Доверительные отношения — эффективный способ ограничить число учетных записей и реализовать единую процедуру регистрации (single sign-on — SSO) в лесах Active Directory (AD), доменах Windows NT и AD и даже в областях Kerberos на платформах, отличных от Windows. Но за доверие приходится платить. В лесу с доменами, связанными отношениями доверия, есть где развернуться недобросовестным администраторам, а физически уязвимые контроллеры домена (DC) представляют собой угрозу для всего леса. В данной статье рассматриваются основы доверительных отношений и потенциальные опасности, связанные с такими отношениями. Затем объясняется, как снизить риск для различных типов доверительных отношений, применяемых в современных системах Windows Server 2003 и Windows 2000.
Оптимальный уровень разделения
Существует много вариантов высокоуровневой организации AD (структурного деления на леса и домены). Одно из ключевых требований к высокоуровневой структуре AD — обеспечить оптимальное разделение между различными частями организации. В идеальном случае организация представляет собой единый лес с одним или несколькими доменами. Если AD реализована как единый лес, то пользователи получают ясную картину сети, и каждый из них может иметь единственную учетную запись. Одновременно лес можно разделить на несколько доменов, чтобы выделить различные группы администраторов или пользователей.
К сожалению, по разным причинам в организации часто оказывается несколько лесов. Если одна компания приобретает другую или две компании объединяются, часто возникает сеть с двумя лесами. Некоторые администраторы считают, что домены в лесу не обеспечивают достаточного разделения административных полномочий, поэтому формируют несколько лесов. Иногда необходимость структуры со многими лесами диктуется требованиями отраслевых стандартов или закона.
Простой вопрос доверия
Рассмотрим простейший вариант доверительных отношений: односторонние нетранзитивные отношения между двумя доменами. Домен A доверяет домену Б, но домен A не доверяет любому домену, которому доверяет домен Б. На рис. 1 показана сравнительная картина нетранзитивных и транзитивных отношений. О проблеме безопасности при различных видах доверительных отношений рассказано во врезке «Типы доверительных отношений». Что происходит, если домен A доверяет домену Б? Кому в действительности доверяет домен A? Получают ли пользователи домена Б автоматический доступ к ресурсам домена A? Имеют ли администраторы домена Б права доступа к домену A?
 |
| Рисунок 1. Транзитивные и нетранзитивные доверительные отношения |
Прежде всего, выясним, что происходит при доверительных отношениях? В данном случае домен A — доверяющий (trusting), а домен Б — доверенный (trusted). Для домена A направление доверительных отношений — исходящее. Компьютеры в домене A доверяют контроллерам домена в домене Б, которые аутентифицируют учетные записи пользователей и компьютеров, и определяют членство в группах. Если администратор в домене A открывает список управления доступом (ACL) файла или папки и выбирает новые учетные записи и группы, чтобы добавить их в ACL, то администратор видит учетные записи и группы как домена Б, так и домена A. Администратор может сделать учетные записи и группы домена Б членами групп домена A, и в целом может использовать учетные записи и группы домена Б всюду, где применимы учетные записи и группы домена A. Пользователи домена Б могут обращаться к ресурсам в домене A, для которых у них имеются соответствующие полномочия.
Кому в действительности доверяет домен A? Пользователям домена Б? Администраторам домена Б? Если установлены доверительные отношения, в соответствии с которыми домен A доверяет домену Б, то, очевидно, желательно, чтобы пользователи домена Б получили доступ к определенным ресурсам домена A. Доступ можно обеспечить, предоставив соответствующие полномочия группам домена Б после установления доверительных отношений. Но получат ли администраторы домена Б дополнительные права в домене A? Очевидный ответ — администраторы домена Б получают такие же права доступа, как и другие пользователи домена Б, за исключением права добавлять и удалять пользователей групп домена Б, имеющих доступ к ресурсам домена A. Другими словами, если администратор домена A предоставляет какие-нибудь права доступа группе домена Б, то администратор домена Б может предоставить или отменить эти права для пользователей домена Б, просто изменив членство в группе домена Б. Поэтому на первый взгляд доверительные отношения не несут серьезной опасности. Однако у администраторов домена Б есть документированный способ незаконно получить административный доступ к домену A. Этот способ будет описан в следующем разделе.
Подводные камни доверительных отношений
Одна из опасностей отношений доверия с другим доменом связана с управлением разрешениями в ситуациях, когда необходимо предоставить всем пользователям домена доступ к определенному ресурсу. Часто для этой цели используется группа Everyone или Authenticated Users. Однако состав группы Authenticated Users изменяется при добавлении доверенного домена. Если домен A не доверяет ни одному другому домену, то в группу Authenticated Users входят только пользователи домена A; если разрешения на доступ к объектам заданы на автономных серверах и рабочих станциях — то локальные пользователи этих компьютеров. Но если домен A доверяет домену Б, то группа Authenticated Users автоматически расширяется и охватывает всех пользователей домена Б. Поэтому любые файлы и другие объекты, в ACL которых есть записи, предоставляющие доступ группе Authenticated Users, становятся доступными и пользователям домена Б. Если доверие домена A домену Б транзитивное, то доверительные отношения распространяются на пользователей всех доменов, которым доверяет домен Б.
В зависимости от типа доверительных отношений, Windows может использовать Kerberos или NT LAN Manager (NTLM) в качестве протокола аутентификации для обработки запросов регистрации между двумя доменами. Проанализировать пакеты и разгадать пароли пользователей можно с помощью любого протокола, но расшифровать информацию NTLM проще и быстрее. Наиболее уязвимые места NTLM можно защитить, если внедрить стандарт NTLMv2 на всех DC и рабочих станциях в доверенном домене и на всех компьютерах в доверяющем домене, но Kerberos все равно надежнее.
Устранить технические препятствия значительно проще, чем главную опасность доверительных отношений с другим доменом: доверие к администраторам другого домена. Если домен A доверяет домену Б, то администраторы домена Б должны выполнять свою работу профессионально и честно. Если домен Б подвергся нападению, то под угрозой оказываются все ресурсы домена A, доступные домену Б. Например, предположим, что Боб имеет учетную запись в домене Б и доступ к важной базе данных в домене A. Если взломщик попытается разгадать пароль Боба путем повторных попыток регистрации, то уровень надежности политики блокировки домена A не имеет значения, и преградой для доступа взломщика к базе данных в домене A служит лишь политика блокировки домена Б. Кроме того, только администраторы домена Б могут обнаружить неудачные попытки регистрации в журнале безопасности контроллера домена. Хотя, если взломщик напрямую атакует один из компьютеров домена A с учетной записью Боба, то неудачные попытки локальной регистрации будут отражены в журнале безопасности атакуемого компьютера. Поэтому, если администраторы в доверенном домене не смогут защитить свои учетные записи, отслеживать попытки несанкционированного доступа или уязвимые места, своевременно устанавливать исправления или принимать другие меры обеспечения безопасности, то доверяющий домен (по крайней мере, его ресурсы, доступные пользователям доверенного домена) подвергается такой же опасности, как домен, которому он доверяет.
Кроме того, всегда существует опасность присутствия непорядочного администратора в доверенном домене. Администраторы могут манипулировать учетными записями и группами по-разному, в том числе действовать от лица пользователя, которому был предоставлен доступ. Конечно, та же опасность существует и внутри доверяющего домена. Поэтому, отвечая на вопрос, можно ли доверять другому домену, следует спросить себя, заслуживают ли доверия администраторы того домена. Однако альтернатива доверительным отношениям между доменами, пользователям которых необходимо предоставить доступ к ресурсам, также не лишена риска. Если не доверять домену, то нужно создать учетные записи для его пользователей. Можно быть уверенным, что эти учетные записи защищены в соответствии с требованиями, действующими внутри домена. Однако нужно предусмотреть меры на случай увольнения или изменения служебных обязанностей пользователей — а может быть, у администраторов домена, с которым установлены отношения доверия, больше возможностей блокировать учетные записи и менять членство в группах при должностных изменениях?
Еще одна опасность заключается в том, что доверенные DC не только аутентифицируют пользователей, но и предоставляют доверяющим DC информацию о членстве в группах. Внутри леса DC доверяет всем SID, назначенным пользователю доверенным DC. Поэтому злоумышленник-администратор в домене Б (при наличии достаточной квалификации и программы, составленной умелым хакером), может заставить DC в домене Б указать, что администратор домена Б принадлежит к группе Administrators домена A, и домен A предоставит ему административные полномочия (см. «Facts about Directory Structures and Directory Structure Owners» в «Design Considerations for Delegation of Administration in Active Directory» по адресу http://www.microsoft.com/ windows2000/docs/addeladmin.doc).
Взломщик мог воспользоваться этим уязвимым местом при доверительных отношениях любого типа. В ответ на угрозу разработчики Microsoft дополнили все версии Windows функцией фильтрации SID. В режиме фильтрации SID доверяющий DC анализирует SID, поступающие от доверенного DC, и отфильтровывает те из них, которые соответствуют учетным записям и группам вне доверенного домена. Однако фильтрация SID невозможна между доменами внутри одного леса, так как нарушает репликацию.
Администратор доверяющего домена должен применить фильтрацию SID к домену, которому он доверяет. Например, с помощью следующей команды Netdom можно фильтровать SID из домена Jonescorp:
C:winnt>netdom /filtersids yes
jonescorp
Доверяй, но проверяй
Каким образом можно уменьшить опасность того, что доверенный администратор-злоумышленник вставит SID внутри леса? На первый взгляд единственное решение — создать отдельный лес для каждого домена. Допустим, Acme — международная компания со штаб-квартирой в США и офисами по всему миру. Доменами в лесу Acme управляют администраторы американских и иностранных офисов. Acme также выполняет секретные заказы правительства США, доступ к которым для иностранных граждан запрещен. Если просто перенести секретные ресурсы в «секретный» домен в лесу Acme, есть опасность, что доступ к ним получат иностранцы с административными полномочиями в других доменах леса. Безусловно, реальное и самое концептуально простое решение — создать отдельный «секретный» лес.
Однако у Acme есть другой выход, который позволит сохранить преимущества единственного леса. Лишь немногие пользователи доменов AD действительно нуждаются в административных полномочиях. Высокодетализированная модель безопасности AD позволяет делегировать фрагменты административных полномочий в соответствии с потребностями конкретного предприятия. Если уделить время идентификации различных ролей в ИТ-подразделении и разобраться в механизме делегирования AD, то можно организовать домены так, чтобы для повседневного администрирования никто не регистрировался в качестве членов групп Administrators, Domain Admins, Enterprise Admins или Schema Admins. Детализированное делегирование полномочий AD позволяет снизить остроту проблемы администраторов-злоумышленников, допуская в число членов групп Administrators, Domain Admins, Enterprise Admins и Schema Admins только граждан США. Благодаря такой мере иностранный сотрудник ИТ-подразделения не сможет вставить SID внутри леса.
Однако ограничение административных полномочий препятствует лишь одному из двух возможных способов вставки SID внутри леса. Другой метод состоит в физическом доступе. Лицо, которое получает физический доступ к DC, может изменить системные файлы при отключенной системе Windows. Физическая уязвимость представляет более сложную проблему для такой компании, как Acme, поскольку ей необходимо устанавливать DC за рубежом для обслуживания производственной деятельности. Единственный способ защититься от вставки SID внутри леса в результате физического проникновения злоумышленника — полностью удалить секретный домен из основного леса. Для связи между пользователями в секретном домене и остальной компанией можно организовать внешние доверительные отношения между специальными доменами основного и секретного лесов (рис. 2). Чтобы компенсировать отсутствие единого, унифицированного глобального каталога (Global Catalog — GC), можно задействовать Microsoft Identity Integration Server (MIIS), который публикует данные пользователей одного леса как объекты «контакт» в другом лесу.
 Пояснения. Пунктирными линиями показано, как администратор-злоумышленник присваивает административные полномочия в других доверяющих доменах в том же лесу. На диаграмме также показан другой доверенный лес и внешний домен, связанный доверительными отношениями непосредственно с доменом администратора-злоумышленника. Знак показывает, что администратор-злоумышленник не может присвоить административные полномочия в этих доменах. |
| Рисунок 2. Возможности доступа администратора- злоумышленника в доверяющих доменах |
Домены Windows 2003 и Windows 2000 — не такая непреодолимая граница административных полномочий, как в NT. Роль административной границы в AD отведена лесу. Следование принципу минимальных полномочий и ограничение административных прав могут существенно уменьшить опасность вставки SID внутри леса, но не устранить ее полностью. Нежелательно строить несколько лесов, так как это неудобно для пользователей и создает дополнительную работу для администраторов, которые должны предоставить пользователям унифицированный каталог. Помочь в этом могут такие инструменты, как MIIS. Проектирование лесов и доменов для организации связано с поиском баланса между удобством использования и риском при управлении.
Типы доверительных отношений
Внутри леса можно установить доверительные отношения родитель-потомок (parent-child), дерево-корень (tree-root) или с помощью указателей (shortcut). Все доверительные отношения внутри леса являются двусторонними и транзитивными. Указательные отношения могут быть односторонними, но они не влияют на безопасность. Принимая решение о создании домена внутри леса, следует учитывать несколько факторов. Все домены в лесу доверяют друг другу, поэтому в новом домене должны быть реализованы минимальные меры безопасности, соответствующие уровню остального леса. Кроме того, по умолчанию все домены относятся к ведению группы Administrators корневого домена леса в силу полномочий, по умолчанию назначаемых группе Enterprise Admins. Следует ли оставить в силе эти полномочия, учитывая особенности ресурсов нового домена? И наконец, хотя официально у администраторов одного домена нет полномочий в других доменах леса, в Active Directory (AD) есть уязвимое место, через которое администраторы одного домена потенциально могут получить административные полномочия в другом. Отдельные подразделения некоторых компаний (например, выполняющие секретные правительственные заказы) должны быть строго недоступны для других администраторов. Для секретного подразделения можно организовать отдельный лес, вместо того чтобы строить отдельный домен в том же лесу.
Внешние, лесные и областные (realm) доверительные отношения расширяют сферу доверия за пределы леса. Внешние связи позволяют установить одностороннее и двухстороннее доверие с доменом в другом лесу или унаследованным доменом Windows NT 4.0. Внешние доверительные отношения нетранзитивны (ограничены двумя доменами, напрямую связанными друг с другом). Внешние отношения ограничены сравнительно ненадежным протоколом аутентификации NT LAN Manager (NTLM), но уровень защиты от анализа пакетов и разгадывания пароля можно повысить, если использовать NTLMv2 вместо NTLM для настройки конфигурации контроллеров домена и клиентских компьютеров в доверенном домене и DC и серверов — в доверяющем домене. Доверяющие домены уязвимы для манипуляций с SID администраторами доверяемого домена. Если фильтрация SID не активизирована, то администратор доверенного домена может вставлять фальшивые SID в свойство предыстории SID учетной записи, которое соответствует SID группы (например, Administrators, Domain Admins и Enterprise Admins) леса доверяющего домена. Если для доверительного отношения активизирована SID-фильтрация, то доверяющий DC фильтрует фальшивые SID, получаемые в составе запросов аутентификации из доверенного домена.
Доверительные отношения между лесами — новшество лесов в Windows Server 2003. Двусторонние доверительные отношения между лесами Windows 2003 расширяют изначальное доверие, обычно существующее между всеми доменами в лесу, распространяя его на оба леса. Одностороннее доверие между лесами означает, что все домены в доверяющем лесу доверяют всем доменам в доверенном лесу, но не наоборот. Лесные доверительные отношения поддерживают как NTLM, так и Kerberos, поэтому вновь возникает потребность в реализации NTLMv2 между двумя участниками доверительных отношений. Лесные доверительные отношения уязвимы к тем же манипуляциям с SID, что и внешние домены, поэтому следует активизировать фильтрацию SID. Посредством доверительных отношений между лесами можно добиться одинакового уровня доверия между всеми доменами двух лесов, не опасаясь кражи административных полномочий одного домена администраторами второго домена в другом, доверенном лесу.
Однако домены, соединенные межлесными доверительными отношениями, не разделяют двух ресурсов AD, общих для всех доменов леса: Global Catalog (GC) и схемы. Изменения схемы в одном лесу не выходят за границу леса. В большинстве случаев это не представляет серьезной проблемы, так как при необходимости можно просто соответствующим образом изменить схему другого леса. Труднее компенсировать отсутствие единого, унифицированного GC. Именно благодаря GC границы домена прозрачны для пользователей, которым нужно найти других пользователей, группы рассылки, серверы и другие ресурсы. Если организация разделена на несколько лесов, то пользователи должны знать границы лесов, а также пользователей, подразделения и ресурсы, принадлежащие конкретным лесам. Для восстановления прозрачности в среде со многими лесами можно синхронизировать объекты между лесами с помощью бесплатного пакета Microsoft Identity Integration Server (MIIS) Feature Pack for Windows Server Active Directory. Например, если есть два леса, A и Б, то можно установить MIIS Feature Pack, чтобы опубликовать учетные записи пользователей леса A в качестве контактов в лесу Б и учетные записи пользователей леса Б в качестве контактов леса A. В результате пользователи смогут отыскать друг друга и общаться через Microsoft Exchange Server.
Редактор Windows IT Pro и ведущий инструктор и разработчик курсов для программы по безопасности Windows NT/2000 института MIS Training. Его компания, Monterey Technology Group, занимается консалтингом в области информационной безопасности. Связаться с ним можно по адресу: rsmith@monterey techgroup.com
Поделитесь материалом с коллегами и друзьями
Доверительные отношения между доменами в разных сетях
Доверительные отношения между доменами нужны для предоставления доступа другим организациям к ресурсам вашей сети. Подробную информацию о довериях вы можете получить в библиотеке Microsoft. На русском языке.
Тестовый стенд:
— Хостовой сервер: Intel i7 4700, 32 GB RAM, AMD R7 200, Windows 10 1803 + Hyper-V
— VM1, Intel i7 4700 x2, 4 GB RAM, Windows Server 2016, exonix.ru
— VM2, Intel i7 4700 x2, 4 GB RAM. Windows Server 2008 R2, beta.com
BETA.COM
EXONIX.RU
Для того, чтобы клиенты разрешали доменные имена доверенного домена, необходимо или делегировать ДНС-зону для ДНС сервера в доверенном домене и затем подключить зону как «stub» или «secondary» или использовать «Условные пересылки». Я буду использовать условные пересылки. На WS 2016 добавим условную пересылку с помощью PowerShell:
На WS 2008 R2 добавляем условную пересылку в оснастке DNS:
После этого на серверах добавятся нетранзитивные двухсторонние доверительные отношение.
Нетранзитивные отношения означают доверия только между двумя доменами. Если в лесу exonix.ru будет создан ещё один домен, например, alpha.de, то доверий между beta.com и alpha.deне будет. Доменная аутентификация означает, что все пользователи будут доступны для поиска и аутентификации в доверенном домене.
Другой вариант доверий. Односторонние, выборочные (Selective): exonix.ru доверяет beta.com. Данные доверия требуются, когда домен beta.com является доменом-бастионом для домена exonix.ru:
В домене exonix.ru появится возможность предоставлять доступ пользователям домена beta.com:
В обратном направлении такого не будет:
17.11.2012
новая статья 03.06.2018
Как мы уже знаем из предыдущих тем, домен является границей доступа к ресурсам в организации. Любой пользователь имея соответствующие разрешения может обращается к любому общедоступному ресурсу в том же самом домене. Но как быть когда у нас на предприятии или фирме по тем или иным причинам имеются несколько доменов. Что бы получить доступ к ресурсам которые находятся за пределами родного домена используются так называемые «доверительные отношения» службы Active Directory.
Доверительные отношения ( trusts ) представляют собой опознавательную (узнаваемую, знакомую) связь между двумя доменами, с помощью которой участники безопасности (пользователи, компьютеры) могут получать полномочия на доступ к ресурсам, расположенным на другом домене. То есть это такая связь (такие отношения) которые позволяют пользователям одного домена аутентифицироваться без проверки контролером другого домена.
Примечание. Под понятием аутентификации надо понимать – «кто ты такой?», которая в сети принимает форму предоставления логина и пароля. В отличие от аутентификации понятие «авторизации» это те права, которые, к примеру, предоставлены определенному пользователю на тот или иной объект (допустим на какой-то файл – только чтение).
Итак вернемся к «доверительным отношениям». Когда идет речь о доверительных отношениях, надо понимать что в данном процессе участвуют два домена так названые «доверяющий» и «доверяемый», смотрите рисунок 1.
В таблице 1 перечислены характеристики доверительных отношений.
В Windows Server 2003 Active Directory поддерживает следующие формы доверительных отношений.
Корневое доверительное отношение ( tree – root trust ).
Такие доверительные отношения устанавливаются неявно, то есть автоматически в случае, когда в лесе вводится новый корневой домен дерева. Рассмотрим пример на рисунке 2.
Такого типа отношения устанавливаются при добавление в дереве нового дочернего домена. Этот тип отношений так же устанавливаются неявно, то есть автоматически (по умолчанию). Если вернутся к рисунку 2 то такие отношения будут создаваться когда в общее пространство имен, к примеру дерева xu.com добавляется домен (дочерний) africa.xu.com или при добавление домена office.xu.com. Непосредственно в момент установки дочернего домена AD автоматически создает доверительные отношения между устанавливаемым доменом и доменом родителем, в нашем случае корневым доменом дерева если брать поддомен africa.xu.com. Таким образом вводимый в состав дерева домен оказывается в доверительных отношениях со всеми остальными доменами этого дерева.
Сокращенное доверительное отношение (shortcut trust).
Данный тип отношений явно устанавливается сетевыми админами. Данный тип отношений необходим в случаях когда нужно повысить скорость или скажем оперативность регистрации пользователей, которая допустим в случае логической удаленности двух доменов в рамках иерархии леса или дерева значительно замедлена.
Данный тип отношений характеризуется транзитивностью.
В отношении направленности то они могут быть как односторонним так и двухсторонним. какую направленность придать связи решает непосредственно сетевой администратор, исходя из существующих реалий.
Внешние доверительные отношения (external trust).
Данный тип отношений устанавливается явно. То есть мы своими ручками это делает. Применяется в случаях когда необходимо устанавливать связи между доменами принадлежащих к различным лесам. Или в случаях между доменами Windows Server 2003 и доменом Windows NT. Так же применяются когда необходимо установить доверительные отношения между лесами в Windows Server 2003 но когда леса вернее один из лесов или оба не находится на функциональном уровне Windows Server 2003. ( С уровнями или функциональными режимами домена или леса можете ознакомится тут)
Характеризуется одно или двухсторонними направленностью. Нетранзитивно.
Доверительные отношениями между лесами (forest trust).
Явно устанавливаются сетевым администратором между двумя корневыми доменами леса. При этом сетевой администратор так же принимает решение о том какую направленность будут иметь данные отношения. Данное отношение предусматривает возможность транзитивного доверия всех доменов одного леса всем доменам другого леса. Но тут есть маленькая фишка. На отношения устанавливаемыми между тремя и более лесами, транзитивность не распространяется. К примеру лес А доверяет лесу В, лес В доверяет лесу С, но лес А не устанавливает доверительные отношения с С, как мы привыкли рассматривать транзитивность. Но транзитивность между лесами возможна. Это происходит тогда когда все леса находятся в режиме работы Windows Server 2003.
Характеризуется одно или двухсторонней направленностью, транзитивные.
Доверительные отношения между доменом и сферой (realm trust).
Явно устанавливаются сетевым администратором между сферой не находящаяся под управлением именно Windows Kerberos v.5. Или скажем чуть по другому, устанавливает доверительные отношения между доменом и областью Kerberos реализованный не в базе Windows. данный тип доверительных отношений может использоваться для обеспечения сквозной аутентификации на Windows и UNIX системах.
Характеризуется одно или двухсторонней направленностью, транзитивные или нетранзитивные.
Вроде бы все, если вкратце о доверительных отношениях.