Okay, I don't understand.
Here is the listing of the entry in question, using ldapsearch
(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? I don't want it to be stored that way.
When I use a tool, like ldapvi, or ldapmodify, and delete, then re-add
'uniqueMember: uid=userX,ou=People,dc=thisdomain,dc=net' (no trailing
then do a search for userX, nothing appears. 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. 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.
I know the letters/numbers are the base64 encoded string I want returned
(with a space after it.) I just can't get that one entry to behave like
the other attributes. I add it the same exact way I do the other
entries in the same group.
Why would the directory server think that I want a uniqueMember
attribute encoded/stored as a base64 string when I don't tell it to do
that, or return the entry as one. I just want the directory server to
return the entry as uniqueMember:
so when I search for it, it is there.
Maybe it was added as a base64 originally, and I just can't update,
remove the record? I really think it might be something with the
backend? Is there a way to check that?
Thank You for your help/.
On Thu, 2008-05-01 at 22:19 +0200, Michael Ströder wrote:
Kevin Graham wrote:
> The problem we're having is when we try to correct the entry using any
It's simply valid LDIF like Noriko already told you. A double colon
after attribute type name indicates that you have to base64-decode the
attribute value. If you want to process LDIF then use a decent LDIF
parser. This has not necessarily to do with the attribute values. It
would also be valid data encoded in valid LDIF if all attributes are
base64-encoded in lines attrType:: attrValue.
> It's a uniqueMember attribute so it's supposed to be ascii.
No, it's not supposed to be ASCII at least since it contains DNs which
can be UTF-8. Maybe in your case it's supposed to be ASCII but not in