LDAP: attribute ‘givenName’ is not allowed

ldapopenldap

OK, so I am learning and configuring openLDAP for the first time based partly on this tutorial:

http://www.rjsystems.nl/en/2100-d6-openldap-provider.php

I am trying to add a sample user, but I think I noticed a type in the tutorial. In the example ldif the author used cn: Christopher. I thought that cn should be a shorter name, similar to the uid if not exactly the same. So in my ldif I set both cn and gn (givenName), but I am getting an error about the givenName:

ldap_add: Object class violation (65)
    additional info: attribute 'givenName' not allowed

Here is my ldif:

dn: cn=tarcuri,ou=groups,dc=example,dc=com
cn: jsmith
gidNumber: 20000
objectClass: top
objectClass: posixGroup

dn: uid=tarcuri,ou=people,dc=example,dc=com
uid: jsmith
uidNumber: 20000
gidNumber: 20000
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
cn: jsmith
gn: John 
sn: Smith
loginShell: /bin/bash
homeDirectory: /home/jsmith
userPassword: john

How would I modify my ldif file to correctly set the 'givenName' because it seems like a person should be able to have a first name. It takes sn after all.

Thanks!!

UPDATE So I tried using inetOrgPerson, which includes a given name, but after using ldapsearch to check the results, I see the following:

givenName:: VGhvbWFzIA==

When it should have the given name I used in the ldif. Obviously something is happening, anyone have some insight? Note the two colons after givenName.

Best Answer

I'm afraid RFC 2256 and its descendants are to blame here: Per the RFC a person doesn't have a givenName, and your LDAP server is (correctly) refusing to let you assign that attribute.
You have a few options: You can use cn (common name) as just the first name, add an additional ObjectClass (like inetOrgPerson) that supports givenName, or chose a different structural ObjectClass (again, like inetOrgPerson) to base your object on.

Generally speaking inetOrgPerson is the "person"-like object class you want to use anyway: It's much more useful than the vanilla LDAP person.

Update Re: your update. The funky string you're getting as the result for givenName is actually a base-64 encoded string (VGhvbWFzIA== => Thomas). Most clients will be able to decode this automatically, I'm not sure why yours didn't (probably a configuration glitch somewhere).

Related Topic