Share via

Active Directory: Управление видимостью объекта - Режим List Object Mode

  • Article

Введение

Общим требованием является ограничение пользователя или группы пользователей возможность просматривать Active Directory. Одним из возможных решений является запрет, «List Contents» на подразделения или корень самого домена остановив пользователей от просмотра конфиденциальной информации (см. Controlling Object Visibility – Deny List Content).  Имейте в виду, что этот вариант будет явно запрещать, учетной записи доступ.

Альтернативное решение для отказа от «List Contents» является включение «List Object Mode». Это альтернативный режим,List Object Mode, решение сразу не влияет или несет последствия, как явный запрет, но это требует изменения в схеме и разрешения должны быть удалены из текущей структуры AD DS. 

Тестовые случаи вытекают из статьи, приведенной выше, Controlling Object Visibility – Deny List Content.  Вместо того, чтобы создавать отдельные тестовые случаи для этого решения, эти случаи тесно напоминают тестовые случаи из предыдущей статьи, чтобы читатели могли иметь более сравнение и сделать более осознанный выбор при выборе решения или решения, которые наилучшим образом соответствует их потребностям Организации. Эти случаи были слегка изменены и предшествовать исходный тестовый случай из  "Controlling Object visibility – Deny List Content" WIKI статьи.  

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

↑ Вернуться к началу

Текущие настройки

  • 3x Windows Server 2012 R2 Servers

    • 2x Lab.local
    • 1x Lab-Forest-2.local

  • 2x Windows 7 SP 1 Workstations

    • 1x Lab.local
    • 1x Lab-Forest-2.local

  • 2x Active Directory Forest

    • Lab.local – Windows 2012 R2 FFL, DFL
    • Lab-Forest-2.local – Windows 2012 R2 FFL, DFL

           

↑ Вернуться к началу

Вопрос форума

Ниже приводится ссылка на Форум службы каталогов на сайте TechNet, пользователь задал вопрос, о необходимости ограничить доступ к организационным подразделениям. Вторая статья вики стремится помочь, показывая в подробные пошаговые инструкции, альтернативное решение для отказа в списоке содержимого и как это может быть достигнуто путем включения «List Object Mode» в Active Directory. Это альтернативное решение, которое некоторым администраторам могут оказаться полезным.

How to config a trusting domain so that domain admins in the trusted domain can only see users in a certain OU in the trusting domain?

↑ Вернуться к началу

Альтернативные решения

Как уже упоминалось во Введении к статье, альтернативное решение "List Object Mode" будет запрещать отображать содержимое списка и оригинал статьи вики в ответ на вопрос форума пользователей Controlling Object Visibility – Deny List Content

↑ Вернуться к началу

Тестовые случаи

Случай 1

Бетти Boop а., который находится в домене Lab.Local, необходимо ограничить доступ тем, что бы она не могла просматривать конфиденциальные подразделения доменной структуры. Конфиденциальным OU является Users OU , которое является вложенным в Accounts >! HighTouch > Lab.Local

Исходный тестовый случай 1 из Controlling Object Visibility – Deny List Content:

Betty A. Boop, который находится в домене Lab.Local, необходимо обеспечить запрет на просмотр OU, которое содержит конфиденциальные аккаунты в пределах своего домена. Конфиденциальным OU является Users OU которое является вложенным Accounts > !HighTouch > Lab.Local

Случай 2

Domain Administrators из домена Lab-Forest-2.Local необходимо ограничить доступ тем, чтобы они не могли просматривать структуру  Lab.Local леса.

Оригинальный тестовый случай 2 из Controlling Object Visibility – Deny List Content:

Domain Administrators из домена Lab-Forest-2.Local необходимо отказать в доступе на просмотр всего содержимого Lab.Local.

↑ Вернуться к началу

Предупреждение, последствия, и др.

 ПРЕДУПРЕЖДЕНИЕ

