Fedora directory users - Jun 2005 - userPassword is base64 encoded

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
Samba apparently does not like this because when I try to change the 
password using the "ctrl+alt+del -> Change Password" method I get
the
following error in samba.log (with log level = passdb:5)

-- cut here --
[2005/06/07 19:27:45, 2] passdb/pdb_ldap.c:init_sam_from_ldap(511)
   init_sam_from_ldap: Entry found for user: gg
[2005/06/07 19:27:45, 2] passdb/pdb_ldap.c:init_sam_from_ldap(511)
   init_sam_from_ldap: Entry found for user: gg
[2005/06/07 19:27:45, 4] passdb/pdb_ldap.c:ldapsam_update_sam_account(1704)
   ldapsam_update_sam_account: user gg to be modified has dn: 
uid=gg,ou=People,dc=kung,dc=foo
[2005/06/07 19:27:45, 2] passdb/pdb_ldap.c:init_ldap_from_sam(893)
   init_ldap_from_sam: Setting entry for user: gg
[2005/06/07 19:27:45, 0] passdb/pdb_ldap.c:ldapsam_modify_entry(1587)
   ldapsam_modify_entry: LDAP Password could not be changed for user gg: 
Unknown error
         Current passwd must be supplied by the user.

[2005/06/07 19:27:45, 0] passdb/pdb_ldap.c:ldapsam_update_sam_account(1731)
   ldapsam_update_sam_account: failed to modify user with uid = gg, 
error: Current passwd must be supplied by the user.
    (Success)
[2005/06/07 19:27:45, 2] passdb/pdb_ldap.c:init_sam_from_ldap(511)
   init_sam_from_ldap: Entry found for user: gg
[2005/06/07 19:27:45, 0] libsmb/smbencrypt.c:decode_pw_buffer(539)
   decode_pw_buffer: incorrect password length (-988553355).
[2005/06/07 19:27:45, 0] libsmb/smbencrypt.c:decode_pw_buffer(540)
   decode_pw_buffer: check that ''encrypt passwords = yes''
-- cut here --

And a dialog from Windows that says:
"The User name or old password is incorrect. Letters in passwords must 
be typed using the correct case."

The SambaNTPassword and SambaLMPassword entries change, but the 
userPassword entry does not.
I''m using the ldap passwd sync = Yes option in my smb.conf since the 
LDAP server is used for Linux authentication as well as Samba 
authentication.

However, if I use the smbldap-passwd utility everything works like a charm.
Both the SambaLMPassword/SambaNTPassword and userPassword entries are 
changed.

If the ldap passwd sync option is set to No in the smb.conf then Windows 
does not complain when I use ctrl+alt+del method, but then of course the 
userPassword entry is not modified.


The samba server is a RHEL4 machine with samba-3.0.10-1.4E and 
fedora-ds-7.1-2.RHEL4.
Output from ldapsearch of the user gg:

--cut here --
kung.foo.is /opt/fedora-ds/slapd-palladium/config/schema# ldapsearch -x 
-ZZ -D "uid=gg,ou=People,dc=kung,dc=foo" -W uid=gg userPassword 
SambaLMPassword SambaNTPassword
Enter LDAP Password:

# gg, People, kung.foo
dn: uid=gg,ou=People,dc=kung,dc=foo
userPassword::
e1NTSEF9OEZaWTRMZFlpMWYxb0E1WWdEdy8raC9SbXkwbUVleU8SambaLMPassword:
7B9FBD79429286DBAAD3B435B51404EE
SambaNTPassword: 2352D5C13878770724EA84A32EFCD485
--cut here--

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 ?

-- 
Sævaldur Gunnarsson /> RHCE

Em Terça 07 Junho 2005 21:58, Sævaldur Gunnarsson
escreveu:
> 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
That shouldn''t pose a problem by itself. Note the double colons (::), 
indicating that this is base64.
> [2005/06/07 19:27:45, 0] passdb/pdb_ldap.c:ldapsam_update_sam_account(1731)
>    ldapsam_update_sam_account: failed to modify user with uid = gg, 
> error: Current passwd must be supplied by the user.
>     (Success)
Samba binds to the DS as the admin server and then just attempts to overwrite 
the userPassword attribute (I assume you have ldap sync turned on). It seems 
DS doesn''t like it: it requires the current password first. Perhaps
there is
some configuration change that can help.

>
>Samba binds to the DS as the admin server and then just attempts to
overwrite
>the userPassword attribute (I assume you have ldap sync turned on). It seems
>DS doesn''t like it: it requires the current password first. Perhaps
there is
>some configuration change that can help.
>
>  
>
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.

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 ?
>

Thank you all for replying.

I think I have narrowed this problem down to the fact that FDS wants the 
user''s old password when changing it.
No matter if you are authenticated as the user or as the Directory Manager.

kung.foo.is ~# ldappasswd -ZZ -D "cn=Directory Manager" 
uid=gg,ou=People,dc=kung,dc=foo -S -x -W
New password:
Re-enter new password:
Enter LDAP Password:
Result: Unknown error (89)
Additional info: Current passwd must be supplied by the user.

This is the same errorcode (err=89) as I see in the access log when I 
try to change the password from Windows
[08/Jun/2005:10:07:11 +0000] conn=1043 op=14 RESULT err=89 tag=120 
nentries=0 etime=0

So looks like the problem has been located
Next, how to fix it ? ;)


David Boreham wrote:
> 
>>
>> Samba binds to the DS as the admin server and then just attempts to 
>> overwrite the userPassword attribute (I assume you have ldap sync 
>> turned on). It seems DS doesn''t like it: it requires the
current
>> password first. Perhaps there is some configuration change that can
help.
>>
>>  
>>
> 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.
> 
> 
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
-- 
Sævaldur Gunnarsson /> RHCE

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:
> Thank you all for replying.
>
> I think I have narrowed this problem down to the fact that FDS wants 
> the user''s old password when changing it.
> No matter if you are authenticated as the user or as the Directory 
> Manager.
>
> kung.foo.is ~# ldappasswd -ZZ -D "cn=Directory Manager" 
> uid=gg,ou=People,dc=kung,dc=foo -S -x -W
> New password:
> Re-enter new password:
> Enter LDAP Password:
> Result: Unknown error (89)
> Additional info: Current passwd must be supplied by the user.
>
> This is the same errorcode (err=89) as I see in the access log when I 
> try to change the password from Windows
> [08/Jun/2005:10:07:11 +0000] conn=1043 op=14 RESULT err=89 tag=120 
> nentries=0 etime=0
>
> So looks like the problem has been located
> Next, how to fix it ? ;)
>
>
> David Boreham wrote:
>
>>
>>>
>>> Samba binds to the DS as the admin server and then just attempts to
>>> overwrite the userPassword attribute (I assume you have ldap sync 
>>> turned on). It seems DS doesn''t like it: it requires the
current
>>> password first. Perhaps there is some configuration change that can
>>> help.
>>>
>>>  
>>>
>> 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.
>>
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>

Em Quarta 08 Junho 2005 19:38, jclowser@unitedmessaging.com
escreveu:
> 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)
The question is more on the line of why does it need the user''s current
password? It''s the DS admin who is performing the change.

It''s the same situation if /bin/passwd, when run as root in order to
change
the password of a local user, asked for the local user''s current
password.

I guess it''s some sort of policy that DS is implementing.

> The question is more on the line of why does it need the user''s
current
> password? It''s the DS admin who is performing the change.
> 
> It''s the same situation if /bin/passwd, when run as root in order
to change
> the password of a local user, asked for the local user''s current
password.
> 
> I guess it''s some sort of policy that DS is implementing.
And can I change this somewhere ?

-- 
Sævaldur Gunnarsson /> RHCE

Em Quarta 08 Junho 2005 21:44, Sævaldur Gunnarsson
escreveu:
> > I guess it''s some sort of policy that DS is implementing.
> 
> And can I change this somewhere ?
I really don''t know, I''m just lurking here... :(