Description of problem: ~~~~~~~~~~~~~~~~~~~~~~~ If the password in nsmultiplexorcredentials for a chaining setup is wrong there is no error message in the log to notify you that the credentials is faulty when the chaining connection is used. Specifically if a user changes his/her password then chaining will be used in our setup. In case of a faulty password the user will see the following error message: New UNIX password: Retype new UNIX password: LDAP password information update failed: Operations error Version-Release number of selected component (if applicable): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 389-admin-1.1.11-1.el5 389-admin-console-1.1.5-1.el5 389-admin-console-doc-1.1.5-1.el5 389-adminutil-1.1.8-4.el5 389-console-1.1.4-1.el5 389-ds-1.2.1-1.el5 389-ds-base-1.2.6.1-1.el5 389-ds-console-1.2.3-1.el5 389-ds-console-doc-1.2.3-1.el5 389-dsgw-1.1.5-1.el5 How reproducible: ~~~~~~~~~~~~~~~~~ Reliably, changing the password via the console to the correct version fixes Steps to Reproduce: ~~~~~~~~~~~~~~~~~~~ 0. Description of environment Master01 ( Provider database ) Master02 ( Consumer database, with chaining for writes back to master01 ) Client01 ( Firewall between client01 and master02, authenticates against master02 ) 1. Setup chaining using the following ldif changetype: add objectClass: top objectClass: extensibleObject objectClass: nsBackendInstance cn: chainingBackend nsslapd-suffix: dc=company nsmultiplexorbinddn: cn=replication manager,cn=config nsusestarttls: off nsfarmserverurl: ldaps://%localmasterfqdn1%:636 %localmasterfqdn2%:636/ nsmultiplexorcredentials: faultysecret nsbindconnectionslimit: 5 nsconcurrentoperationslimit: 5 nsconnectionlife: 130 nsbindtimeout: 3 nsbindretrylimit: 3 nsmaxresponsedelay: 3 nsmaxtestresponsedelay: 5 dn: cn=dc\3dcompany,cn=mapping tree,cn=config changetype: modify add: nsslapd-backend nsslapd-backend: chainingBackend - replace: nsslapd-state nsslapd-state: backend - replace: nsslapd-distribution-plugin nsslapd-distribution-plugin: /usr/lib64/dirsrv/plugins/libreplication-plugin.so - replace: nsslapd-distribution-funct nsslapd-distribution-funct: repl_chain_on_update dn: cn=config,cn=chaining database,cn=plugins,cn=config changetype: modify add: nsTransmittedControls nsTransmittedControls: 2.16.840.1.113730.3.4.12 2. Setup password policies dn: cn=config changetype: modify replace: passwordMaxAge passwordMaxAge: 7776000 - replace: passwordExp passwordExp: on - replace: passwordHistory passwordHistory: on - replace: passwordWarning passwordWarning: 604800 - replace: nsslapd-pwpolicy-local nsslapd-pwpolicy-local: on - replace: passwordInHistory passwordInHistory: 12 - replace: passwordCheckSyntax passwordCheckSyntax: on - replace: passwordGraceLimit passwordGraceLimit: 3 - replace: passwordMaxRepeats passwordMaxRepeats: 0 - replace: passwordMinLength passwordMinLength: 8 - replace: passwordMinAlphas passwordMinAlphas: 0 - replace: passwordMinDigits passwordMinDigits: 0 - replace: passwordMinSpecials passwordMinSpecials: 0 - replace: passwordMinLowers passwordMinLowers: 0 - replace: passwordMinCategories passwordMinCategories: 3 - replace: passwordMinUppers passwordMinUppers: 0 - replace: passwordMinTokenLength passwordMinTokenLength: 3 - replace: passwordMin8bit passwordMin8bit: 0 - replace: passwordMinAge passwordMinAge: 86400 - replace: passwordMustChange passwordMustChange: on dn: cn=config changetype: modify replace: passwordIsGlobalPolicy passwordIsGlobalPolicy: on 3. Login on client01 as any user in directory 4. Try to change password as user using passwd command Actual results: LDAP password information update failed: Operations error Expected results: Expects to be able to change password and if not see a relevant error in the log that tells me that the chaining authentication failed. Additional info: I have enabled the following log levels in the error log on both master01 and master02: cces Control Summary Plug-ins Heavy Trace Output Connection Management Log Communications with shell databases while looking into this problem. The other log levels did not seem relevant. I have not seen an appropriate error message in either master01 or master02 or client01 that would indicate that there was an authentication error with the chaining setup. I can do more tests and recheck error messages in log levels if required.
Created attachment 475308 [details] git patch file (master) Description: Chaning db plugin was terse not to reveal the config error to end users as well as to prevent error log overflow by every single error possibly caused by end users. This patch returns this generic error text to end users: ldap_add: Operations error (1) additional info: database configuration error - \ please contact the system administrator And more detailed messages are logged in the errors log. E.g., chaining database - Internal credentials decoding error; password storage schemes do not match or encrypted password is corrupted. chaining database - cb_get_connection failed (49) Invalid credentials Note: the messages are logged just once in the errors log.
Reviewed by Nathan (Thank you!!!) Pushed to master. $ git merge 646381 Updating a7fe1a3..7ece306 Fast-forward ldap/servers/plugins/chainingdb/cb.h | 2 + ldap/servers/plugins/chainingdb/cb_add.c | 76 ++++++++++----- ldap/servers/plugins/chainingdb/cb_bind.c | 62 ++++++++----- ldap/servers/plugins/chainingdb/cb_compare.c | 55 +++++++---- .../servers/plugins/chainingdb/cb_conn_stateless.c | 71 ++++++++++----- ldap/servers/plugins/chainingdb/cb_delete.c | 80 ++++++++++------ ldap/servers/plugins/chainingdb/cb_modify.c | 74 ++++++++++----- ldap/servers/plugins/chainingdb/cb_modrdn.c | 82 +++++++++++------ ldap/servers/plugins/chainingdb/cb_search.c | 99 ++++++++++++++------ ldap/servers/slapd/pw.c | 4 +- 10 files changed, 404 insertions(+), 201 deletions(-) $ git push Counting objects: 33, done. Delta compression using up to 4 threads. Compressing objects: 100% (17/17), done. Writing objects: 100% (17/17), 5.91 KiB, done. Total 17 (delta 15), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git a7fe1a3..7ece306 master -> master
Thanks! That will really be helpful for anyone running into a similar problem again. Will the message always show up in the errors log or is it tied to log level?
(In reply to comment #6) > Will the message always show up in the errors log or is it tied to log level? They are logged without setting any special log level (but just once). Thank you for your report!
Steps to verify: 1. Set up chaining backend. 2. Set bogus password in dn: cn=chainbe1,cn=chaining database,cn=plugins,cn=config nsmultiplexorcredentials: bogus <== not a true password. 3. Run any operation which is fowarded to the chained backend. The operation should fail and it returns this generic error text to end users: ldap_<OP>: Operations error (1) additional info: database configuration error - \ please contact the system administrator And more detailed message(s) are logged in the errors log. E.g., chaining database - cb_get_connection failed (49) Invalid credentials
1. Done the chainonupdate setup. 2. [root@snmaptest ~]# ldapmodify -D "cn=directory manager" -w Secret123 -p 34206 -x -h localhost -f /home/bug.ldif modifying entry "cn=chainbe1,cn=chaining database,cn=plugins,cn=config 3. earlier passwd was : nsmultiplexorcredentials: {DES}5ARfALKjUhSVvyIRPHFtAg== Now nsmultiplexorcredentials: {DES}PHzkunoHFUc 4. Still I am able to do below operation : [root@snmaptest ~]# ldapadd -x -h localhost -p 34202 -D "cn=Directory Manager" -w Secret123 << EOF > dn: uid=amitaji1,ou=People,o=airius.com > cn: ami1 > sn: ami1 > objectClass: top > objectClass: person > objectClass: inetOrgPerson > uid: ami1 > mail: ami1 > telephoneNumber: +1 408 555 1221 > EOF adding new entry "uid=amitaji1,ou=People,o=airius.com" What operation I should to hit the error?
(In reply to comment #9) > 1. Done the chainonupdate setup. > > 2. [root@snmaptest ~]# ldapmodify -D "cn=directory manager" -w Secret123 -p > 34206 -x -h localhost -f /home/bug.ldif > modifying entry "cn=chainbe1,cn=chaining database,cn=plugins,cn=config > > 3. earlier passwd was : > nsmultiplexorcredentials: {DES}5ARfALKjUhSVvyIRPHFtAg== > > Now > nsmultiplexorcredentials: {DES}PHzkunoHFUc > > 4. Still I am able to do below operation : > > [root@snmaptest ~]# ldapadd -x -h localhost -p 34202 -D "cn=Directory Manager" > -w Secret123 << EOF > > dn: uid=amitaji1,ou=People,o=airius.com > > cn: ami1 > > sn: ami1 > > objectClass: top > > objectClass: person > > objectClass: inetOrgPerson > > uid: ami1 > > mail: ami1 > > telephoneNumber: +1 408 555 1221 > > EOF > adding new entry "uid=amitaji1,ou=People,o=airius.com" > > What operation I should to hit the error? You have to use a user other than "cn=Directory Manager" - operations done by directory manager are done against the local directory server and are not chained.
S1PORT=34202 S1PORTS=34212 S2PORT=34204 S2PORTS=34214 C1PORT=34206 C1PORTS=34216 C2PORT=34208 C2PORTS=34218 Currently : nsmultiplexorcredentials: {DES}5ARfALKjUhSVvyIRPHFtAg== [root@snmaptest ~]# ldapmodify -D "cn=directory manager" -w Secret123 -p 34206 -x -h localhost -f /home/bug.ldif modifying entry "cn=chainbe1,cn=chaining database,cn=plugins,cn=config" After modify nsmultiplexorcredentials: {DES}PHzkunoHFUc= Trying binding with normal user: [root@snmaptest ~]# ldapsearch -x -h localhost -p 34208 -D "uid=ams,ou=People,o=airius.com" -w Secret123 -b "o=airius.com" | more # extended LDIF # # LDAPv3 # base <o=airius.com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # airius.com dn: o=airius.com objectClass: top objectClass: organization o: airius.com # Groups, airius.com dn: ou=Groups,o=airius.com objectClass: top objectClass: organizationalunit ou: Groups # Directory Administrators, Groups, airius.com dn: cn=Directory Administrators,ou=Groups,o=airius.com cn: Directory Administrators objectClass: top objectClass: groupofuniquenames ou: Groups uniqueMember: uid=kvaughan,ou=People,o=airius.com uniqueMember: uid=rdaugherty,ou=People,o=airius.com uniqueMember: uid=hmiller,ou=People,o=airius.com # People, airius.com Also, I observed : [root@snmaptest ~]# ldapadd -x -h localhost -p 34206 -D "uid=ams,ou=People,o=airius.com" -w Secret123 << EOF > dn: uid=sghai1,ou=People,o=airius.com > cn: sghai11 > sn: sghai11 > objectClass: top > objectClass: person > objectClass: inetOrgPerson > uid: sghai11 > mail: s1 > telephoneNumber: +1 408 555 1221 > EOF adding new entry "uid=sghai1,ou=People,o=airius.com" ldap_add: Insufficient access (50) additional info: database configuration error - please contact the system administrator [root@snmaptest ~]# ldapadd -x -h localhost -p 34202 -D "uid=ams,ou=People,o=airius.com" -w Secret123 << EOF dn: uid=sghai1,ou=People,o=airius.com cn: sghai11 sn: sghai11 objectClass: top objectClass: person objectClass: inetOrgPerson uid: sghai11 mail: s1 telephoneNumber: +1 408 555 1221 EOF adding new entry "uid=sghai1,ou=People,o=airius.com" [root@snmaptest ~]# ldapadd -x -h localhost -p 34206 -D "uid=ams,ou=People,o=airius.com" -w Secret123 << EOF dn: uid=sghai11,ou=People,o=airius.com cn: sghai111 sn: sghai111 objectClass: top objectClass: person objectClass: inetOrgPerson uid: sghai111 mail: s1 telephoneNumber: +1 408 555 1221 EOF adding new entry "uid=sghai11,ou=People,o=airius.com" ldap_add: Insufficient access (50) additional info: database configuration error - please contact the system administrator [root@snmaptest ~]# ldapadd -x -h localhost -p 34204 -D "uid=ams,ou=People,o=airius.com" -w Secret123 << EOF dn: uid=sghai11,ou=People,o=airius.com cn: sghai111 sn: sghai111 objectClass: top objectClass: person objectClass: inetOrgPerson uid: sghai111 mail: s1 telephoneNumber: +1 408 555 1221 EOF adding new entry "uid=sghai11,ou=People,o=airius.com" Please guide.
(In reply to comment #11) > S1PORT=34202 > S1PORTS=34212 > S2PORT=34204 > S2PORTS=34214 > C1PORT=34206 > C1PORTS=34216 > C2PORT=34208 > C2PORTS=34218 > > Currently : nsmultiplexorcredentials: {DES}5ARfALKjUhSVvyIRPHFtAg== > > [root@snmaptest ~]# ldapmodify -D "cn=directory manager" -w Secret123 -p 34206 > -x -h localhost -f /home/bug.ldif > modifying entry "cn=chainbe1,cn=chaining database,cn=plugins,cn=config" > > After modify > nsmultiplexorcredentials: {DES}PHzkunoHFUc= > > Trying binding with normal user: > [root@snmaptest ~]# ldapsearch -x -h localhost -p 34208 -D > "uid=ams,ou=People,o=airius.com" -w Secret123 -b "o=airius.com" | more > # extended LDIF > # > # LDAPv3 > # base <o=airius.com> with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # airius.com > dn: o=airius.com > objectClass: top > objectClass: organization > o: airius.com > > # Groups, airius.com > dn: ou=Groups,o=airius.com > objectClass: top > objectClass: organizationalunit > ou: Groups > > # Directory Administrators, Groups, airius.com > dn: cn=Directory Administrators,ou=Groups,o=airius.com > cn: Directory Administrators > objectClass: top > objectClass: groupofuniquenames > ou: Groups > uniqueMember: uid=kvaughan,ou=People,o=airius.com > uniqueMember: uid=rdaugherty,ou=People,o=airius.com > uniqueMember: uid=hmiller,ou=People,o=airius.com > > # People, airius.com Ok. Either 34208 (C2PORT) is chained with correct configuration, or else the operation is going against its local database. This looks correct. > > Also, I observed : > [root@snmaptest ~]# ldapadd -x -h localhost -p 34206 -D > "uid=ams,ou=People,o=airius.com" -w Secret123 << EOF > > dn: uid=sghai1,ou=People,o=airius.com > > cn: sghai11 > > sn: sghai11 > > objectClass: top > > objectClass: person > > objectClass: inetOrgPerson > > uid: sghai11 > > mail: s1 > > telephoneNumber: +1 408 555 1221 > > EOF > adding new entry "uid=sghai1,ou=People,o=airius.com" > ldap_add: Insufficient access (50) > additional info: database configuration error - please contact the system > administrator This looks correct. 34206 (C1PORT) has the bogus multiplexor password. > > [root@snmaptest ~]# ldapadd -x -h localhost -p 34202 -D > "uid=ams,ou=People,o=airius.com" -w Secret123 << EOF > dn: uid=sghai1,ou=People,o=airius.com > cn: sghai11 > sn: sghai11 > objectClass: top > objectClass: person > objectClass: inetOrgPerson > uid: sghai11 > mail: s1 > telephoneNumber: +1 408 555 1221 > EOF > > adding new entry "uid=sghai1,ou=People,o=airius.com" This looks correct - 34202 (S1PORT) is a master. > > [root@snmaptest ~]# ldapadd -x -h localhost -p 34206 -D > "uid=ams,ou=People,o=airius.com" -w Secret123 << EOF > dn: uid=sghai11,ou=People,o=airius.com > cn: sghai111 > sn: sghai111 > objectClass: top > objectClass: person > objectClass: inetOrgPerson > uid: sghai111 > mail: s1 > telephoneNumber: +1 408 555 1221 > EOF > > adding new entry "uid=sghai11,ou=People,o=airius.com" > ldap_add: Insufficient access (50) > additional info: database configuration error - please contact the system > administrator This looks correct. 34206 (C1PORT) has the bogus multiplexor password. > > [root@snmaptest ~]# ldapadd -x -h localhost -p 34204 -D > "uid=ams,ou=People,o=airius.com" -w Secret123 << EOF > dn: uid=sghai11,ou=People,o=airius.com > cn: sghai111 > sn: sghai111 > objectClass: top > objectClass: person > objectClass: inetOrgPerson > uid: sghai111 > mail: s1 > telephoneNumber: +1 408 555 1221 > EOF > > adding new entry "uid=sghai11,ou=People,o=airius.com" This looks correct - 34204 (S2PORT) is a master. > > > Please guide.
Ok, then I am marking this bug as VERIFIED.
Why on earth is this bug/enhancement marked as "VERIFIED" if it have already been confirmed and a patch released? It seems a lot of duplication of effort for no gain.
(In reply to comment #14) > Why on earth is this bug/enhancement marked as "VERIFIED" if it have already > been confirmed and a patch released? It seems a lot of duplication of effort > for no gain. Our internal QE organization has to perform their own verification (for most bugs) for the RHEL version of 389-ds-base. It may seem like wasted effort, but the only way we can be sure to support the paying RHEL customers is if we can reproduce the bug in house and verify that the bug fixes the problem.