При внесении изменений в схему и списки управления доступом в Службу каталогов Active Directory, вы рискуете сделать серьезный ущерб вашей реализации доменных служб и приложений, которые зависят от AD DS для доступа к информации и объектов, содержащихся в. Любые изменения в Active Directory, сделаные правильно, могут предоставить вам и вашей организации дополнительные преимущества. Всегда вносите эти изменения в среде разработки, где вы можете проверить многие аспекты, прежде чем сделать их в продуктивном AD DS.

  Примечание:  Для регистрации оснастки Schema и вносения изменения в схему, требуется повышенные права. Права администратора домена необходимы для зарегистрации dll Schema и права администратора схемы будут необходимы для изменения схемы. Проверьте учетную запись, являющейся членом вышеупомянутых групп, чтобы учетная запись имеет соответствующие права для выполнения действия, описанные ниже.

↑ Вернуться к началу

Вложенность группы пользователей прошедших проверку

По умолчанию, группа Authenticated Users является членом группы Pre-Windows 2000 Compatible Access, поэтому там ее необходимо удалить. Группа Pre-Windows 2000 Compatible Access предназначена для совместимости с NT.  You remove this group just like you would any other user or nested group.

  1. Откройте Active Directory Users and Computers
  2. Выберете Builtin контейнер
  3. Выберете Pre-Windows 2000 Compatible Access
  4. Правой клавишей на группе и выберете Свойства
  5. Выберете закладку Members

Как видно на изображения ниже, Authenticated Users вложена в Pre-Windows 2000 Compatible Access группу.

  1. Выберете группу Authenticated Users
  2. Выберете Remove (Удалить)
  3. Подтвердите удаление в диалоговом окне Active Directory Domain Services, нажав Yes

Смотрите изображения ниже.

  1. Жмем Apply (Применить)
  2. Потом OK

Этим завершаем шаг удаления группы Authenticated Users из Pre-Windows 2000 Compatible Access группы.

↑ Вернуться к началу

Изменение схемы - DS-Heuristics

  Стоп: Внесение изменений в схеме может вызвать серьезные или смертельные проблемы реализации AD DS. Убедитесь, что у вас есть текущая резервная копия вашей среды AD DS, а также проверенные планы/процедуры восстановления. Как всегда прежде чем вносить какие-либо изменения в продуктивной среде, убедитесь, вы полностью протестировали и понимаете действия, которые вы собираетесь выполнить. Проверить эти действия в среде разработки до их выполненоя в продуктивной среде.

Атрибут DS-Heuristics в AD DS можно использовать для внесения глобальных изменений в поведение Active Directory и контроллеров Служба каталогов Active Directory во всем лесу Active Directory. Это изменение представляет собой широкое изменение леса.

Включение режима List Object Mode

Первый шаг, чтобы перевести Active Directory в «List Object Mode», — изменение атрибута dSHeuristics attribute и установка третьего символа в 1. Это делается средствами ADSI Edit путем подключения к конфигурации.

Изменение атрибута dSHeuristics - ASDI Edit

Откройте ADSI Edit из Administrative Tools, или выполните adsiedit.msc в командной или PowerShell строке.

Открыв, щелкните правой кнопкой мыши в левой области ADSI Edit и выберете "Connect to..."("Подключиться к...") как показано ниже.

После выбора "Connect to...", появится диалоговое окно Connection Settings (Параметры подключения).  В этом диалоговом окне выберите Configuration (Конфигурация) из "Select a well known Naming Context" ("Выберите известный контекст именования") а затем нажмите кнопку ОК. Смотри изображение ниже.

После того, как вы подключились к Конфигурации:

  1. Разверните Configuration 
  2. Разверните CN=Configuration,DC=yourdomainname,DC=com 
  3. Разверните CN=Services
  4. Разверните CN=Windows NT
  5. Выберите, а затем щелкните правой кнопкой мыши CN=Directory Services и нажмите кнопку Properties(Свойства)

Смотрите изображение ниже о шагах выше.

После выполнения шагов выше, бедет отображено диалоговое окно CN=Directory Services Properties, как показано ниже.

