I am having a very unusual error on FDS version 1.0.3.
When we use ldapsearch to search for certain attributes we are getting results back scrambled.
Upon further investigation we found that the 'scrambled' entries were the intended entries just base64 encoded. Normally we'd expect the results back in ascii of course.
The strange thing is that no matter how many times, and with any client application, trying to fix the attribute results in no change.
Deleting the attribute will delete it, but when we re-add the attribute, (checked for things like trailing spaces.), the entry will reappear as the base64 entry (with a trailing space when translated back.)
It just appears 'stuck' and will not change to the intended text.
Any help or pointers on this would be appreciated.
Kevin Graham wrote:
I am having a very unusual error on FDS version 1.0.3.
When we use ldapsearch to search for certain attributes we are getting results back scrambled.
Upon further investigation we found that the 'scrambled' entries were the intended entries just base64 encoded. Normally we'd expect the results back in ascii of course.
The strange thing is that no matter how many times, and with any client application, trying to fix the attribute results in no change.
Deleting the attribute will delete it, but when we re-add the attribute, (checked for things like trailing spaces.), the entry will reappear as the base64 entry (with a trailing space when translated back.)
It just appears 'stuck' and will not change to the intended text.
Any help or pointers on this would be appreciated.
Could you double check your data to be added? This might be happening. http://www.faqs.org/rfcs/rfc2849.html RFC 2849 - The LDAP Data Interchange Format (LDIF)
8) Values or distinguished names that end with SPACE SHOULD be base-64 encoded.
Hi, we've checked that.
The problem we're having is when we try to correct the entry using any client.
We'd delete the entry, then try to re-add it; checking for the trailing space. Then when we go to look at the entry again, the attribute has the trailing space, and in ldapsearch comes back as base64.
It's a uniqueMember attribute so it's supposed to be ascii.
It's perplexing.
On Thu, 2008-05-01 at 09:48 -0700, Noriko Hosoi wrote:
Kevin Graham wrote:
I am having a very unusual error on FDS version 1.0.3.
When we use ldapsearch to search for certain attributes we are getting results back scrambled.
Upon further investigation we found that the 'scrambled' entries were the intended entries just base64 encoded. Normally we'd expect the results back in ascii of course.
The strange thing is that no matter how many times, and with any client application, trying to fix the attribute results in no change.
Deleting the attribute will delete it, but when we re-add the attribute, (checked for things like trailing spaces.), the entry will reappear as the base64 entry (with a trailing space when translated back.)
It just appears 'stuck' and will not change to the intended text.
Any help or pointers on this would be appreciated.
Could you double check your data to be added? This might be happening. http://www.faqs.org/rfcs/rfc2849.html RFC 2849 - The LDAP Data Interchange Format (LDIF)
- Values or distinguished names that end with SPACE SHOULD be base-64 encoded.
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.
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 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.
389-users@lists.fedoraproject.org
-
Kevin Graham -
Michael Ströder -
Noriko Hosoi