Bug 3605 - ldap password synchronization throws samba into weeds
ldap password synchronization throws samba into weeds
Status: RESOLVED WORKSFORME
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts
3.0.21c
x86 Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
http://lists.samba.org/archive/samba/...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-14 04:34 UTC by Lukasz Stelmach
Modified: 2011-03-03 02:04 UTC (History)
1 user (show)

See Also:


Attachments
confs, logs, tcpdumps (31.35 KB, application/octet-stream)
2006-03-14 07:04 UTC, Lukasz Stelmach
no flags Details
dump from ldappasswd (1.67 KB, application/octet-stream)
2006-03-15 06:03 UTC, Lukasz Stelmach
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lukasz Stelmach 2006-03-14 04:34:54 UTC
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.
Comment 1 Volker Lendecke 2006-03-14 04:45:11 UTC
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
Comment 2 Lukasz Stelmach 2006-03-14 07:04:42 UTC
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.
Comment 3 Guenther Deschner 2006-03-14 10:26:59 UTC
Just a short note: joe is not really a BDC (please fix and verify with testparm).
Comment 4 Lukasz Stelmach 2006-03-14 10:48:37 UTC
(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.

Comment 5 Volker Lendecke 2006-03-15 03:09:13 UTC
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
Comment 6 Lukasz Stelmach 2006-03-15 06:03:08 UTC
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.
Comment 7 Lukasz Stelmach 2006-03-18 09:28:57 UTC
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
Comment 8 Gerald (Jerry) Carter 2006-04-20 08:03:39 UTC
severity should be determined by the developers and not the reporter.
Comment 9 Björn Jacke 2011-03-03 02:04:25 UTC
closing out - not active since 5 years and obviously more an LDAP than a Samba problem