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