4

У меня есть тестовый экземпляр Active Directory (AD) с вложенными группами: Employees (Parent) с двумя подгруппами: руководители и инженеры.Может ли LDAP_MATCHING_RULE_IN_CHAIN ​​возвращать «результаты поиска поддерева» с атрибутами (в частности, «memberOf»)?

Tree: 
    Employees 
    | 
    -Executives 
    | | 
    | -Mister Executive 
    | 
    -Engineers 
     | 
     -Joe Engineer 

Я вижу, что AD-расширение LDAP_MATCHING_RULE_IN_CHAIN ​​будет искать поддерево; Я могу найти всех пользователей, которые сотрудники с этим запросом:

query: 
(& (objectClass=person) (memberOf:1.2.840.113556.1.4.1941:=CN=Employees,CN=Users,DC=cloud,DC=com)) 

Проблема: рекурсивный поиск, но не Рекурсивный Результаты

Однако, я не могу найти способ, чтобы получить «результаты поиска поддерево », то есть, в то время как запрос возвращает« Mister Executive »как« Employee », атрибут« memberOf »содержит только списки« Руководители », то есть группу, к которой он непосредственно принадлежит. Я проверил все другие атрибуты и не вижу «работника»

резюмировать

Таким образом, для окончательного выяснения: действительно позволяет AD любого способа получить «SUBTREE memberOf» результаты наряду с «поддеревом» LDAP_MATCHING_RULE_IN_CHAIN ("memberOf: 1.2.840.113556.1.4.1941: =") ищет

заранее спасибо,

+0

Является ли основа вашего поиска корневой домен, или, по крайней мере, OU, где пользователи расположены? Ваш AD 2003 или 2008? Можете ли вы опубликовать весь блок поиска? – Daro

+0

Да, базовый поиск должен быть «пользователями OU». Я думаю, что это 2008 год (трудно сказать), но мы поддерживаем как 2003, так и 2008 год. Что касается «всего блока поиска». Я просто проверяю запрос в инструменте поиска LDAP - просто вставляя вышеуказанный запрос. Вы хотите получить результаты? – user331465

+0

Если вы посмотрите здесь: http://support.microsoft.com/kb/914828/en-us, вы видите, что вы хотите. Если вы комбинируете примеры 1 и 5, вы должны получить то, что хотите, если в 2003 году установлено исправление, или у вас есть AD AD 2008. – Daro

ответ

2

Я редактировал это потому, что перечисление не было необходимости ...

Chan ge Ваш фильтр:

(&(objectClass=user)(memberof:1.2.840.113556.1.4.1941:=CN=Employees,CN=Users,DC=cloud,DC=com)) 
8

Я думаю, что вы путаетесь между группами и узлами.

дерева каталогов

справочник это дерево, в котором каждый объект является узлом. Active-Directory немного особенный, поскольку только несколько объектов, таких как organizationalUnits (OU), Domains или Containers, могут быть узлами, содержащими пользовательские объекты.

Так поиск каталога состоит из:

  1. узла, который начинается поиск, с которой идентифицируется отличающим Именем (DN)
  2. The атрибутов объявления, которые вы хотите быть возвращены
  3. Глубины поиска (базовый, одноуровневый, поддерево)
  4. Фильтр.

Каждый объект в каталоге содержит атрибуты с именем и синтаксисом. Для некоторых атрибутов, таких как member, memberOf, manager, managedBy, Microsoft предоставляет специальный синтаксис, называемый uniqueName. Этот синтаксис относится к выделенному имени, но каталог предоставляет своего рода реляционную целостность для этих атрибутов. Это означает, что, например, если вы переместите объект в каталог, DN внутри этого атрибута сохранит свое значение. Если вы перемещаете пользователя, атрибут member в группы, к которому он принадлежит, настраивается автоматически.

LDAP_MATCHING_RULE_IN_CHAIN.

Когда пользователь X является членом группы A. Пользователь X DN находится в атрибуте члена группы A, DN группы A находится в атрибуте memberOf пользователя X. Если группа A является членом группы B , пользователь X принадлежит группе B, но DN группы B НЕ является атрибутом memberOf пользователя X. Здесь вы можете использовать LDAP_MATCHING_RULE_IN_CHAIN, чтобы найти рекурсивную принадлежность к группам. Это специальный оператор расширенного совпадения, который перемещает цепочку предков в объектах до корня до тех пор, пока не найдет совпадение.

Microsoft пример такого запроса - это тот, который предназначен для проверки того, является ли пользователь «user1» членом группы «group1». Вы должны установить базу для DN пользователя (cn = user1, cn = users, dc = x) и область для базы и использовать следующий запрос.

(memberOf:1.2.840.113556.1.4.1941:=cn=Group1,OU=groupsOU,DC=x) 

Аналогично, чтобы найти все группы, которые «User1» является членом, установить основание для групп контейнера DN; например (OU = groupsOU, dc = x) и область действия для поддерева, и использовать следующий фильтр.

(member:1.2.840.113556.1.4.1941:=cn=user1,cn=users,DC=x) 

