Fedora directory users - May 2008 - FDS: Error in encoding and attribute deletion

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
System Administrator
Advance Internet
031589182

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)
> 
> 8)  Values or distinguished names that end with SPACE SHOULD be base-64
encoded.
> 
> 
-- 
Kevin Graham
System Administrator
Advance Internet

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
System Administrator
Advance Internet

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.