После появления диалогового окна CN=Directory Services Properties:

  1. Найдите и дважды щелкните dSHeuristics атрибут 
  2. Откроется редактор атрибутов dSHeuristics, нажмите кнопку Clear (Очистить)
  3. Тип 001
  4. Нажмите кнопку OK

Чтобы завершить включение "List Object Mode"

  1. Нажмите кнопку Apply (Применить)
  2. Нажмите кнопку OK

После этого можно закрыть редактор ADSI Edit, вы уже знаете, «List Object Mode» включен и готовы продолжить.

Проверка включения List Object Mode

Проверка включения List Object Mode:

  1. Откройте Active Directory Users and Computers
  2. Нажмите кнопку View (Вид)
  3. Нажмите кнопку Advanced Features (если он еще не выбран)
  4. Выберите контейнер Users
  5. Выберите Domain Admins
  6. Щелкните правой кнопкой мыши Domain Admins
  7. Выберите Properties (Свойства)
  8. Перейдите на вкладку Security (Безопасность)
  9. Нажмите кнопку Advanced (Дополнительно)
  10. Выберите Authenticated Users
  11. Нажмите кнопку Edit (Редактировать)

Откроется диалоговое окно "Permission Entry for Domain Admins" и участник должен быть Authenticated Users (левый верхний угол), в разделе разрешения вы должны увидеть недавно перечисленные разрешения "List object".  

Смотрите изображение ниже.

↑ Вернуться к началу

Изменение родительской OU

Чтобы сохранить соответствие с тестовым случаем 1 и скрыть Users OU,  который вложен в Accounts -> !HighTouch -> Lab.local, wнам нужно сначала удалить разрешение «List content» для Authenticated Users пользователей на подразделении Accounts.

Удаление List Content

Откройте Active Directory Users and Computers и найдите, а затем выберите и щелкните правой кнопкой мыши родительский OU, вы хотите изменить (в данном случае Accounts OU).

  1. Нажмите кнопку Properties (Свойства)
  2. В диалоговом окне Properties OU щелкните вкладку Security (Безопасность)
  3. Нажмите кнопку Advanced (Дополнительно)

Когда откроется диалоговое окно Advanced Security:

  1. Найдите и выберите Authenticated Users
  2. Нажмите кнопку Edit (Изменить)

После этого появится диалоговое окно Permission Entry of Accounts.

  1. Убедитесь, что пользователь Authenticated Users
  2. Снимите флажок List contents
  3. Нажмите кнопку OK

После завершения этого шага будет закрыто диалоговое окно Permission Entry for Accounts (или выберите OU в вашей среде), и система отобразит вам Advanced Security Settings for Accounts в диалоговом окне. 

В этом диалоговом окне,

  1. Убедитесь, что Authenticated Users теперь имеет Special в столбце Access (Доступ)
  2. Нажмите кнопку Apply (Применить)
  3. Затем OK

После проверки, нажав кнопку Apply (Применить) и кнопку OK, диалоговое окно будет закрыто, и вы останетесь с диалоговым окном Settings (Свойства) для подразделения. Нажмите кнопку ОК, чтобы закрыть это диалоговое окно и вы успешно завершите этот шаг.

↑ Вернуться к началу

Проверка присутствия подразделения Users

На компьютере Windows 7 я установки RSAT и открыл Active Directory Users and Computers, чтобы убедиться, что я все еще могу видеть Users OU и объекты, которые он содержит. 

↑ Вернуться к началу

Изменение дочерней OU

После завершения предыдущих шагов и удалив разрешение «List contents» для Authenticated Users на родительском подразделении (в данном случае Accounts OU), мы можем продвигаться вперед и удалить разрешение «List object» ля Authenticated Users на дочернем подразделении. Теперь Бетти Boop и другие пользователи в рамках Users OU не должны иметь доступ. 

Удаление List Object

 

