Bug 578863 - "Password Modify Extended Operation" ignoring referrals and writing information on dedicated consumer server
Summary: "Password Modify Extended Operation" ignoring referrals and writing informati...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.2.0
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 434914
TreeView+ depends on / blocked
 
Reported: 2010-04-01 15:28 UTC by TISDN-SERPRO
Modified: 2015-12-07 17:01 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 17:01:01 UTC


Attachments (Terms of Use)
Generated access.log during the password changing (windows machine) (18.38 KB, application/octet-stream)
2010-04-01 15:28 UTC, TISDN-SERPRO
no flags Details
Patch (7.86 KB, patch)
2010-04-08 22:59 UTC, Nathan Kinder
nkinder: review?
rmeggins: review+
Details | Diff

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="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:

Comment 2 Nathan Kinder 2010-04-08 22:59:02 UTC
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.

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

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.


Note You need to log in before you can comment on or make changes to this bug.