LDAP: записи для сервисов?

(Извините, если я неправильно понял терминологию, я довольно новичок в LDAP)

Я настраиваю локальный сервер LDAP (Apache Directory Server) со следующей структурой:

o={my organization name} [objectClass=organization]
  ou=groups [objectClass=organizationalUnit]
    cn=someGroup [objectClass=groupOfUniqueNames]
    cn=otherGroup [objectClass=groupOfUniqueNames]
    ...
  ou=users [objectClass=organizationalUnit]
    cn=user1 [objectClass=inetOrgPerson]
    cn=user2 [objectClass=inetOrgPerson]
    cn=user3 [objectClass=inetOrgPerson]
    ...

Я также настроил некоторые основные авторизации в соответствии с руководством.

Все отлично работает.

Теперь у меня есть проблема. У меня есть другой сервер под управлением Atlassian Crowd, которому нужен доступ к этому LDAP, и я хотел бы предоставить этой службе свою собственную запись авторизации LDAP для разделения прав доступа. Но это не пользователь, это сервис.

Какой objectClass используется для идентификаторов служб?

(и как новичок в LDAP, как вы узнаете, что groupOfUniqueNames используется для групп, inetOrgPerson используется для записей пользователей? Это кажется нормой.)

Источник

3 ответа

Решение

Какой objectClass используется для идентификаторов служб?

Все, что вы хотите, на самом деле. Чтобы Crowd (или что-то еще) проходило аутентификацию, вам нужно отличительное имя где-то в вашем дереве, и оно должно иметь userPassword приписывать.

Если вы посмотрите на свою схему (если вы используете OpenLDAP, это обычно/etc/openldap/schema), вы можете найти объектные классы, которые соответствуют этому критерию.

Самое простое, вероятно, person Класс объекта, определение которого выглядит так:

objectclass ( 2.5.6.6 NAME 'person'
        DESC 'RFC2256: a person'
        SUP top STRUCTURAL
        MUST ( sn $ cn )
        MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

Это говорит о том, что это требует sn а также cn атрибуты, и может иметь userPassword атрибут (а также несколько других). Так что, возможно, вы бы добавили такую ​​запись:

dn: cn=crowd,ou=serviceAccounts, o=myOrganization
objectClass: person
cn: crowd
sn: Service Account
description: Service account for Crowd access to LDAP
userPassword: {SSHA}MZO/eoDUg/nFJDAZBvawCRYIxSeQUm3U

Это предполагает, что у вас есть serviceAccounts OU, где вы будете размещать такие вещи, что, вероятно, является хорошей идеей (потому что это четко отделяет учетные записи служб от учетных записей пользователей).

Толпа будет аутентифицироваться какcn=crowd,ou=serviceAccountrs,o=myOrganizationи вам необходимо настроить каталог LDAP, чтобы дать этому DN соответствующие права доступа.

Источник

RFC 2256 / RFC 4519 рекомендует objectClass: applicationProcess для такого рода вещей:

Определение класса объекта applicationProcess является основой записи, которая представляет приложение, выполняемое в компьютерной системе.

Соответствующие атрибуты: cn (требуется), seeAlso, ou, l, а также description (необязательный).

Одно из преимуществ использования cn вместо uid для RDN учетные записи служб не будут ошибочно сопоставляться с учетными записями пользователей, если вы используете что-то вроде ldap_filter: (uid=%U) как пользовательский поисковый запрос.

Источник

Я использую классы объектов account (структурный) и simpleSecurityObject (вспомогательный) для служебных учетных записей. Таким образом, учетная запись службы имеет uid и userPasswordИ то, и другое хорошо иметь при аутентификации и авторизации.

dn: uid=kerberos,ou=services,dc=example,dc=com
objectClass: account
objectClass: simpleSecurityObject
objectClass: top
uid: kerberos
userPassword: {SSHA}xxxxxxxxxx
Источник
Другие вопросы по тегам