Created attachment 404023 [details] Generated access.log during the password changing (windows machine) Description of problem: We are using FDS 1.2.0 and we are making SAMBA integration with LDAP. There are two FDS servers, one (serverA) is configured as single master and the other (serverB) as a dedicated consumer. We're using the option "ldap passwd sync=only" and pointing the ldapsam to serverB. When we changed the password of a user (in a Windows machine), his "userpassword" ldap attribute has changed in serverB(the dedicated consumer) instead of return referral to serverA (the master). The most strange is that the access log doesn't show nothing, even the correct error code 10 (referral). We've checked the suffix configuration in the serverB and the "update on referral" was selected. It seems to us that SAMBA found a way to ignore the "update on referral" and made the modifications on the consumer. Below are the lines in the access.log of the dedicated consumer server that show that the "password modify extended operation" seems not following referral: - 01/Apr/2010:08:36:09 -0300] conn=553 op=18 EXT oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop" - [01/Apr/2010:08:36:09 -0300] conn=553 op=18 RESULT err=0 tag=120 nentries=0 etime=0 ps: There is no other modify operation (MOD) in the access log. Version-Release number of selected component (if applicable): SO: Debian Lenny Directory: FDS 1.2 SAMBA 3.3.2 / 3.4.7 How reproducible: Steps to Reproduce: 1) Configure two LDAP servers (one as single master and the other as dedicated consumer). 2) Configure replication between the two servers above. 3) Install SAMBA 4) Configure SAMBA as a PDC and smb.conf with the following parameters: -- the ldapbackend pointing to the dedicated consumer server. -- ldap passwd sync=Only. -- ldap ssl = start tls (it's necessary). 5) Join in a domain with a Windows machine 6) Turn off the master ldap server 7) Change the password of an user. Actual results: The userpassword attribute was changed on the dedicated consumer server. Expected results: Return referral to the master ldap server. Additional info:
Created attachment 405422 [details] Patch The password modify extended operation was modifying the local database on a read-only replica instead of returning a referral. The server is designed to let the plugin ID used for updating password retry info make local updates instead of returning a referral. This plugin ID was being used by the password extop code, which it should not be doing. The second issue is that we need to check if a referral needs to be sent as early as possible when processing the extop request. We don't want to reject the change if an entry does not exist before checking if a referral is necessary since the server we refer to may have the target entry present. This required adding a new helper function that allows one to see if a write operation to a particular DN would require a referral to be sent. The password modify extop code leverages this new function to get the referrals and return them to the client if necessary.
Pushed to master and Directory_Server_8_2_Branch. Thanks to Rich for his review! Counting objects: 15, done. Delta compression using 2 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (8/8), 2.17 KiB, done. Total 8 (delta 6), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git b433e4c..c53b8b3 master -> master Counting objects: 15, done. Delta compression using 2 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (8/8), 2.14 KiB, done. Total 8 (delta 6), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 7b29561..92ca2bb ds82-local -> Directory_Server_8_2_Branch
could you please add steps to verify this bug? thanks!
(In reply to comment #4) > could you please add steps to verify this bug? thanks! - Setup a single master, single read-only replica topology - Use the ldappasswd tool to attempt to change the password for a user against the replica. A referral should be sent back to the ldappasswd client. The password should not be updated on the replica.
verified - RHEL 4 version: redhat-ds-base-8.2.0-2010051204.el4dsrv ldappasswd -v -Y DIGEST-MD5 -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 2389 -U TVradmin0 -w TVradmin0 -S New password: Re-enter new password: ldap_initialize( ldap://jgalipea-rhel4.idm.lab.bos.redhat.com:2389 ) SASL/DIGEST-MD5 authentication started SASL username: TVradmin0 SASL SSF: 128 SASL installing layers Result: Referral (10) Matched DN: dc=example,dc=com Referral: ldap://jgalipea-rhel4.idm.lab.bos.redhat.com:1389 Password is not changed on consumer.