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.
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
