Okay, I don't understand. 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? I don't want it to be stored that way. 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. 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: uid=userX,ou=People,dc=thisdomain,dc=net 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 > > client. > > 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 > general. > > Ciao, Michael. -- Kevin Graham System Administrator Advance Internet
