Bug 578863

Summary: "Password Modify Extended Operation" ignoring referrals and writing information on dedicated consumer server
Product: [Retired] 389 Reporter: TISDN-SERPRO <tisdn.livre>
Component: Directory ServerAssignee: Nathan Kinder <nkinder>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: high Docs Contact:
Priority: high    
Version: 1.2.0CC: jgalipea
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 17:01:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 434914    
Description Flags
Generated access.log during the password changing (windows machine)
Patch nkinder: review?, rmeggins: review+

Description TISDN-SERPRO 2010-04-01 15:28:07 UTC
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="" 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:

Comment 2 Nathan Kinder 2010-04-08 22:59:02 UTC
Created attachment 405422 [details]

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.

Comment 3 Nathan Kinder 2010-04-09 14:57:32 UTC
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

Comment 4 Jenny Severance 2010-05-17 15:52:02 UTC
could you please add steps to verify this bug? thanks!

Comment 5 Nathan Kinder 2010-05-17 15:58:38 UTC
(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.

Comment 6 Jenny Severance 2010-05-18 16:17:01 UTC
verified - RHEL 4


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