Блокирование разрешения: используйте осторожно
Использование блокирования разрешения может привести к тому, что работать с моделью защиты вашей службы Active Directory будет очень трудно. Есть множество различных сценариев, в которых вы можете предусмотреть блокировку разрешения. Один из них состоит в том, что вы можете использовать Deny (Запретить) для удаления некоторых унаследованных разрешений. Например, вы можете предоставить разрешения Modify на контейнерном уровне, но заменить его на Read-Only (Только для чтения) далее вниз по иерархии. В этом же сценарии вы можете блокировать разрешение Write на любых объектах или свойствах далее вниз по иерархии.
Еще одним сценарием, в котором можно было бы использовать Deny, является создание контейнера, требующего более высокой защиты. Например, имеется контейнер для всех должностных лиц, и нужно сделать так, чтобы обычный пользователь не смог читать свойства учетных записей должностных лиц. Вы можете блокировать разрешение Read для контейнера, используя группу Domain Users (Пользователи домена). В результате пользователям будет запрещено читать объекты каталога, включая администраторов. Из-за осложнений, которые может вызвать использование Deny, вы должны применять эту опцию с осторожностью.
В большинстве случаев вместо блокировки разрешений можно удостовериться, что пользователю или группе не были даны эти разрешения. Если пользователь при этом не является членом группы, которой были предоставлены разрешения, он не будет иметь доступа к объектам. Вам не обязательно блокировать разрешение для предотвращения доступа пользователей к объектам Active Directory.
Один из немногих сценариев, в которых выгодно использовать Deny, состоит в том, что группа должна иметь определенные разрешения, а один или более пользователей этой же группы должны иметь разрешения более низкого уровня. Например, вы можете создать группу по имени Account Admins, которая отвечает за управление всеми учетными записями пользователей в домене. Некоторые члены этой группы могут быть временными служащими, которые должны управлять всеми учетными записями пользователей в домене, но не имеют права изменять свойства учетных записей должностных лиц. В этом случае вы можете назначить группе Account Admins разрешение управлять учетными записями
пользователей в домене, затем создать OU для учетных записей должностных лиц и группу для временных членов группы Account Admins. Затем можно заблокировать право временных пользователей изменять какие-либо учетные записи пользователей в OU должностных лиц.
Таким образом, конфигурирование защиты объектов Active Directory может затрагивать большое количество взаимосвязанных переменных. Многие компании могут начинать с довольно простого проекта защиты, в котором маленькой группе администраторов предоставляются все разрешения в Active Directory. В большинстве случаев начальная конфигурация защиты Active Directory ясно задокументирована. Однако со временем она становится более запутанной. Иногда другой группе администраторов предоставляется набор разрешений для выполнения определенной задачи в течение определенного периода времени. Предоставить разрешение просто, но часто случается так, что впоследствии разрешения забывают удалить. Часто модификации защиты, сделанные после начального развертывания Active Directory, не документируются.
Для любой структуры Active Directory существует возможность того, что текущая конфигурация защиты окажется более сложной, чем первоначально разработанная конфигурация. Иногда это кончается тем, что пользователи имеют больше разрешений, чем следует. К счастью, в Windows Server 2003 есть инструмент, который может использоваться для определения фактических разрешений, представленных участнику безопасности для доступа к объектам Active Directory.
Обратитесь к свойствам объекта через соответствующий инструмент администрирования Active Directory. Выберите вкладку Security (Безопасность), щелкните на Advanced (Дополнительно), а затем выберите вкладку Effective Permissions (Фактические разрешения). На рисунке 9-7 показано окно инструмента Active Directory Users And Computers. Чтобы определить фактические разрешения для определенной учетной записи пользователя или группы, щелкните Select (ВыборХ а затем найдите имя группы или пользователя. Выбрав имя, щелкните на ОК. Окно Effective Permissions (Фактические разрешения) отображает все разрешения, которые предоставлены выбранному участнику безопасности для доступа к данному объекту Active Directory.
Примечание. Данный инструмент имеет некоторые ограничения, которые могут влиять на отображаемые фактические разрешения. Инструмент определяет фактические разрешения, основанные на наследовании и явно определенных разрешениях для учетной записи пользователя и его группы. Однако пользователь может также получить некоторые разрешения на основании того, как он входит в систему и соединяется с объектом. Например, в Windows Server 2003 вы можете назначать разрешения для группы Interactive (членом этой группы становится каждый, кто cделал вход на компьютер) или группы Network Login (каждый, кто обращается к информации по сети). Описанный выше инструмент Active Directory не может определять разрешения, предоставленные пользователю на основании принадлежности к этим типам групп. Кроме того, он может определять разрешения, используя только разрешения человека, выполняющего инструмент. Например, если пользователь, который выполняет инструмент, не имеет разрешения читать состав некоторых групп, к которым принадлежит интересующий его пользователь, то инструмент не способен точно определить разрешения.
Рис. 9-7. Отображение фактических разрешений для объекта Active Directory
