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

link|improve this question

72% accept rate
feedback

2 Answers

up vote 4 down vote accepted

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.

link|improve this answer
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
feedback

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
link|improve this answer
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.