I've described the problem in the message to samba mailing list. Just to sum up: 1. One domain 2. Two domain controlers, primary(jane) and backup(joe). 3. Two ldap servers, master(jane) and slave(joe), replication works fine. smb.conf (on both machines) passdb backend = ldapsam:ldapi:///var/run/ldapi idmap backend = ldap:ldapi:///var/run/ldapi ldap admin dn = "cn=Sambaroot,o=TELMARK,c=PL" ldap password sync = yes Changing password via joe's ldap server (slave) fails with a very curious side effect. Sambaroot's password gets changed. Unfortunately I haven't included cleartext password support in my openldap so I can't tell what is Sambaroot's password afterwards. To overcome this singularity one can either set smbd on joe to use jane's (master) ldap server or *turn off* "ldap password sync". The former is no good since I'd like to use the bdc in a remote location, the latter breaks access to unix services: ssh/mail/etc.
Could you please provide your smb.conf, the LDAP config, a debug level 10 log of smbd taking the password change, as well as a sniff of the network traffic of that machine? I'm particularly interested in the traffic to the LDAP server. Thanks, Volker
Created attachment 1794 [details] confs, logs, tcpdumps > I'm particularly interested in the traffic to the LDAP server. Here you are. The dump has been taken with tcpdump -s 1500 -w ldap.pkt port 389 and host 10.1.2.4 It also contains replication back to joe. 10.1.2.4 is jane (real name vlana) 10.1.2.7 is joe (real name charlotte) Don't worry about passwords I've changed them.
Just a short note: joe is not really a BDC (please fix and verify with testparm).
(In reply to comment #3) > joe is not really a BDC Could "domain logons = no" hurt ldap password modification. I think not. I turned domain logons off, because joe is on the same network as jane and by some accident users could try to use it while it's not fully set up. I've just checked. It does not matter.
To be honest, to me everything Samba does looks fine. Ethereal for some reason can not decode the modify request. But a brief look at the blob in the modify it looks ok to me. Same for the ldap change password extended operation. It correctly gives your dn in frame 21 of the trace. The frames 27 to 34 seem to be replication traffic between your PDC and your BDC. And there something strange happens: Frame 31 changes the userPassword field for cn=Sambaroot. To me it looks as if your LDAP does something strange. Could you try to use and sniff ldappasswd? I'm curious if it also uses the extended operation and if this makes any difference. Volker
Created attachment 1799 [details] dump from ldappasswd OK lets start. I sit on joe and try to run ldappasswd. I will bind as Sambaroot and change Lukasz Stelmach's password, just like smbd does. $ ldappasswd -h localhost -D "cn=Sambaroot,o=TELMARK,c=PL" -y ldap.secret "cn=Lukasz Stelmach,ou=Pracownicy,o=TELMARK,c=PL" and # tcpdump -i lo -w ldap_slave.pkt port 389 ok I get referral Result: Referral (10) Referral: ldap://10.1.2.4:389 Since ldappasswd does not do automatic referral handling let's do it by hand $ ldappasswd -h 10.1.2.4 -D "cn=Sambaroot,o=TELMARK,c=PL" -y ldap.secret "cn=Lukasz Stelmach,ou=Pracownicy,o=TELMARK,c=PL" and a proper tcpdump to ldap_master.pkt OK Lukasz's userPassword has changed Sambaroot's is untouched.
Look at these dumps (and find the difference ;-), the first one is smbd to ldap communication, the other is from ldappaswd. Look at offsets: 0x3b, 0x54. I'm trying to figure out what difference does it make and why it happens so. * smbd 12:59:22.031440 IP 10.1.2.7.3352 > 10.1.2.4.389: P 64:160(96) ack 15 win 2920 <n 0x0000: 4500 0094 c16f 4000 4006 60e8 0a01 0207 E....o@.@.`..... 0x0010: 0a01 0204 0d18 0185 cff1 e44a 6b05 ac71 ...........Jk..q 0x0020: 8018 0b68 1893 0000 0101 080a 0549 2561 ...h.........I%a 0x0030: 1048 fb58 305e 0201 0e77 5904 1731 2e33 .H.X0^...wY..1.3 0x0040: 2e36 2e31 2e34 2e31 2e34 3230 332e 312e .6.1.4.1.4203.1. 0x0050: 3131 2e31 003e 303c 802f 636e 3d4c 756b 11.1.>0<./cn=Luk 0x0060: 6173 7a20 5374 656c 6d61 6368 2c6f 753d asz.Stelmach,ou= 0x0070: 5072 6163 6f77 6e69 6379 2c6f 3d54 454c Pracownicy,o=TEL 0x0080: 4d41 524b 2c63 3d50 4c82 0961 6c61 6d61 MARK,c=PL..alama 0x0090: 6b6f 7461 kota * ldappasswd 12:26:15.591133 IP 10.1.2.7.2817 > 10.1.2.7.389: P 62:158(96) ack 15 win 8198 <n 0x0000: 4500 0094 b7d4 4000 4006 6a80 0a01 0207 E.....@.@.j..... 0x0010: 0a01 0207 0b01 0185 9016 94c4 905a 4fc8 .............ZO. 0x0020: 8018 2006 1896 0000 0101 080a 068b 2358 ..............#X 0x0030: 068b 2358 305e 0201 0277 5980 1731 2e33 ..#X0^...wY..1.3 0x0040: 2e36 2e31 2e34 2e31 2e34 3230 332e 312e .6.1.4.1.4203.1. 0x0050: 3131 2e31 813e 303c 802f 636e 3d4c 756b 11.1.>0<./cn=Luk 0x0060: 6173 7a20 5374 656c 6d61 6368 2c6f 753d asz.Stelmach,ou= 0x0070: 5072 6163 6f77 6e69 6379 2c6f 3d54 454c Pracownicy,o=TEL 0x0080: 4d41 524b 2c63 3d50 4c82 0961 6c61 6d61 MARK,c=PL..alama 0x0090: 6b6f 7461 kota
severity should be determined by the developers and not the reporter.
closing out - not active since 5 years and obviously more an LDAP than a Samba problem