Может ли LDAP_MATCHING_RULE_IN_CHAIN ​​возвращать «результаты поиска поддерева» с атрибутами (в частности, «memberOf»)? - PullRequest
Новая
       43

Может ли LDAP_MATCHING_RULE_IN_CHAIN ​​возвращать «результаты поиска поддерева» с атрибутами (в частности, «memberOf»)?

4 голосов
/ 30 марта 2012

У меня есть тестовый экземпляр Active Directory (AD) с вложенными группами: Сотрудники (Родитель) с двумя подгруппами: Руководители и Инженеры. 

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» содержит только «Executives», то есть группу, в которую он напрямую принадлежит. Я проверил все остальные атрибуты и не вижу ни одного «сотрудника»

Recap

Итак, для окончательного пояснения: разрешает ли AD какой-либо способ получения результатов "subtree memberOf" вместе с "subtree" LDAP_MATCHING_RULE_IN_CHAIN ​​("memberOf: 1.2.840.113556.1.4.1941: =") ищет

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

Ответы [ 3 ]

9 голосов
/ 31 марта 2012

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

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

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

Таким образом, поиск в каталоге состоит из:

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

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

Сейчас LDAP_MATCHING_RULE_IN_CHAIN.

Когда пользователь X является членом группы A. DN пользователя X находится в атрибуте участника группы 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) и область для base и использовать следующий запрос. 

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

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

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

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

2 голосов
/ 30 марта 2012

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

Измените ваш фильтр на: 

(&(objectClass=user)(memberof:1.2.840.113556.1.4.1941:=CN=Employees,CN=Users,DC=cloud,DC=com))
0 голосов
/ 27 июня 2017

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

У меня есть 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
...