Как использовать фильтр, чтобы избежать суб-OU в Active Directory?

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

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

Хотел

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

Нежелательный

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

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


active-directory ldap
person DrStalker    schedule 08.07.2009    source источник

Ответы (5)


arrow_upward
13
arrow_downward

Если вы используете _1 _ (_ 2_) в .NET, вы можете установить SearchScope на OneLevel для поиска только в People-OU (без дочерних OU). Но это не сработает, если у вас есть _5 _...

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

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

person Per Noalt    schedule 12.07.2009
comment
A для усилий, но поиск с использованием подстановочных знаков не работает с данными типа DN, в частности distinguishedName. - person Anton Tykhyy; 26.04.2010
comment
Удалил первый неверный вариант, оставил два других варианта. - person Per Noalt; 16.04.2012

arrow_upward
8
arrow_downward

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

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

person esk    schedule 13.01.2017
comment
Это верно. Active Directory не поддерживает расширяемое сопоставление: msdn.microsoft.com/en-us/ библиотека / cc223241.aspx - person trebor; 13.08.2018

arrow_upward
6
arrow_downward

Следующее поможет:

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

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

person Louis Reedijk    schedule 26.01.2016
comment
Работал у меня. Если у вас есть кратные, которые вы хотите исключить, вы также можете сделать что-то вроде (objectClass=user)(!(|(distinguishedName:=*Evil*)(distinguishedName:=*Neutral*)))). - person KGlasier; 29.01.2019

arrow_upward
3
arrow_downward

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

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

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

person Ben Klang    schedule 09.07.2014

arrow_upward
1
arrow_downward

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

person Terry Gardner    schedule 13.08.2011