Bug 1171308
| Summary: | replication not working for "add: userPassword" LDAP operation | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Thang Nguyen <thang> | ||||||
| Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 6.3 | CC: | jgalipea, nhosoi, nkinder, pdwyer, rmeggins, samuel, sramling, victoriano | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | 389-ds-base-1.2.11.15-51.el6 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2015-07-22 06:36:27 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
The error is reported when the master gets CONN_NOT_CONNECTED: /* We lost the connection - enter backoff state */ Could you provide the error log as well as the access log of the consumer server? Also, if you run ldapsearch against the master and the consumer, what's returned? (please see also https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/ldap-clients-ssl.html for running ldapsearch over SSL.) ldapsearch -x -H "ldaps://YOUR_HOST:636" -D YOUR_DIR_MGR -w YOUR_PW -b "cn=user1,dc=ou,dc=o" userPassword Created attachment 965276 [details]
consumer access log
I attached the consumer access log. There's nothing in the consumer error log around this time. When I do an ldapsearch, I see the userPassword attribute on the master but not on the consumer server. Thanks for the input. It looks the mod sent to the consumer was empty. [04/Dec/2014:10:12:58 -1000] conn=2662 op=7 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" [04/Dec/2014:10:12:58 -1000] conn=2662 op=7 RESULT err=0 tag=120 nentries=0 etime=0 [04/Dec/2014:10:12:58 -1000] conn=2662 op=8 MOD dn="uhEntry=d78930247890123479012347801237489123,ou=People,dc=hawaii,dc=edu" authzid="(null)", no values given [04/Dec/2014:10:12:58 -1000] conn=2662 op=8 RESULT err=2 tag=103 nentries=0 etime=0 [04/Dec/2014:10:12:58 -1000] conn=2662 op=9 MOD dn="uhEntry=d78930247890123479012347801237489123,ou=People,dc=hawaii,dc=edu" [04/Dec/2014:10:12:58 -1000] conn=2662 op=9 RESULT err=0 tag=103 nentries=0 etime=0 csn=5480c04f0001005d0000 If you run "dbscan -f /path/to/yourMastersChangelogDir/yourChangeLog.db4" against your master server, do you see the contents of the modify operation? Another question, is the symptom specific to userPassword? And does it occur every time you add userPassword with modify? Thanks. I see the contents in the dbscan output.
To clarify the issue:
Replication does NOT work with the following LDIF:
dn: cn=user1,dc=ou,dc=o
changetype: modify
add: userPassword
userPassword: {SSHA}xxxxxxx
However, I just tested and replication does work with this LDIF:
dn: cn=user1,dc=ou,dc=o
changetype: modify
add: userPassword
userPassword: xxxxxxx
Seems like the "{SSHA}" causes the problem.
I see the contents in the dbscan output.
To clarify the issue:
Replication does NOT work with the following LDIF:
dn: cn=user1,dc=ou,dc=o
changetype: modify
add: userPassword
userPassword: {SSHA}xxxxxxx
However, I just tested and replication does work with this LDIF:
dn: cn=user1,dc=ou,dc=o
changetype: modify
add: userPassword
userPassword: xxxxxxx
Seems like the "{SSHA}" causes the problem.
I want to add that replication works with "replace" that has {SSHA}:
dn: cn=user1,dc=ou,dc=o
changetype: modify
replace: userPassword
userPassword: {SSHA}xxxxxxx
Thanks, Thang.
I could reproduce the problem.
Could you please confirm one thing?
This fails with Protocol error (2).
dn: cn=user1,dc=ou,dc=o
changetype: modify
add: userPassword
userPassword: {SSHA}xxxxxxx
This modify-add is successfully replicated to the consumer.
dn: cn=user1,dc=ou,dc=o
changetype: modify
add: userPassword
userPassword: xxxxxxx
This modify-replace is successfully replicated, too. Right?
dn: cn=user1,dc=ou,dc=o
changetype: modify
replace: userPassword
userPassword: {SSHA}xxxxxxx
That's correct. Thanks Noriko! I tested this on RHEL6.6 and its reproducible as mentioned above in comment #9. Build tested - 389-ds-base-1.2.11.15-48 LDAP Modify-add with hashed password FAILS: ldapmodify -x -p 1189 -h localhost -D "cn=Directory Manager" -w Secret123 dn: cn=ttusr2,ou=people,dc=passsync,dc=com changetype: modify add: userPassword userPassword: {SSHA}U2VjcmV0MTIzNA== ldapsearch -LLLx -p 1189 -h localhost -D "cn=Directory Manager" -w Secret123 -b "dc=passsync,dc=com" cn=ttusr2 userPassword dn: cn=ttusr2,ou=People,dc=passsync,dc=com userPassword:: e1NTSEF9VTJWamNtVjBNVEl6TkE9PQ== ldapsearch -LLLx -p 1289 -h localhost -D "cn=Directory Manager" -w Secret123 -b "dc=passsync,dc=com" cn=ttusr2 userPassword dn: cn=ttusr2,ou=People,dc=passsync,dc=com LDAP Modify-replace: it works fine. [root@iceman ~]# ldapmodify -x -p 1189 -h localhost -D "cn=Directory Manager" -w Secret123 << EOF dn: cn=ttusr3,ou=people,dc=passsync,dc=com changetype: modify replace: userPassword userPassword: {SSHA}U2VjcmV0MTIzNA== EOF modifying entry "cn=ttusr3,ou=people,dc=passsync,dc=com" [root@iceman ~]# ldapsearch -LLLx -p 1289 -h localhost -D "cn=Directory Manager" -w Secret123 -b "dc=passsync,dc=com" cn=ttusr3 userPassword dn: cn=ttusr3,ou=People,dc=passsync,dc=com userPassword:: e1NTSEF9VTJWamNtVjBNVEl6TkE9PQ== [root@iceman ~]# ldapsearch -LLLx -p 1189 -h localhost -D "cn=Directory Manager" -w Secret123 -b "dc=passsync,dc=com" cn=ttusr3 userPassword dn: cn=ttusr3,ou=People,dc=passsync,dc=com userPassword:: e1NTSEF9VTJWamNtVjBNVEl6TkE9PQ== With modify-add with regular password: works fine [root@iceman ~]# ldapmodify -x -p 1189 -h localhost -D "cn=Directory Manager" -w Secret123 << EOF dn: cn=ttusr4,ou=people,dc=passsync,dc=com changetype: modify add: userPassword userPassword: Secret1234 EOF modifying entry "cn=ttusr4,ou=people,dc=passsync,dc=com" [root@iceman ~]# ldapsearch -LLx -p 1189 -h localhost -D "cn=Directory Manager" -w Secret123 -b "dc=passsync,dc=com" cn=ttusr4 userPassword dn: cn=ttusr4,ou=People,dc=passsync,dc=com userPassword:: e1NTSEF9UU95cXlWMnRFTDk3Ukp3ekNFclFIa2o5SllzTjlyajhnazczYWc9PQ= = [root@iceman ~]# ldapsearch -LLLx -p 1289 -h localhost -D "cn=Directory Manager" -w Secret123 -b "dc=passsync,dc=com" cn=ttusr4 userPassword dn: cn=ttusr4,ou=People,dc=passsync,dc=com userPassword:: e1NTSEF9UU95cXlWMnRFTDk3Ukp3ekNFclFIa2o5SllzTjlyajhnazczYWc9PQ= = Fixed upstream. We have also been bitten by this bug. I may not post the changelog because it contains PII (Personal Identifiable Information). We have found that any other attributes that go in the same change record with the added base64 encoded hashed userPassword do not replicate as well. Is there any time frame for new RPMs with the fix included? We have had to implement a very ugly hack to our user provisioning system. And we have to provision quite a number almost every day. Thanks. Thanks Noriko for the clarification. Marking the bug as Verified. Confirming this here at VLSCI with: [root@ldap2 slapd-ldap2]# yum info 389-ds-base Loaded plugins: etckeeper, product-id, rhnplugin, security, subscription-manager This system is receiving updates from RHN Classic or RHN Satellite. Installed Packages Name : 389-ds-base Arch : x86_64 Version : 1.2.11.15 Release : 50.el6_6 Size : 4.9 M Repo : installed From repo : rhel-x86_64-server-6 Summary : 389 Directory Server (base) URL : http://port389.org/ License : GPLv2 with exceptions Description : 389 Directory Server is an LDAPv3 compliant server. The base package includes : the LDAP server and command line utilities for server administration. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-1326.html |
Created attachment 965227 [details] replication log Description of problem: In a replication (master-master or master-consumer) environment, when doing a dn: cn=user1,dc=ou,dc=o changetype: modify add: userPassword userPassword: xxxxxxx on the master server, the userPassword attribute/value is added to the master but cannot be replicated to the consumer. I get the following error in the error log: [04/Dec/2014:10:12:58 -1000] NSMMReplicationPlugin - agmt="cn=ldp93-to-ldp92-636" (ldp92:636): Consumer failed to replay change (uniqueid 5b2cfd01-7bf011e4-85c0de15-2b200dc9, CSN 5480c04f0000005d0000): Protocol error (2). Will retry later. Attached is the replication log (nsslapd-errorlog-level: 8192) for this operation. This happens on version 1.2.11.15-48.el6_6 but NOT on 1.2.11.15-34.el6_5. Version-Release number of selected component (if applicable): 389-ds-base.x86_64 1.2.11.15-48.el6_6 Steps to Reproduce: 1. configure a master-consumer replication environment 2. create any new ldap record without userPassword attribute 3. do "add: userPassword" as mentioned in the description of problem section. 4. check the error log