I think this could be an access control issue. The default ACIs supplied with the server only allow root (Directory Manager) and 'self' write access to the userPassword attribute. If you changed the access control rules to allow the user that samba binds as write access, that might help. The access log is your friend : look in there (.../slapd-<hostname>/logs/access) to find the operations samba attempted. The ldap result code for the modify operation will be in there. You will be able to see if the operation failed due to access control restrictions (error code 50) or for some other reason.

Hmm - error 89 is parameter error. Something you/samba passed was invalid in some way (i.e. for some reason it seems to be passing null for the current password) What does it show in the directory server access and error logs? Show us the entire connection, as well as anything in the error log around that time. - Jeff Sævaldur Gunnarsson wrote:

And can I change this somewhere ? -- Sævaldur Gunnarsson /> RHCE

Sævaldur Gunnarsson wrote: Does the program supply the old password and the new password? If not, then I think I know what the problem is. Take a look at http://cvs.fedora.redhat.com/lxr/dirsec/source/ldapserver/ldap/servers/sl... lines 310-350. It rejects operations which do not have both the old password and the new password. The RFC however allows this - http://www.ietf.org/rfc/rfc3062.txt. It should be pretty easy to change the server to handle a missing old password - just ensure the current BIND identity is valid and has a valid password (or some other stronger auth). I'm not sure what to do about a missing new password - does AD generate a new one (as allowed but not required by the RFC)? How about OpenLDAP? It would be nice to be compatible with them, but the RFC allows an error to be returned if there is no new password. "In absence of a client provided newPasswd, the server SHALL either generate a password on behalf of the client or return a non-success result code."

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: