Можно ли выделить одного пользователя (запись) под двумя разными подразделениями (организационной единицей) в OpenLDAP? - PullRequest
Новая
       47

Можно ли выделить одного пользователя (запись) под двумя разными подразделениями (организационной единицей) в OpenLDAP?

1 голос
/ 15 июля 2011

Я планирую структуру нового сервера OpenLDAP, чтобы интегрировать его с Moodle.

Я думал о следующей структуре:

  • O = НазваниеКомпании
    • OU = ProjectName
      • UID = UserID001
      • UID = UserID002
      • UID = UserID003
    • OU = ProjectName
      • UID = UserID002

Обратите внимание, что один и тот же пользователь 'uid = UserID002' может быть выделен в одном или нескольких проектах. Это упростит синхронизацию между программным обеспечением и LDAP.

Возможно ли это сделать с помощью OpenLDAP? Я слышал, что IBM LDAP это позволяет, правда? Есть ли какая-нибудь «символическая ссылка» на запись?

Ответы [ 3 ]

1 голос
/ 15 июля 2011

Некоторые серверы каталогов поддерживают понятие уникальности атрибутов, вплоть до наличия плагина для уникальности uid. Вам следует связаться с администратором сервера каталогов, чтобы определить, поддерживают ли ваши локальные службы каталогов понятие уникальности атрибута, и если это так, является ли уникальность атрибута, настроенная для атрибута uid.

Что касается общей концепции уникальности именования атрибутов, то в вашей идее нет ничего, что не должно поддерживаться сервером каталогов профессионального качества, который поддерживает группу стандартов LDAP. uid - это просто атрибут, и в вашем примере в этом нет ничего особенного, кроме того, что он становится компонентом относительного отличительного имени. Объект, который идентифицирует запись на сервере каталогов, является отличительным именем, uid является атрибутом, как и любой другой.

Согласно RFC4512 , LDAP поддерживает понятие псевдонимов, но эта функциональность не должна использоваться в вашем случае.

1 голос
/ 17 апреля 2015

Лучше всего использовать оверлей memberOf.

Вы используете класс объектов groupOfNames (который уже существует), чтобы указать членов, которые будут принадлежать записи проекта, используя атрибут member.Вы можете добавить столько атрибутов member, сколько захотите, где каждый атрибут участника является (полным) DN.

Лично я бы создал свой собственный objectClass (например, с именем project), который расширил класс groupOfNames, чтобы я мог добавить к нему дополнительные атрибуты, связанные с проектом.Но зависит от того, насколько сложным вы хотите стать.

Затем вы переопределите свою структуру следующим образом ...

  • O = CompanyName
    • OU = People
      • uid = UserID001
      • uid = UserID002
      • uid = UserID003
    • OU = Проекты
      • cn = ProjectName
      • cn = ProjectName ...

Это сделает вашу структуру намного чище и с элементами проекта (например, cn =ProjectName) хранится отдельно от ваших пользовательских записей.Элементами проекта будут ваши классы groupOfNames, которые содержат атрибуты участников для людей в классе OU = People (например, member: uid=UserID001,OU=People,O=CompanyName).

Что будет делать оверлей memberOf при установке в ваш olap, добавитдополнительный атрибут под названием member of к вашим результатам поиска ldap (он генерируется динамически).

Это довольно распространенное наложение, которое используется и даже используется серверами AD, поэтому этот метод обычно используется, и вы может обнаружить, что Moodle их поймет.

Небольшая вещь, на которую следует обратить внимание при тестировании вашей установки .... ldapsearch запросы не будут показывать атрибут memberof по умолчанию, поэтому вам нужно будет специально запросить его.например;

ldapsearch -Y EXTERNAL -H ldapi:/// "(objectClass=groupOfNames)" uid, memberof

Тот озадачил меня, когда я впервые начал их использовать.Я думаю, что есть опция «все», которая заставит поиск показывать скрытые атрибуты, но не может думать, что это в данный момент.Проверьте man страниц ldapsearch.

В любом случае, надеюсь, что это поможет ..:)

1 голос
/ 15 июля 2011

Вы можете сделать это с помощью псевдонимов LDAP достаточно легко, но общая идея в этих случаях заключается в использовании схемы, такой как organizationalRole, для узлов проекта. organizationalRole имеет многозначный атрибут roleOccupant , , которые являются DN записей, занимающих роль ... вместо создания целого леса подконтекстов в каждом проекте. Таким образом, вы просто ищете в каждом проекте или во всех них (roleOccupant={0}), где {0} предоставляется в качестве DN, который вы проверяете.

...