3

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.

Improve this question

4 Answers 4

Reset to default
7

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

Improve this answer
3
  • I agree, but please see my update for my next problem. givenName doesn't appear to be stored correctly. I'll ask another question if need be...
    – Mr. Shickadance
    Jul 28, 2011 at 19:39
  • Aha, that makes sense, and is obviously correct since it includes my real name, not John Smith like used in the example.
    – Mr. Shickadance
    Jul 28, 2011 at 19:42
  • 1
    I believe (though I wouldn't swear to it) that the double-colon in your output is how LDIFs indicate Base64-encoded data -- Double-check the manual for your tools to be sure, and they'll probably tell you how to get human-readable output as well :-)
    – voretaq7
    Jul 28, 2011 at 19:48
3

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.

Improve this answer
1
  • Well I just checked my ldif file and sure enough there was a single space after the given name. I'll try and update it to see what happens.
    – Mr. Shickadance
    Jul 29, 2011 at 15:36
1

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'.

Improve this answer
1
0

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.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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