Откройте Active Directory Users and Computers и найдите, а затем выберите и щелкните правой кнопкой мыши дочернее OU для изменений (в данном случае Users).

  1. Нажмите кнопку Properties (Свойства)
  2. В диалоговом окне Properties  (Свойства), перейдите на вкладку Security (Безопасность)
  3. Нажмите кнопку Advanced (Дополнительно)

Когда появится диалоговое окно Advanced Security Settings (Дополнительные параметры безопасности):

  1. Найдите и выберите группу Authenticated Users
  2. Затем нажмите кнопку Edit (Изменить)

После этого появится диалоговое окно Permission Entry of Accounts(Разрешение входа учетных записей).  

  1. Убедитесь, что выбран Authenticated Users 
  2. Снять флаг List object (не List Contents как это было сделано для родительского OU) 
  3. Нажмите кнопку ОК 

После завершения этого шага будет закрыто диалоговое окно Permission Entry for Accounts (или выберите OU в вашей среде), и система отобразит вам Advanced Security Settings for Accounts в диалоговом окне. 

  1. Убедитесь, что Authenticated Users теперь имеет Special в столбце Access (Доступ)
  2. Нажмите кнопку Apply (Применить)
  3. Затем OK

После проверки, нажав кнопку Apply (Применить) и кнопку OK, диалоговое окно будет закрыто, и вы останетесь с диалоговым окном Settings (Свойства) для подразделения. Нажмите кнопку ОК, чтобы закрыть это диалоговое окно и вы успешно завершите этот шаг.

По завершении этого действия будут скрыты дочернее OU. 

↑ Вернуться к началу

Проверка исчезновения Users OU

Возвращаясь к машине Windows 7 с RSAT, в Active Directory — пользователи и компьютеры выберите родительский OU (���� данном случае Accounts OU) и нажмите клавишу F5, чтобы обновить содержимое OU. После обновления содержимого родительского OU убедитесь, что дочернее подразделение, Users не видна.

Если все работает, как запланировано, дочернее OU не должен быть видим для обычных пользователей и Authenticated Users как на изображение выше.

↑ Вернуться к началу

Разница: List Object Mode против Deny List Content

В настоящее время регулярные пользователи не могут видеть структуру Подразделений Организации. Это верно заявление... Однако при текущих настройках, группа Authenticated Users имеет возможность просматривать дочернее подразделение в Active Directory Users and Computers Users которые удалены. Это не останавливает пользоватлей Authenticated Users в вашей среде.

В изображении ниже Обратите внимание, что в Active Directory Users and Computers Users OU не является видимым. Однако если вы посмотрите на поиск пользователей, контактов и групп, а также PowerShell, оба позволяют Betty Boop (Authenticated Users) найти учетные записи пользователей, которые были в скрытом, в скрытом дочернем подразделение.

Чтобы сделать шаг дальше, вы должны также удалить разрешения List Content для дочерних Подразделений. 

↑ Вернуться к началу

Удаление List Content и List Object

Если вам интересно, почему я не включил это как часть шагов в предыдущих разделах, вот причина. Если удалить «List Content» от родительского подразделения и затем удалите «List object» и «List Content» из дочернего подразделения, вы не сможете найти пользователей с помощью поиска или PowerShell. Путем удаления «List object» и «List Content», вы создали по существу то же самое, что и запрет «List Content».

На изображении ниже, стрелка 1 PowerShell Get-ADUser команда, перед удалением «List Content» из дочернего подразделения и стрелка 2 команда после удаления «List Content» из дочернего подразделения.

Напомним, что если «List object» и «List Content» удаляются из дочернего подразделения, если у родителя которого удалено «List Content», вы получаете риск отказа приложений, использующих учетные записи пользователей в среде AD DS, возможность поиска информации в домене.

↑ Вернуться к началу

Тестовый случай 2 & List Object Mode

