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 ?
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
