Подтвердить что ты не робот

Как обычно выполняются вложенные группы в LDAP?

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

Как работают вложенные группы?

Я могу понять, что ou (организационная единица), и я могу понять, как помещать людей в них, и использовать класс groupOfNames для работы в качестве контейнера для членов, например, этот фрагмент LDIF из zytrax:

    # create FIRST Level groups branch

    dn: ou=groups,dc=example,dc=com
    objectclass:organizationalunit
    ou: groups
    description: generic groups branch

    # create the itpeople entry under groups

    dn: cn=itpeople,ou=groups,dc=example,dc=com
    objectclass: groupofnames
    cn: itpeople
    description: IT security group
    member: cn=William Smith,ou=people,dc=example,dc=com

    # create the hrpeople entry under groups

    dn: cn=hrpeople,ou=groups,dc=example,dc=com
    objectclass: groupofnames
    cn: hrpeople
    description: Human Resources group
    member: cn=Robert Smith,ou=people,dc=example,dc=com

Как бы добавить дополнительные уровни вложенности?

То, что мне нужно, это что-то вроде этого псевдокода:

ou='Projects' /
description: This top level group has a few people in it that can create new groups, and control who in them
member: cn=Robert Smith,ou=people,dc=example,dc=com

    -- somethingsomethingAbitrarilyNestedGroup='project-name'
        member: cn=Robert Smith,ou=people,dc=example,dc=com

        -- groupOfNames = 'project-name development'
            member: cn=Robert Smith,ou=people,dc=example,dc=com
            member: cn=Jane Doe,ou=people,dc=example,dc=com
            member: cn=server1$,ou=servers,dc=example,dc=com

        -- groupOfNames = 'project-name staging'
            member: cn=Jane Doe,ou=people,dc=example,dc=com
            member: cn=server2$,ou=servers,dc=example,dc=com

Учитывая эту иерархию, какой лучший способ предоставить доступ к этой группе сейчас?

Я не вижу простого способа выполнить произвольное группирование групп - среди обычных классов, доступных без использования дорогостоящего инструмента с закрытым исходным кодом, но похоже, что он не должен быть таким сложным.

Как это обычно делается с помощью такого инструмента, как OpenLDAP, чтобы другие клиенты ldap контролировали членство в группе, когда они аутентифицируются как пользователь с правильными правами?

4b9b3361

Ответ 1

Ваш вопрос немного смущен - я не уверен, что вы имеете в виду "лучший способ предоставить доступ к этой группе сейчас" в контексте начальных нескольких абзацев.

Вложенные группы мертвы просто. Если вы используете objectClass groupOfNames, просто добавьте еще один атрибут member в свою родительскую группу, причем значение будет DN дочерней группы.

Из вашего псевдокода:

# Assuming your "groups" OU already exists...
# First create the child groups

dn: cn=project-name development,ou=groups,dc=example,dc=com
objectclass: groupofnames
cn: project-name development
member: cn=Robert Smith,ou=people,dc=example,dc=com
member: cn=Jane Doe,ou=people,dc=example,dc=com
member: cn=server1$,ou=servers,dc=example,dc=com

dn: cn=project-name staging,ou=groups,dc=example,dc=com
objectclass: groupofnames
cn: project-name development
member: cn=Jane Doe,ou=people,dc=example,dc=com
member: cn=server2$,ou=servers,dc=example,dc=com

# Now create the parent group
dn: 'project-name,ou=groups,dc=example,dc=com'
objectclass: groupofnames
member: cn=Robert Smith,ou=people,dc=example,dc=com
member: cn=project-name staging,ou=groups,dc=example,dc=com
member: cn=project-name development,ou=groups,dc=example,dc=com

Hiearchy в подразделениях действительно только для того, чтобы разделить дерево LDAP на "логические" сегменты на основе структуры вашей организации. Так, например, вы можете использовать все свои группы для управления "Департаментом развития" в своем собственном подразделении, поэтому хорошо и понятно, что они имеют. Объекты могут ссылаться друг на друга и гнездиться довольно счастливо, ссылаясь друг на друга с соответствующими атрибутами (в данном случае member).

Ответ 2

Я считаю, что при ссылке на пользовательские объекты вы должны использовать uid=, а не cn=

Проблема с группами вложенности состоит в том, что многие приложения, которые могут ссылаться на группу, не знакомы с поиском вложенных групп для объектов-членов.