LDAP: o atributo 'givenName' não é permitido

Question

OK, estou aprendendo e configurando o openLDAP pela primeira vez com base parcialmente neste tutorial:

link

Estou tentando adicionar um usuário de amostra, mas acho que notei um tipo no tutorial. No exemplo ldif, o autor usou cn: Christopher . Eu pensei que cn deveria ser um nome mais curto, semelhante ao uid, se não exatamente o mesmo. Então, no meu ldif, defino os dois cn e gn (givenName), mas estou recebendo um erro sobre o givenName:

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

Aqui está o meu 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

Como eu modificaria meu arquivo ldif para definir corretamente o 'givenName' porque parece que um person deveria ser capaz de ter um primeiro nome. Leva sn depois de tudo.

Obrigado !!

UPDATE Então, tentei usar inetOrgPerson , que inclui um determinado nome, mas depois de usar o ldapsearch para verificar os resultados, vejo o seguinte:

givenName:: VGhvbWFzIA==

Quando deveria ter o nome dado que eu usei no ldif. Obviamente, algo está acontecendo, alguém tem algum insight? Observe os dois dois pontos após givenName.

    

Answer 1

Eu tenho medo que RFC 2256 e seus descendentes sejam os culpados aqui: De acordo com a RFC, uma pessoa não tem um givenName e seu servidor LDAP está (corretamente) se recusando a permitir que você atribua esse atributo.
Você tem algumas opções: Você pode usar cn (nome comum) como apenas o primeiro nome, adicionar uma classe de objeto adicional (como inetOrgPerson) que ofereça givenName ou escolher uma ObjectClass estrutural diferente (como inetOrgPerson) para basear seu objeto em.

De modo geral, inetOrgPerson é a classe de objeto "pessoa" que você deseja usar de qualquer maneira: é muito mais útil do que a pessoa LDAP de baunilha.

Atualização Re: sua atualização. A string funky que você está obtendo como resultado para givenName é na verdade uma string codificada na base 64 ( VGhvbWFzIA== = > Thomas ). A maioria dos clientes poderá decodificá-lo automaticamente, não sei por que o seu não foi feito (provavelmente uma falha de configuração em algum lugar).

    

Answer 2

Os dois pontos duplos (::) indicam que o valor fornecido foi codificado na base 64. Isso pode acontecer com frequência quando se usam algumas versões da antiga ferramenta OpenLDAP ldapmodify , especialmente quando um espaço é incluído no final de um valor de atributo. Espaços à direita não são permitidos no final dos valores, mas o OpenLDAP ldapmodify não observa esse fato e envia a entrada e o atributo ofensivo para o servidor de qualquer maneira, com o resultado de que o servidor corretamente base64 codifica o valor do atributo. p>

Eu não sei se este é o caso no seu exemplo, mas é possível. Veja minha entrada de blog em ldapmodify.

    

Answer 3

Você precisa verificar se o objectClass 'person' inclui o atributo 'givenName'. Se isso não acontecer (o que provavelmente é o caso), tente substituir a 'pessoa' por 'inetOrgPerson'.

    

Answer 4

A mensagem de erro citada é lançada quando você tenta atribuir um atributo a um objeto em que esse atributo não está em nenhuma das ClassClasses desse objeto. Parece que gn não está definido no esquema de top , person , shadowAccount ou posixAccount .