Так LDAP_MATCHING_RULE_IN_CHAIN не имеет ничего общего с узлом дерева каталогов.

+0

Он хочет, чтобы все члены группы Сотрудники и все подгруппы. Его запрос был прекрасен. Он просто перепутал человека и пользователя (категория или класс). – Daro

+0

Это было красивое, кратким описанием того, что цепочка 'LDAP_MATCHING_RULE_IN_CHAIN' фактически проверяет. –

0

Если проблема, которую вы пытаетесь решить это:

Я имею потребителя DN и я хочу, чтобы найти все группы, к которым он/она принадлежит

То, что вы хотите использовать является вычисленным атрибутом tokenGroups, который содержит SID всех вычисленных групп пользователей, учитывающих наследование. Это то, что делают инструменты интеграции служб каталогов для максимальной надежности.

(смотри также tokenGroupsGlobalAndUniversal в соответствии с вашими потребностями)

○ → ldapsearch -o ldif-wrap=no -LLL -Y GSSAPI -H ldap://ad1.mdmarra.local -b 'CN=Michael Brown,OU=Employees,DC=mdmarra,DC=local' -s base memberOf tokenGroups 
dn: CN=Michael Brown,OU=Employees,DC=mdmarra,DC=local 
memberOf: CN=Staff,OU=Security Groups,DC=mdmarra,DC=local 
memberOf: CN=cloud_users,OU=Security Groups,DC=mdmarra,DC=local 
memberOf: CN=TACACS-NOC-Customer,OU=Security Groups,DC=mdmarra,DC=local 
memberOf: CN=TACACS-NOC,OU=Security Groups,DC=mdmarra,DC=local 
memberOf: CN=PRTG-Admins,CN=Users,DC=mdmarra,DC=local 
tokenGroups:: AQIAAAAAAAUgAAAAIQIAAA== 
tokenGroups:: AQUAAAAAAAUVAAAA2TH4QrS3zSIH5TsreSgAAA== 
tokenGroups:: AQUAAAAAAAUVAAAA2TH4QrS3zSIH5TsrQCgAAA== 
tokenGroups:: AQUAAAAAAAUVAAAA2TH4QrS3zSIH5Tsr7xkAAA== 
tokenGroups:: AQUAAAAAAAUVAAAA2TH4QrS3zSIH5Tsr+xkAAA== 
tokenGroups:: AQUAAAAAAAUVAAAA2TH4QrS3zSIH5TsrAQIAAA== 
tokenGroups:: AQUAAAAAAAUVAAAA2TH4QrS3zSIH5TsrcRIAAA== 
tokenGroups:: AQUAAAAAAAUVAAAA2TH4QrS3zSIH5Tsr7ScAAA== 
tokenGroups:: AQUAAAAAAAUVAAAA2TH4QrS3zSIH5Tsr8BkAAA== 
tokenGroups:: AQUAAAAAAAUVAAAA2TH4QrS3zSIH5Tsr8RkAAA== 
tokenGroups:: AQUAAAAAAAUVAAAA2TH4QrS3zSIH5Tsr9hkAAA== 
tokenGroups:: AQUAAAAAAAUVAAAA2TH4QrS3zSIH5TsrWigAAA== 
tokenGroups:: AQUAAAAAAAUVAAAA2TH4QrS3zSIH5TsrWygAAA== 
tokenGroups:: AQUAAAAAAAUVAAAA2TH4QrS3zSIH5Tsr7hkAAA== 
tokenGroups:: AQUAAAAAAAUVAAAA2TH4QrS3zSIH5Tsr+RkAAA== 

○ → ldbsearch -k yes -H ldap://ad1.mdmarra.local -b 'CN=Michael Brown,OU=Employees,DC=mdmarra,DC=local' -s base memberOf tokenGroups 
… 
memberOf: CN=PRTG-Admins,CN=Users,DC=mdmarra,DC=local 
tokenGroups: S-1-5-32-545 
tokenGroups: S-1-5-21-1123561945-583907252-725345543-10361 
tokenGroups: S-1-5-21-1123561945-583907252-725345543-10304 
tokenGroups: S-1-5-21-1123561945-583907252-725345543-6639 
tokenGroups: S-1-5-21-1123561945-583907252-725345543-6651 
tokenGroups: S-1-5-21-1123561945-583907252-725345543-513 
tokenGroups: S-1-5-21-1123561945-583907252-725345543-4721 
tokenGroups: S-1-5-21-1123561945-583907252-725345543-10221 
tokenGroups: S-1-5-21-1123561945-583907252-725345543-6640 
tokenGroups: S-1-5-21-1123561945-583907252-725345543-6641 
tokenGroups: S-1-5-21-1123561945-583907252-725345543-6646 
tokenGroups: S-1-5-21-1123561945-583907252-725345543-10330 
tokenGroups: S-1-5-21-1123561945-583907252-725345543-10331 
tokenGroups: S-1-5-21-1123561945-583907252-725345543-6638 
tokenGroups: S-1-5-21-1123561945-583907252-725345543-6649 

 Смежные вопросы

  • Нет связанных вопросов^_^