(Прошу прощения, если я неправильно понял терминологию, я новичок в LDAP)
Я настраиваю локальный сервер LDAP (сервер каталогов Apache) со следующей структурой:
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 для разделения прав доступа. Но это не пользователь, это служба.
Какой объектный класс используется для удостоверений службы?
(и как новичок в LDAP, как узнать, что groupOfUniqueNames используется для групп, inetOrgPerson используется для пользовательских записей? Это кажется нормой.)
Какой объектный класс используется для удостоверений службы?
Все, что вы хотите, правда. Чтобы 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