Hi,
I'm still finding my feet in LDAP and LDIFs but I've been led to think entries such as these were 'corruptions' :
cisSetting:: Ym0ubmV3QGRl userPassword:: eXZxZDJkbHk= dn:: AGNuPWRzdnIwMDAwLG91PUF
I don't know about NS Dir., but, in OpenLDAP, those represent values that are already server-encrypted. It's how the server differentiates between:
userPassword: mypasswordintheclear
userPassword: {md5}anmd5hash
userPassword:: base64alreadyserverencryptedpasswordLDIF, including various techniques for resolving the corrupt double colon entries.
That might not be such a good thing.
After a successful ldapadd into my provider, verifying my fixed LDIF is syntactically sound, and successful syncrepl to my consumer (including resolution of ITS#3546 using OPENLDAP_REL_ENG_2_2 cvs) I decided to have a look at a slapcat. To my astonishment, I've found many entries such as quoted above.
Yep.
Things to note: *all* userPassword entries are double colon entries in the LDIF - they are infact plaintext at this point, visible in gq. Not all cisSettings are double colon entries, and those that are render in plain text in gq. They render as above with ldapsearch. The dn's I haven't checked out as they are clearly not human readable.
That's the opposite of what I would expect and the opposite of the behavior on my system, although I'm not using the cisSettings attribute, but the userPassword attribute behaves as I described above.
Can someone clarify whether the above is 'normal' or not? I'm beginning to think they are encoded in some way, however why would gq render them in plaintext, yet slapcat and ldapsearch render them in this way? What does the double colon signify? Perhaps the NSD LDIF isn't as corrupt as we thought?
I'm not familiar with gq, so, I can't answer that question.
I'm still pretty new to this myself, but, that's been my experience so far.
Owen
-- If it wasn't crypto-signed, it probably didn't come from me.
Attachment:
pgpo5XDlZwXoB.pgp
Description: PGP signature