好的，所以我第一次学习和configurationopenLDAP部分基于这个教程：
http://www.rjsystems.nl/en/2100-d6-openldap-provider.php
我想添加一个示例用户，但我想我注意到在教程中的一个types。 在例子ldif中，作者使用了cn: Christopher 。 我认为cn应该是一个较短的名称，类似于uid，如果不完全相同。 所以在我的ldif中，我同时设置了cn和gn （givenName），但是我得到了有关givenName的错误：
ldap_add: Object class violation (65) additional info: attribute 'givenName' not allowed
这是我的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
我如何修改我的ldif文件来正确设置'givenName'，因为它看起来像一个person应该能够有一个名字。 它毕竟需要sn 。
谢谢！！
更新所以我尝试使用inetOrgPerson ，其中包括一个给定的名称，但使用ldapsearch检查结果后，我看到以下内容：
givenName:: VGhvbWFzIA==
当它应该有我在ldif中使用的名字。 显然有什么事情发生，任何人都有一些洞察力？ 注意givenName后面的两个冒号。
恐怕RFC 2256及其后代在这里被指责：根据RFC，一个人没有给定名称，并且你的LDAP服务器（正确）拒绝让你分配该属性。
您有几个select：您可以使用cn （通用名称）作为名字，添加一个支持givenName的额外的ObjectClass（如inetOrgPerson），或者select一个不同的结构ObjectClass（像inetOrgPerson一样）将您的对象作为基础。
一般来说，inetOrgPerson是您想使用的“人”类对象类：它比vanilla LDAP人更有用。
更新Re：你的更新。 作为givenName结果的时髦string实际上是一个base-64编码的string（ VGhvbWFzIA== => Thomas ）。 大多数客户端将能够自动解码，我不知道为什么你没有（可能是一个configuration故障的地方）。
双冒号(::)表示提供的值是以base-64编码的。 在使用某些版本的旧版OpenLDAP ldapmodify工具时，经常会发生这种情况，特别是在属性值末尾包含空格时。 值的末尾不允许出现尾部空格，但是OpenLDAP ldapmodify没有注意到这一点，并且无论如何都将条目和违规属性发送到服务器，从而导致服务器正确地base64编码属性值。
我不知道你的例子是否属于这种情况，但这是可能的。 在ldapmodify上查看我的博客条目 。
你必须检查objectClass'person'是否包含属性'givenName'。 如果没有（可能是这种情况），请尝试用'inetOrgPerson'replace'person'。
当您尝试将属性分配给其中该属性不在该对象的任何ObjectClasses中的对象时引发的错误消息。 看起来gn没有在模式中为top ， person ， shadowAccount或posixAccount 。