LDAP: entries for services?

Question

(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.)

score 11 · Accepted Answer · answered Sep 28 '11 at 16:30

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.

You could of course create a custom object class for this if you wanted, but I don't think that's the best course of action. — larsks, Sep 28 '11 at 16:30
re: serviceAccounts -- yeah, I was thinking along those lines. Thanks for your help, it provides some enlightenment. — Jason S, Sep 28 '11 at 18:35

score 8 · Answer 2 · answered May 21 '19 at 17:58

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.

score 6 · Answer 3 · answered Nov 13 '11 at 02:44

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

LDAP: entries for services?

3 Answers3