[Pkg-samba-maint] Bug#505215: ldapsam: Samba's use of the modify password exop causes password change propagation to fail
Ralph Rößner
roessner at capcom.de
Mon Nov 10 18:33:47 UTC 2008
Package: samba
Version: 2:3.2.4-1
Password changes made on our Windows (XP Pro) clients are not begin
propagated to the UNIX side. This will sometimes result in an error message
as result of the password change dialogue and sometimes not but in every
case the Windows password is changed, and the UNIX password is not.
Our Samba server is using an ldapsam passdb backend targeting an OpenLDAP
server (from the slapd package). The backend will successfully update the
sambaNTPassword attribute for the user but will fail to update the
userPassword field as well. The Samba server will log an error message like
this:
ldapsam_modify_entry: LDAP Password could not be changed for user gast1: Other (e.g., implementation specific) error
password hash failed
This is suspicious because changing the same password attribute with
ldappasswd (from the slapd package) succeeds, and both Samba and ldappasswd
rely on the LDAP Modify Password Extended Operation, which leaves the choice
of the hashing algorithm to the LDAP server. OpenLDAP chooses whatever its
configured default hash is (UNIX crypt in our case), regardless of the
client. So the cause of the different behaviour should lie in the invocation
of the exop.
Comparing network traces of Samba's failed password change and ldappasswd's
successful one shows that Samba sends an extra two bytes of data to the LDAP
server, otherwise the exop invocations are identical. See the attached
"samba-passwd-exop-failed" capture file (libpcap format) for the Samba
version and "ldappasswd-passwd-exop-success" for the ldappasswd one.
The marshalling of the arguments for the exop call begins at
samba-3.2.4/source/passdb/pdb_ldap.c, line 1722 with the allocation of the
BER structure. The following lines encode a sequence consisting of the user
id, the desired new password, and a null element. This null element, added
in line 1732, is exactly what distinguishes the Samba packet in the above
capture files from the ldappasswd packet. See the Samba source:
#pdb_ldap.c, 1729
if ((ber_printf (ber, "{") < 0) ||
(ber_printf (ber, "ts", LDAP_TAG_EXOP_MODIFY_PASSWD_ID, utf8_dn) < 0) ||
(ber_printf (ber, "ts", LDAP_TAG_EXOP_MODIFY_PASSWD_NEW, utf8_password) < 0) ||
(ber_printf (ber, "n}") < 0)) {
Now compare the corresponding part of the lappasswd source:
#ldappasswd.c, 278
ber_printf( ber, "{" /*}*/ );
if( user != NULL ) {
ber_printf( ber, "ts",
LDAP_TAG_EXOP_MODIFY_PASSWD_ID, user );
free(user);
}
if( oldpw.bv_val != NULL ) {
ber_printf( ber, "tO",
LDAP_TAG_EXOP_MODIFY_PASSWD_OLD, &oldpw );
free(oldpw.bv_val);
}
if( newpw.bv_val != NULL ) {
ber_printf( ber, "tO",
LDAP_TAG_EXOP_MODIFY_PASSWD_NEW, &newpw );
free(newpw.bv_val);
}
ber_printf( ber, /*{*/ "N}" );
Note that the ldappasswd source appends an "N" element, as opposed to the
Samba source, which appends an "n". I am not an expert on libber but from
what I gathered from the ber_printf man page and libber source, the "n"
forces the creation of a null element (which the LDAP server does not like)
but the "N" only appends the null element "when necessary" (it does not
appear to be).
So I tried this modification to Samba:
*** samba-3.2.4/source/passdb/pdb_ldap.c.orig 2008-11-10 18:21:41.000000000 +0100
--- samba-3.2.4/source/passdb/pdb_ldap.c 2008-11-10 18:22:14.000000000 +0100
***************
*** 1732 ****
! (ber_printf (ber, "n}") < 0)) {
--- 1732 ----
! (ber_printf (ber, "N}") < 0)) {
The result is a password change exop that is accepted by the OpenLDAP
server. I suggest that someone with a better grasp of BER and the use of
libber.so have a look at this, to avoid any side effects this modification
may have. All I can say that it solves the problem for me.
For the record:
Samba version: 2:3.2.4-1
OpenLDAP version: 2.4.11-1
libldap-2.4-2 version (for libldap and libber): 2.4.11-1
Samba configuration (shares excluded):
[global]
workgroup = CAPCOM.DE
netbios name = KELDON
server string = %h PDC
security = user
logon path = \\interceptor\profiles\%U
# logon home = \\interceptor\%U\winprofile
logon home = \\interceptor\%U
logon drive = X:
logon script = startup.cmd
os level = 64
preferred master = True
domain master = True
local master = Yes
domain logons = Yes
hosts allow = 146.140.220.128/255.255.255.128 172.16.0.0/255.255.255.0 146.140.29.111 140.140.29.17 192.168.0.2
passdb backend = ldapsam:ldap://localhost
ldap ssl = no
ldap suffix = dc=capcom,dc=de
ldap admin dn = cn=samba service,ou=roles,dc=capcom,dc=de
ldap delete dn = no
ldap user suffix = ou=People
ldap group suffix = ou=Groups
ldap machine suffix = ou=Machines
ldap passwd sync = yes
ldap replication sleep = 5000
ldapsam:editposix = no
ldapsam:trusted = yes
ldap debug level = 5
ldap debug threshold = 1
wins support = yes
encrypt passwords = true
printing = lprng
load printers = no
unix password sync = no
pam password change = no
add machine script = /usr/local/sbin/addldapntbox %u force
Sincerely,
Ralph Rößner
--
Ralph Rößner
CAPCom AG < http://www.capcom.de >
Rundeturmstr. 10, 64283 Darmstadt, Germany
Phone +49 6151 155 900, Fax +49 6151 155 909
Vorstand: Luc Neumann (Vorsitzender)
Vorsitzender des Aufsichtsrats: Prof. Dr.-Ing. José L. Encarnação
Sitz der Gesellschaft: Darmstadt, Registergericht: Darmstadt HRB 8090
-------------- next part --------------
A non-text attachment was scrubbed...
Name: samba-passwd-exop-failed
Type: application/octet-stream
Size: 307 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20081110/4fca2c37/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldappasswd-passwd-exop-success
Type: application/octet-stream
Size: 285 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20081110/4fca2c37/attachment-0001.obj
More information about the Pkg-samba-maint
mailing list