Отношения доверия в лесах и доменах
Часто бывает, что корпоративная сеть состоит из нескольких доменов, а иногда и лесов, в этом случае в корпоративной сети можно выделить внутреннюю и внешнюю границы. Сетями, находящимися за внешней границей по-прежнему будем считать сети никак не подконтрольные организации, внутренними же границами будем считать границы доменов или лесов корпоративной сети предприятия.
Для того чтобы пользователи различных доменов имели доступ через внутренние границы корпоративной сети между доменами и лесами, необходимо установить отношения доверия. Чтобы построить систему отношений доверия необходимо: задокументировать текущую архитектуру лесов или доменов; определить потребность в доступе к ресурсам во всех имеющихся доменах; выбрать направление доверия; определить ограничение отношений доверия.
Предположим, что документация по архитектуре существующих доменов является частью Политики безопасности корпоративной сети, поэтому сразу перейдем ко второму этапу и укажем аспекты, требующие внимания при анализе потребностей доступа к ресурсам. Во-первых, необходимо убедиться, что доступ к данным через внутреннюю границу действительно необходим (вполне возможно, что данные можно разместить на внешнем Web-сервере, тогда отпадет необходимость в пересечении внутренней границы. Во-вторых, необходимо определиться с локализацией ресурсов, к которым необходим доступ (определить находятся ли требуемые ресурсы в одном или в разных доменах, а может быть на единственном сервере). В-третьих, необходимо выяснить, кто будет давать разрешения на доступ , кто будет его контролировать (определиться с владельцами нужных объектов и административными учетными записями).
Доверие бывает следующих типов:
- отсутствие доверия (применяется по умолчанию в доменах WindowsNT 4.0; делает домен изолированной сущностью; предполагает, что пользователи получат доступ к ресурсам этого домена при наличии в нем соответствующей учетной записи);
- доверие между доменами одного леса (все домены WS2003 в одном лесу связаны двухсторонними переходными отношениями. Это значит, что каждый домен, являющийся участником таких отношений доверяет другому домену, который также является участником указанного доверия);
- спрямляющее доверие (отношения доверия с доменом из того же леса, является односторонним и не переходным; также отличается от доверия между доменами в одном лесе тем, что позволяет сократить путь доверия. В этом случае запрос сеансовых билетов происходит непосредственно в целевом домене и не проходит полный путь иерархии доменов в лесе.);
- внешнее доверие (отношения доверия между доменом WindowsNT 4.0 и некоторым лесом или доменом другого леса. Является односторонним и не переходным. Для установки двухстороннего доверия нужно использовать два разнонаправленных доверия, которыми надо связать все требуемые пары доменов.);
- доверие между лесами (это двухсторонние или односторонние отношения доверия между разными лесами, всегда являющиеся переходными. Для их организации оба леса должны работать в режиме WS2003.).
Созданные доверия рекомендуется ограничивать. Доверие в принципе ограничивается автоматически, но можно добавить и созданное вручную ограничение. Автоматически доверие ограничивается: направлением; кругом доверяемых доменов и лесов (по умолчанию доверительные отношения между двумя доменами разных лесов не распространяются на остальные домены); типом доступа (для всех участников безопасности доступ к общим ресурсам в доверительных доменах должен быть определен явно, потому что отношения доверия не отменяют механизм авторизации).
Вообще говоря, злоумышленник может использовать доверие для несанкционированного доступа в другом домене, поэтому необходимо устанавливать дополнительные ограничения на отношения доверия. Во-первых, необходимо использовать фильтрацию SID . Этот механизм включается автоматически и обеспечивает неприменение внешних идентификаторов безопасности при доступе к внутренним ресурсам леса. Если бы такой механизм отсутствовал, получилось бы, что администраторы доверяемого домена становились бы администраторами в доверяющем. Аналогичная ситуация произошла бы и с другими участниками безопасности. Поэтому в доверяющем домене идентификаторы безопасности из других доменов не должны произвольно использоваться. Механизм фильтрации SID можно отключить, но делать это крайне не рекомендуется.
Также с точки зрения безопасности важно понимать, что вновь созданное отношение доверия уязвимо из-за потенциально широкого доступа к объектам группы Все. Любой пользователь из доверяемого домена будет иметь полномочия этой группы в доверяющем домене, даже если ему явно не назначено разрешение на доступ к объектам. Поэтому доступ к важным ресурсам этой группы следует ограничить еще до создания доверительных отношений. То же самое касается группы Сеть. Также доверие следует ограничить следующим образом:
- отключить список участников доверия домена (не стоит отключать Запись с информацией о домене полностью. Это равносильно запрету использования доверия. Для ограничения нужно использовать запись TopLevelExclusion, которое позволяет исключить часть пространства из доверия.);
- ограничить проверку подлинности (можно явно разрешить проверку на уровне сервера или домена. Без такой проверки ни один пользователь из доверяемого домена не сможет обратиться к ресурсам доверяющего.);
- установить разрешение на проверку подлинности (это можно сделать в свойствах безопасности контроллера домена для установления доверия между доменами или лесами или в свойствах безопасности конкретного сервера).
Для функционирования доверия также необходимо соблюдение ряда физических условий. Во-первых, домены должны быть физически соединены кабелем, во-вторых, необходима адекватная настройка системы DNS , ведь имена должны разрешаться по обе стороны доверия. Если пространство имен DNS разделено между разными серверами, то они должны быть доступны по обе стороны доверия. В-третьих, если внутренние границы сети соединены между собой брандмауэрами, то на последних необходимо открыть следующие порты: RPC локального администратора безопасности (по умолчанию он динамический, но для уменьшения числа открытых портов его номер необходимо задать в следующем разделе реестра HKLM\system\currentcontrolset\servicies\ntds\parameters – параметр TCP/IP Port ); RPC NETLOGON ( он задается в реестре по адресу HKLM\system\currentcontrolset\servicies\netlogon\parameters ), а также порты с номерами 88 для аутентификации Kerberos, 135 – для контроля над Action Control Listами объектов.
Внедряя доверие , необходимо руководствоваться следующими рекомендациями:
- для сокращения пути доверия и времени отклика нужно использовать спрямляющее доверие;
- для доступа к ресурсам домена WindowsNT 4.0 нужно использовать внешнее одностороннее доверие;
- двустороннее доверие между лесами подойдет для лесов WS2003 при условии размещения общих ресурсов в обоих лесах;
- если пользователям одного домена WS2003 необходим доступ к ресурсам в разных доменах другого леса необходимо использовать одностороннее доверие между исходным доменом и каждым из целевых;
- если используются домены WS2000 нужно использовать попарную связь лесов с двухсторонними довериями.
Грамотно настроенные отношения доверия позволят пользователю проходить аутентификацию в своем домене при доступе к ресурсам другого домена или леса, а это значит, что для обеспечения санкционированного доступа к ресурсам необходимо будет контролировать его не во всей сети, а только в пределах нужного домена. Отношения доверия облегчают труд администраторов и делают систему доступа к ресурсам более прозрачной и контролируемой.
Источник
Применение политик между лесами Active Directory
Нам часто кажется, что технология или инструмент, с которым мы работаем нам полностью понятны. На самом деле, нам понятны сценарии, с которыми мы встречались на практике. Для всего остального мы можем лишь предположить ожидаемое поведение.
Недавно мне задали интересный вопрос – как будут применяться политики при использовании компьютеров в одном Active Directory домене пользователями из другого домена, при условии, что между доменами есть доверительные отношения, но они находятся в разных лесах. Я понял, что я знаю, как оно должно быть в теории, но ни разу не проверял, как оно себя поведёт на самом деле. Самый простой способ убедиться в своей правоте или ошибке – проверить. Ниже диаграмма простой тестовой среды:
Поиграв с настройками политик, я узнал несколько забавных вещей. Если вам интересно, как будут вести себя политики пользователя из домена Users.org и пользовательская секция политик компьютера из домена Computers.com при совместном использовании, добро пожаловать под кат.
Для управления политиками в таком сценарии у вас есть два инструмента. Первый знаком всем администраторам Active Directory доменов – режим обработки замыкания пользовательской групповой политики (User Group Policy loopback processing). Справедливости ради, эта настройка работает независимо от того, в каком домене находится пользователь использующий компьютер. Параметр, который нас интересует:
Computer Configuration\Administrative Templates\System\Group Policy\User Group Policy loopback processing mode
Если вы используете этот режим, то пользовательская секция настроек из групповой политики применённой на компьютер будет использована для вашего пользователя, даже если он из доверенного домена. Здесь никаких сюрпризов не было.
Второй инструмент управления процессом применения групповых политик — разрешить применение параметров политик пользователей и использование перемещаемых профилей пользователей при переходе между лесами. Я видел эту настройку в сценариях с миграцией между доменами, где она была нужна для обеспечения доступности профилей пользователей, но ни разу не видел её использования именно для применения политик между лесами. Вам нужен следующий параметр:
Computer Configuration\Administrative Templates\System\Group Policy\Allow cross-forest User Policy and Roaming User Profiles
Когда этот режим активирован на рабочей станции, при входе пользователя в систему, применяются настройки пользовательской секции групповых политик из его родного домена.
Итак, у вас есть возможность настраивать среду для пользователей на компьютерах в доверяющем лесу либо через компьютерные политики и режим обработки замыкания либо через пользовательские политики и режим применения политик между лесами. На мой взгляд, вариант, с обработкой замыкания лучше, так как вы сохраняете все настройки в одном месте – в политиках того домена, где находится компьютер. Если вы используете режим применения политик между лесами, то вам стоит аккуратно задокументировать эту особенность вашей среды, чтобы в дальнейшем, новый человек, пришедший её администрировать не получил сюрпризов с непонятным для него поведением системы.
Источник