Home / server / Questions / 295200
Accepted
Mr. Shickadance
Asked: 2011-07-29 11:21:41 +0800 CST

LDAP: attribute 'givenName' is not allowed

  • 772

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.

ldap openldap

4 Answers

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

    • 7

  2. The double colons (::) indicate that the value provided was base-64 encoded. This can often happen when using some versions of the older OpenLDAP ldapmodify tool, especially when a space is included at the end of an attribute value. Trailing spaces are not allowed at the end of values, but the OpenLDAP ldapmodify fails to note this fact and sends the entry and the offending attribute to the server anyway, with the result that the server correctly base64 encodes the attribute value.

    I do not know if this is the case in your example, but it is possible. See my blog entry on ldapmodify.

    • 3

  3. You have to check if the objectClass 'person' includes the attribute 'givenName'. If it doesn't (which is probably the case), try replacing the 'person' with 'inetOrgPerson'.

    • 1

  4. The error message you cite is thrown when you attempt to assign an attribute to an object where that attribute is not in any of that object's ObjectClasses. It would seem that gn is not defined in the schema for any of top, person, shadowAccount, or posixAccount.

    • 0