Для Тестового случая 2 мы столкнулись с проблемой, на основе работы, которую мы делали выше.  С текущей настройки два домена доверяют друг другу по 2-way доверию и проверки подлинности в лесу.  Из-за проверку подлинности всего леса, вам придется изменить корень домена и убрать «List contents» для группы Authenticated Users. После этого вам придется забрать «List Object» на первом уровне всех подразделений и контейнеров. Это работает, но что делать, если у вас есть структуры Подразделений, где родительский OU имеет удаленный «List contents»?  Это приведет, что все пAuthenticated Users лишены доступа к объектам в этом подразделении, это же результат как удаление list content and list object из раздела выше.

Этот список и изображение ниже, подробности сценария:

  1. Содержимое списка удаляется из корня домена
  2. Содержимое списка и списк объектов будет удален из верхнего уровня подразделения, в нашем случае !BusinessUnits
  3. Объект списка удаляется из дочерних подразделений 1, 2 и 3, потому что новое подразделение 4 должены быть созданы, и мы не хотим чтобы пользователи в подразделении 4, могли видеть подразделения 1, 2 и 3 

Чистый результат - всем пользователям будет отказано в доступе к объектам ниже родительского подразделения !BusinessUnits

↑ Вернуться к началу

Другие ресурсы

↑ Вернуться к началу

Заключение

Active Directory является очень гибким из коробки, и вы можете делегировать и управлять разрешениями в соответствии с потребностями вашей организации. Однако, для многих изменений, неопробованные, могут причинить вам часы, дни головной боли. Всегда вносите изменения в контролируемых условиях и никогда не вносите изменения непосредственно в продуктиве AD DS. Помните, что в этой статье описано создания «List Object Mode», это не всегда уместно во всех ситуациях, как было указано в Test Case 2 & List Object Mode.  Для вашей огрганизации "List Object Mode" может быть полезным или использование запрещающего правила или сочетание этих двух правил. Какой вар��ант лучше всего подходит для вас, являетс�� то, что лучше всего подходит для вашей организации.

↑ Вернуться к началу

Бонус: Модификация схемы - группы Пользователей прошедших проверку

  Стоп: Внесение изменений в схеме может вызвать серьезные или смертельные проблемы AD DS. Убедитесь, что у вас есть текущая резервная копия вашей среды AD DS, а также проверенные планы/процедуры восстановления. Как всегда прежде чем вносить какие-либо изменения в продуктивной среде, убедитесь, что вы полностью протестировали и понимаете действия, которые вы собираетесь принять. Проверте эти действия в среде разработки до переноса в продуктив..

  Примеание: Эта модификация схемы является НЕ обязательным шагом и��и требованием.  Этот шаг дает вам инструкции, необходимые для измения набора разрешений по умолчанию класса подразделения. Изменяя набор разрешений по умолчанию класса подразделения, можно уменьшить кол-во шагов, необходимых при создании новых подразделений в будущем.

Используя указанные ниже действия, для изменения класса подразделения, вы измените набор прав для подразделения по умолчанию, который не включает «List object» на Authenticated Users разрешений по умолчанию. Ниже будет показано, как установить оснастки схемы и изменить класс OU, шаг за шагом. После изменения, любое вновь созданное подразделение будет иметь этот набор прав по умолчанию. Чтобы воспользоваться всеми преимуществами этого шага, все вновь созданные подразделения должны находиться под родительским Подразделением, которое имеет разрешение «List content», удалено для Authenticated Users пользователей. Этот параметр может быть лучше всего подходит для среды распределенного типа, но может применяться и к другим организациям.

См. ниже для визуального представления и дальнейшего объяснения.

На изображении выше 1 представлено родительское подразделение и 2 представляют собой дочерние подразделения. Для выполнения шагов в этом разделе для вновь созданного дочернего подразделения будут автоматически скрыты от представления пользователей, родительский OU должны быть изменены и пользователи группы Authenticated Users необходимо иметь удаленный «List Content» из списка разрешений . В сценарии выше, дочернее подразделения, помеченные как 2, по-прежнему будут видны для пользователей. Если !BusinessUnits 4-й бизнес-подразделения, которое было создано подразделение с именем 4, он будет автоматически скрыт от всех Authenticated Users пользователей, при условии изменения родительского подразделения безопасности и выполняются указанные ниже действия. Чтобы изменить существующие дочерние подразделения, необходимо удалить разрешение «list object», и этот шаг повторяется для каждого подразделения, которое должно быть скрыто от пользователей. 

