[Fedora-directory-users] FDS: Error in encoding and attribute deletion

[Michael Ströder]

Kevin Graham wrote:
> Okay, I don't understand.

Okay, I will try again. ;-)

> Here is the listing of the entry in question, using ldapsearch
> 
> uniqueMember: uid=user2,ou=People,dc=thisdomain,dc=net
> uniqueMember:: dWlkPW1xxxxxxxG8sb3U9UGVvcGxlLGRjPWFkdmFuY2XXXXXXXdUs==
> 
> (i've changed it a little, because it's sensitive)
> 
> that appears when I search for cn=tech,ou=Groups,dc=thisdomain,dc=net
> 
> why would the one entry be returned as base64 encoded, when the others
> aren't?

Because most likely it contains NON-ASCII chars (in the DN?). I can't 
check since Python's base64.decodestring() fails on your example above 
with "binascii.Error: Incorrect padding".

>  I don't want it to be stored that way.

It is not stored in the directory that way. It's just base64-encoded in 
the LDIF format which is the output format of command-line tool ldapsearch.

> When I use a tool, like ldapvi, or ldapmodify, and delete, then re-add
> the entry:
> 
> 'uniqueMember: uid=userX,ou=People,dc=thisdomain,dc=net' (no trailing
> space,one colon)
> 
> then do a search for userX, nothing appears. 

Please elaborate what "search for userX" means for you. Maybe post a 
search filter?

> The strange thing is when
> I look at the entry in say ADs, or jxplorer, it appears as uid=userX...
> but with a trailing space.

Maybe you should try to modify this attribute with jxplorer?

>  I have made sure anytime I've re-added the
> entry that there is never a '::' or a trailing space.  I've even used
> ADs, and phpldapadmin, and jxplorer to do the delete->add->check cycle 
> and always end up with the same result.

Maybe FDS adds the trailing space because attribute 'uniqueMember' is of 
LDAP syntax 'Name And Optional UID' (OID 1.3.6.1.4.1.1466.115.121.1.34) 
which is not only a DN (and this particular syntax is considered to be 
flawed anyway).

Ciao, Michael.