Как использовать фильтр, чтобы избежать подчиненного подразделения в Active Directory?

Question

У меня есть приложение, которое извлекает пользовательскую информацию из подразделения в Active Directory. Необходимые параметры - это база для поиска и строка фильтра.

У меня есть подразделение, из которого я хочу получить информацию, но есть подразделение, о котором я хочу избежать:

Требуются

пользователей из OU=People,DC=mydomain,DC=com

Не разыскивается

пользователи из OU=Evil,OU=People,DC=mydomain,DC=com

Я знаю, что это можно сделать, переписав приложение, выполняющее импорт, чтобы остановить его поиск в подразделениях, но есть ли способ сделать это с помощью фильтра LDAP в поиске? Нечто подобное (DistinguishedName !contains "Evil") или подобное, которое позволит мне исключать пользователей на основе пути к пользователю, а не фильтровать его по свойству.

Answer 1

Если вы используете System.DirectoryServices (.Protocols) в .NET, вы можете установить SearchScope на OneLevel, чтобы выполнять поиск только в подразделении People (и не в дочерних подразделениях). Но это не сработает, если у вас есть OU=Good,OU=People,DC=mydomain,DC=com ...

Второй вариант - запросить подразделение People для всех подразделений: s (objectClass=organizationalUnit), а затем выдать несколько поисковых запросов; по одному на каждого из них (кроме «злого»).

Редактировать: @geoffc - это будет действительно сложно реализовать. По умолчанию все прошедшие проверку пользователи имеют доступ на чтение ко всем объектам в Active Directory. Простая установка «Deny Read» в Evil OU не сработает, потому что право на чтение для аутентифицированных пользователей установлено для отдельного объекта пользователя (в данном случае) и, таким образом, имеет приоритет над Deny ACL, установленным в OU. По сути, вам нужно будет установить ACL Deny Read для каждого из объектов в Evil-OU и всегда следить за тем, чтобы новые объекты, добавленные в каталог, получали одинаковый набор прав Deny. Вы можете отредактировать схему Active Directory и удалить права для аутентифицированных пользователей, но это может нарушить многие другие функции (включая Exchange) и не поддерживается Microsoft.

Answer 2

AFAICT, это невозможно сделать с помощью фильтра LDAP в активной директории. Многие другие реализации LDAP поддерживают расширяемое сопоставление, а AD - нет.

Пользователи, рекомендующие фильтры, содержащие (ou:dn:=Evil) или подстановочные знаки в distinguishedName, не проверяли Active Directory.

Answer 3

Следующие хитрости помогут:

(&(objectClass=user)(!(distinguishedName:=%Evil%)))

Я столкнулся с подобной проблемой при создании адресной книги для сканирования в электронную почту. Я пробовал (&(objectClass=user)(!(distinguishedName:=*Evil*))), но кажется, что некоторые МФУ не принимают * в качестве подстановочного знака, но они принимают %

Answer 4

Согласно http://www.zytrax.com/books/ldap/apa/component.html, можно получить то, что вы хотите, используя компонентные фильтры LDAP. Вот пример, который будет соответствовать тому, что вы описываете:

(&(objectClass=organizationalUnit)(!(ou:dn:=Evil)))

Это соответствует всем объектам, которые имеют objectClass of OrganizationUnit, но отклоняет все, чье DN содержит компонент, который соответствует ou = Evil.

Answer 5

objectClasses organizationalUnit и его потомок inetOrgPerson позволяют атрибуту ou присутствовать в записи. Добавьте атрибут ou со значением evil к объектам, подчиненным ветви ou=evil, и включите утверждение (!(ou=evil)) в поисковый фильтр, чтобы ограничить ответы из списка кандидатов теми, которые не содержат атрибут ou со значением evil. В качестве альтернативы, LDAP Assertion Control может использоваться для запросов таким же образом, чтобы гарантировать, что запросы, содержащие ou со значением evil, не будут обработаны. Серверы каталогов профессионального качества, совместимые с LDAP, будут поддерживать оба этих метода.