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

У меня есть приложение, которое извлекает информацию пользователя из OU в Active Directory. Параметры, которые он принимает, являются базой для поиска и строкой фильтра.

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

Требуются

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

Не требуется

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

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

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

Это соответствует всем объектам, у которых есть objectClass организацииUnit, но отклоняет все, чье DN содержит компонент, который соответствует ou = Evil.

Ответ 3

Следующее выполнит трюк:

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

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

Ответ 4

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

Ответ 5

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

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