Home / server / Questions / 316440
Accepted
Jason S
Asked: 2011-09-29 07:53:05 +0800 CST

LDAP: entries for services?

  • 772

(Apologies if I've got the terminology wrong, I'm fairly new to LDAP)

I am setting up a local LDAP server (Apache Directory Server) with the following structure:

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]
    ...

I also set up some basic authorization according to the manual.

Everything works great.

Now I have an issue. I have another server running Atlassian Crowd that needs access to this LDAP, and I would like to give that service its own LDAP authorization entry, to partition access rights. But it's not a user, it's a service.

What objectClass is used for service identities?

(and as a newbie to LDAP, how do you find out that groupOfUniqueNames is used for groups, inetOrgPerson is used for user entries? That seems to be the norm.)

ldap authorization apache-ds

3 Answers

  1. Best Answer

    What objectClass is used for service identities?

    Whatever you want, really. In order for Crowd (or anything else) to authenticate, you need a distinguished name somewhere in your tree and it needs to have a userPassword attribute.

    If you look at your schema (if you're using OpenLDAP, that's usually /etc/openldap/schema), you can find objectClasses that meet this criteria.

    The simplest is probably the person object class, the definition for which looks like this:

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

    That says that it requires the sn and cn attributes, and may optionally have a userPassword attribute (as well as a few others). So maybe you would add an entry like this:

    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

    This presumes that you have a serviceAccounts OU where you will place this sort of thing, which is probably a good idea (because this clearly separates service accounts from user accounts).

    Crowd would authenticate as cn=crowd,ou=serviceAccountrs,o=myOrganization, and you would need to configure your LDAP directory to give this DN the appopriate access permissions.

    • 11

  2. RFC 2256 / RFC 4519 recommends objectClass: applicationProcess for this sort of thing:

    The 'applicationProcess' object class definition is the basis of an entry that represents an application executing in a computer system.

    Relevant attributes: cn (required), seeAlso, ou, l, and description (optional).

    One advantage of using cn instead of uid for the RDN is that service accounts won't be mistakenly matched as user accounts if you're using something like ldap_filter: (uid=%U) as the user lookup query.

    • 8

  3. I use object classes account (structural) and simpleSecurityObject (auxiliary) for service accounts. This way the service account has a uid and a userPassword, both of which are good to have when doing authentication and authorization.

    dn: uid=kerberos,ou=services,dc=example,dc=com
objectClass: account
objectClass: simpleSecurityObject
objectClass: top
uid: kerberos
userPassword: {SSHA}xxxxxxxxxx
    • 6