Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
add comment

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.

share|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
add comment

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
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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