Я что-то тестировал в своей лаборатории: я создал учетную запись, а затем добавил запрещающий ACL к домену, применив его и ко всем дочерним объектам, отказавшись от полного контроля. Однако я обнаружил, что, используя adfind в качестве запрещенной учетной записи, я все еще мог перечислять пользователей (но некоторые свойства были скрыты)!
Я обнаружил, что при применении запретить полный доступ ACL только к пользователю вызывало скрытие пользователя. Однако унаследованные разрешения показаны и, похоже, все отрицают.
Почему унаследованного ACL недостаточно для предотвращения списка пользователей?
Платформа в данном случае - Windows Server 2008 R2.
Оказывается, что явные разрешающие ACL имеют приоритет над унаследованными запрещающими ACL, и есть явные ACL для каждого объекта для аутентифицированных пользователей. Увы; единственный способ сделать это - либо лишить авторизованных пользователей разрешения на все, что нужно скрыть, либо добавить явный ACL для каждого такого объекта.
Это, к сожалению, значительно затрудняет отказ пользователя в доступе к перечислению чего-либо в домене.
Пользователи могут просматривать все дочерние объекты контейнера, если им не было отказано в разрешении контейнера на просмотр дочерних объектов.
Управление видимостью объекта
http://msdn.microsoft.com/en-us/library/windows/desktop/ms675746%28v=vs.85%29.aspx
«Доменные службы Active Directory предоставляют возможность скрывать объекты от пользователей, которым отказано в определенных правах. Если объект скрыт, приложение, работающее с учетными данными пользователя, не сможет выполнить перечисление или привязку к объекту.
"Если пользователю предоставлено право управления доступом ADS_RIGHT_ACTRL_DS_LIST к контейнеру, пользователь может просматривать любой из дочерних объектов контейнера. Аналогичным образом, если пользователю отказано в праве управления доступом ADS_RIGHT_ACTRL_DS_LIST к контейнеру, пользователь не может просматривать ни один из дочерних объектов контейнера. Это позволяет скрыть содержимое целых контейнеров ".
Я знаю, что это устарело, но, возможно, мой ответ поможет направить тех, кому он нужен, в правильном направлении (сейчас я прохожу то же самое с компанией, у которой уже была внедрена среда AD).
Встроенный Прошедшие проверку пользователи группе будет предоставлена возможность читать атрибуты объектов Active Directory и это примет приоритет над явным разрешением DENY, унаследованным от родительского подразделения или контейнера. Все это основано на том, как изначально строится AD и как создается структура разрешений при создании леса / домена. Прочтите эту статью для получения дополнительной информации:
Скрытие данных в Active Directory
А этот из той же серии (о том, как это сделать) ...
Скрытие данных в Active Directory, часть 3: Включение режима объектов списка в лесу
В принципе, вы можете включить Режим списка объектов путем изменения бита dsHeuristics через ADSIedit (измените 3-й бит с 0 на 1). Тогда избавься от Прошедшие проверку пользователи (чтобы он не применялся автоматически к объектам AD). Тогда ваши разрешения DENY будут иметь приоритет. Однако изменение этого параметра приведет к тому, что AD потребуется больше времени для оценки разрешений, поэтому убедитесь, что это именно то, что вы хотите сделать. Для «средних» доменов задержка незначительна.
ВНИМАНИЕ: Кроме того, убедитесь, что это именно то, что вы хотите сделать (и я рекомендую делать это при первом построении домена, а не после его использования). Если вы не сделаете это заранее при первом создании домена, вы, скорее всего, нарушите групповые политики, приложения, которые запрашивают AD, и т. Д. Этот тип вещей должен быть спланирован и реализован в домене заранее, чтобы вы гарантировали надлежащие разрешения. доступны для работы приложений во время их развертывания. Все зависит от того, насколько гранулярно вы хотите получить, но это может легко сломать все, если вы реализуете его в домене, который уже находится в производстве.