[Fedora-directory-users] userPassword is base64 encoded

[jclowser at unitedmessaging.com]

This is from memory from looking at this as the Netscape/Sun Directory 
server, so I'm troubleshooting it as if you were using that, assuming 
FDS is the same :)

The password is not actually stored in Base64 in the directory - the 
base64 is a function of ldapsearch.  I.e. if ldapsearch sees an 
attribute that it _thinks_ is a binary attribute, it base64 encodes it 
to output in LDIF, since LDIF is a text format, and the raw binary data 
is not appropriate.

Different versions of ldapsearch do this differently, and I'm not sure 
what criteria it uses to determine if an attribute is binary.  The Sun 
version of ldapsearch displays it as normal text, while the openldap 
version of ldapsearch displays it as base64 encoded.  If you are on 
linux and have the openldap client package installed, that is probably 
what you are running, I'd guess.  If you can search the Fedora DS using 
ldapsearch on a Sun box, my guess is you will see it _not_ base64 
encoded.  If you export it with tools like db2ldif, I don't think you'll 
see it as base64 encoded.

My guess is that there is a Samba/Directory ACI issue that is really the 
cause here.  Look in the FDS logs - look at the access logs:

1.  grep on MOD and the IP of your samba box.  That will show you modify 
requests coming from the samba box.  In these lines, there should be a 
conn=XXXX, where XXXX is a connection number.
2.  grep on "conn=XXXX" to find all access coming from that connection 
by samba.

 From that, look for BIND lines, to see what samba is binding as, and 
look for MOD lines to see where it is trying to modify the password.  
Look at the line after that for the result code.  Lookup that number 
(search for ldap result codes on google to find complete lists).  If the 
result is 50, that means insufficient access - likely an aci or samba 
config problem.  From the BIND line(s), see what samba is binding as.  
Check that this is what samba is supposed to bind as (i.e. if samba 
binds as anonymous and tries to change the password, that is bad).  
Review your directory aci's to see if appropriate access controls are there.

Generally, for binding to the directory, apps can do this one of 2 
ways:  1 is that the app connects to the directory server and attempts 
to bind as the user.  2 is that they can bind to the directory, retrieve 
the users password, and try to match what it expects.  #2 is bad for a 
lot of reasons:  the password is sent to the app - even in encrypted 
form, it's bad security; apps have to understand the format the password 
is in in the directory; etc.  However, some apps do this, unfortunately 
- many of the early unix/linux name service plugins used this (maybe 
still do?), because the underlying unix calls required this to be 
returned, and it expected it in crypt format...

If samba (or whatever) uses method #2, you may have to match that format 
in your directory.  Sun/Netscape directory server (and presumably FDS) 
allows you to write the password to the server as plaintext (i.e. 
userpassword: plaintextpassword in ldif), but once the server receives 
it, it actually encrypts it and writes it to the ldap db using the 
default encryption method the directory server uses (by default SSHA).  
However, if you pre-encrypt it and write it to the directory (i.e. 
userpassword: {crypt}cryptedpassword in an ldif), it will preserve this 
and not re-encrypt it, and the server will accept it for binds and stuff 
(as long as what's in {} is supported by the server - i.e. crypt, SHA, 
SSHA).  This is nice if you are transitioning, say, from unix passwords 
to SSHA - you can put the crypt passwords in and it will work, but if 
users change their password, it will SSHA encrypt the new password (for 
apps using method 1 above).  If your app uses method 2, you need to 
config the directory server to use the appropriate encryption method for 
passwords so that when users change their password, it stays in the 
appropriate format.

 - Jeff



Sævaldur Gunnarsson wrote:

> I posted the following on the samba-users mailing list:
> -- 
>
> I'm switching from OpenLDAP to the newly released Fedora Directory 
> Server (formely known as the Netscape Directory Server) as a LDAP 
> backend for my Samba domain.
>
> I'm now faced with a problem regarding how Fedora DS handles the 
> userPassword field.
> Unlike OpenLDAP it encodes it in base64 so instead of reading
> userPassword: {SSHA}8FZY4LdYi1f1oA5YgDw/+h/Rmy0mEeyO
> it reads:
> userPassword:: e1NTSEF9OEZaWTRMZFlpMWYxb0E1WWdEdy8raC9SbXkwbUVleU8=
>
>
> Advice of how to correct this are greatly appreciated.
> -- 
>
> The reply I got back was that it was not a Samba problem but a FDS 
> problem.
> I guess I'm looking for a way to store the userPassword entry as a 
> regular entry and not a base64 encoded one.
> So any advice ?
>