Установка оснастки Active Directory Schema

Полную версию статьи Microsoft для действия можно найти в http://technet.microsoft.com/en-us/library/cc732110.aspx

Требования к установке

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

Шаги по установки оснастки

Откройте с повышенными правами командную строку или PowerShell 

Введите следующую команду, перечисленные ниже, а затем нажмите клавишу ВВОД:

regsvr32 schmmgmt.dll

Ошибка установки оснастки схемы

Если вы получили сообщение об ошибке выше, вы либо не открыли командную строку с привилегиями администратора или учетной записи, используемой не имеет соответствующие разрешения для регистрации библиотеки dll. Проверьте разрешения учетной записи, которую вы используете для завершения шага выше, откройте с запросом имени пользователя, щелкнув правой кнопкой мыши запрос и выберите «Запуск от имени администратора» и снова запустите команду.  

Удачная установка оснастки Схемы

Если команда завершается успешно, вы получите сообщение о том, schmmgmt.dll успешно зарегистрированы, см. изображение выше.

Открытие остнастки Schema

После того, как вы успешно зарегистрировали оснастку схемы dll, откройте Microsoft Management Console (MMC) и нажмите кнопку файл, а затем нажмите кнопку Добавить или удалить оснастку. 

Как только появится диалоговое окно Добавление и удаление оснастки, 

  1. Выберите Active Directory Schema из "Доступные оснастки" в левой стороне 
  2. Нажмите кнопку Add (Добавить) между доступные и Выбранные оснастки 
  3. Убедитесь, что оснастки Active Directory Schema присутствует в столбце Выбранные оснастки
  4. Затем закончите, нажав кнопку ОК в правом нижнем углу диалогового окна. 

Смотрите изображение ниже для визуального пояснения предыдущих 4 шагов.

Теперь, когда оснастка схемы добавлена в консоль MMC можно найти и изменить класс organizationalUnit.

Поиск Organizational Unit class - organizationalUnit

После открытия оснастки схемы выполните следующие действия, чтобы найти класс Organizational Unit.

  1. Разверните Active Directory Schema
  2. Нажмите на Classes
  3. Используйте полосу прокрутки справа чтобы найти organizationalUnit, пролистайте список вниз
  4. Щелкните правой кнопкой мыши на organizationalUnit и выберите пункт Properties (Свойства)
  5. Затем когда появится окно Properties (Свойства) organizationalUnit  выберите Default Security (Безопасность по умолчанию)

Смотрите изображение ниже для визуального пояснения предыдущих 5 шагов.

Изменение Organizational Unit class

Когда будут открыты свойства organizationalUnit и выбранна вкладка Default Security (Безопасность по умолчанию), там будут присутствовать права безопасности по умолчанию.

Обратите внимание, что в изображении выше Authenticated Users группы по умолчанию, будут иметь разрешения на чтение каждого подразделения, которое создается.

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

Разрешения:

  • List contents
  • Read permissions
  • List object
  • Read all properties

Свойства**:**

  • Read all Properties

Изменение разрешений группе Authenticated Users

Если вы хотите,чтобы в будещем при создании OU не впоминать о необходимости измения разрешения для группы Authenticated Users. 

Измените разрешения группе Authenticated Users group:

  1. Снимите флаг List object
  2. Нажмите OK 

Когда разрешения выполнены для Organizational-Unit, затем нажмите OK:

  1. Убедитесь,что Authenticated Users имеют Special разрешения в колонке Access  на закладке Advanced Security Settings для Organizational-Unit диалоговом окне
  2. Нажмите Apply
  3. Нажмите OK

В диалоговом окне organizationalUnit Properties:

  1. Нажмите Apply
  2. Нажмите OK

Закройте консоль Schema.

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

↑ Вернуться к началу

Другие языки

  Вернуться к началу