Bug 1219990
Summary: | bind on db chained to AD returns err=32 | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Noriko Hosoi <nhosoi> |
Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> |
Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 6.0 | CC: | jgalipea, nhosoi, nkinder, rmeggins, salmy, sramling, tlavigne |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 389-ds-base-1.2.11.15-57.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-07-22 06:37:39 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Noriko Hosoi
2015-05-08 22:46:04 UTC
Hi Noriko, requesting you to add steps to verify this bug. Email discussion regarding the bug verification. Noriko Hosoi wrote: >> Could the verification steps be something like this? >> >> 1. Set up chaningdb from 389-ds-base to AD. >> 2. Add users to the AD. >> 3. Set up password policy on AD. >> 4. Bind as a user on the AD. If the bind is successful, the fix was verified. Rich Megginson wrote: > I don't know if you need to set up password policy on AD in order to reproduce the problem and verify the fix. The problem is that the regular bind operation is chained, but the internal search that get_entry does to get the entry to use for slapi_check_account_lock is not chained, so you get an err 32. > > However, we may want to set up password policy on AD to see what happens if you try to chain a BIND operation that fails due to password policy (not sure what that would be - too many attempts? locked out? password requires reset?). But that isn't what the bug is about. Noriko Hosoi wrote: To verify this fix (only), this would be good enough. 1. Set up chaningdb from 389-ds-base to AD. 2. Add users to the AD. 3. Bind as a user on the AD. If the bind is successful, the fix was verified. But as Rich suggested, could you set up some password policies on AD and test them? Thanks, Sankar! Followed these steps to create chaining for AD. 1. Create an instance and add a suffix in DS - "dc=testsuff,dc=com" 2. Create organizational unit "ou=testing" 3. Setup chaining to AD ; IP address - 10.65.206.58 [root@dhcp35-49 ~]# ldapmodify -ca -x -p 1189 -h localhost -D "cn=Directory Manager" -w Secret123 << EOF dn: cn=newdblink3,cn=chaining database,cn=plugins,cn=config objectclass: top objectclass: extensibleObject objectclass: nsBackendInstance nsslapd-suffix: cn=users,dc=tsar,dc=com nsfarmserverurl: ldap://kungfupanda.eng.lab.pnq.redhat.com:389/ nsmultiplexorbinddn: cn=Administrator,cn=Users,dc=tsar,dc=com nsmultiplexorcredentials: Secret123 dn: cn="cn=users,dc=tsar,dc=com",cn=mapping tree,cn=config objectclass: top objectclass: extensibleObject objectclass: nsMappingTree nsslapd-state: backend nsslapd-backend:newdblink3 nsslapd-parent-suffix: ou=testing,dc=testsuff,dc=com EOF 4. Create user in AD - testusr2. and run ldapsearch to AD directly [root@dhcp35-49 ~]# ldapsearch -x -p 389 -h kungfupanda.lab.eng.pnq.redhat.com -D "cn=testusr2,cn=Users,dc=tsar,dc=com" -w Secret123 -b "cn=testusr2,cn=Users,dc=tsar,dc=com" |grep -i "dn: " Success: 5. Run ldapsearch to the same user from DS: [root@dhcp35-49 ~]# ldapsearch -x -p 1189 -h localhost -D "cn=testusr2,ou=testing,dc=testsuff,dc=com" -w Secret123 -b "ou=testing,dc=testsuff,dc=com" Result: FAIL It returns error 32. You have to use the same suffix on DS for chaining that you use for AD for chaining. That means you have to have your base suffix on DS as dc=tsar,dc=com not dc=teststuff,dc=com. 1. Create an instance and add a suffix in DS - "dc=tsar,dc=com" you do not need step 2 #2. Create organizational unit "ou=testing" 3. dn: cn=newdblink3,cn=chaining database,cn=plugins,cn=config objectclass: top objectclass: extensibleObject objectclass: nsBackendInstance nsslapd-suffix: cn=users,dc=tsar,dc=com nsfarmserverurl: ldap://kungfupanda.eng.lab.pnq.redhat.com:389/ nsmultiplexorbinddn: cn=Administrator,cn=Users,dc=tsar,dc=com nsmultiplexorcredentials: Secret123 dn: cn="cn=users,dc=tsar,dc=com",cn=mapping tree,cn=config objectclass: top objectclass: extensibleObject objectclass: nsMappingTree nsslapd-state: backend nsslapd-backend:newdblink3 nsslapd-parent-suffix: dc=tsar,dc=com 4. looks good 5. Run ldapsearch to the same user from DS: [root@dhcp35-49 ~]# ldapsearch -x -p 1189 -h localhost -D "cn=testusr2,cn=users,dc=testsuff,dc=com" -w Secret123 -b "cn=testusr2,cn=users,dc=testsuff,dc=com" Thanks Rich!. Went ahead and deleted the existing chaining rules and created a new chaining rule as per your comment. [root@dhcp35-49 MMR_WINSYNC]# ldapmodify -ca -x -p 1189 -h localhost -D "cn=Directory Manager" -w Secret123 << EOF dn: cn=vnewdblink1,cn=chaining database,cn=plugins,cn=config objectclass: top objectclass: extensibleObject objectclass: nsBackendInstance nsslapd-suffix: cn=users,dc=tsar,dc=com nsfarmserverurl: ldap://kungfupanda.eng.lab.pnq.redhat.com:389/ nsmultiplexorbinddn: cn=Administrator,cn=Users,dc=tsar,dc=com nsmultiplexorcredentials: Secret123 dn: cn="cn=users,dc=tsar,dc=com",cn=mapping tree,cn=config objectclass: top objectclass: extensibleObject objectclass: nsMappingTree nsslapd-state: backend nsslapd-backend: vnewdblink1 nsslapd-parent-suffix: dc=tsar,dc=com EOF adding new entry "cn=vnewdblink1,cn=chaining database,cn=plugins,cn=config" adding new entry "cn="cn=users,dc=tsar,dc=com",cn=mapping tree,cn=config" [root@dhcp35-49 MMR_WINSYNC]# [root@dhcp35-49 MMR_WINSYNC]# ldapsearch -x -p 389 -h kungfupanda.lab.eng.pnq.redhat.com -D "cn=ntestuser1,cn=Users,dc=tsar,dc=com" -w Secret123 -b "dc=tsar,dc=com" | grep -i dn: |wc -l 229 [root@dhcp35-49 MMR_WINSYNC]# ldapsearch -x -p 1189 -h localhost -D "cn=ntestuser1,dc=tsar,dc=com" -w Secret123 -b "dc=tsar,dc=com" ldap_bind: No such object (32) matched DN: dc=tsar,dc=com > [root@dhcp35-49 MMR_WINSYNC]# ldapsearch -x -p 1189 -h localhost -D "cn=ntestuser1,dc=tsar,dc=com" -w Secret123 -b "dc=tsar,dc=com"
> ldap_bind: No such object (32)
> matched DN: dc=tsar,dc=com
Try this instead:
[root@dhcp35-49 MMR_WINSYNC]# ldapsearch -x -p 1189 -h localhost -D "cn=ntestuser1,cn=users,dc=tsar,dc=com" -w Secret123 -b "cn=ntestuser1,cn=users,dc=tsar,dc=com"
[root@dhcp35-49 ~]# ldapsearch -x -p 1189 -h localhost -D "cn=ntestuser1,cn=users,dc=tsar,dc=com" -w Secret123 -b "cn=ntestuser1,cn=users,dc=tsar,dc=com" # extended LDIF # # LDAPv3 # base <cn=ntestuser1,cn=users,dc=tsar,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 12 Critical extension is unavailable text: database configuration error - please contact the system administrator # numResponses: 1 And in the error logs: [23/Jun/2015:22:03:00 +051800] chaining database - 00000057: LdapErr: DSID-0C090745, comment: Error processing control, data 0, v1db0 What might be wrong? Viktor, if you increase the log level to PLUGIN, do you see more messages in the error log? Rich and Noriko, thank you! Setting 'nsProxiedAuthorization: off' made AD happy. # ldapsearch -LLL -x -p 1189 -h localhost -D "cn=ntestuser1,cn=users,dc=tsar,dc=com" -w Secret123 -b "cn=ntestuser1,cn=users,dc=tsar,dc=com" dn: CN=ntestuser1,CN=Users,DC=tsar,DC=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: ntestuser1 sn: ntestuser1 givenName: ntestuser1 distinguishedName: CN=ntestuser1,CN=Users,DC=tsar,DC=com instancetype: 4 whencreated: 20150623193142.0Z whenchanged: 20150623194343.0Z displayName: ntestuser1 usncreated: 184363 usnchanged: 184370 name: ntestuser1 objectguid:: vCy6bzFKo0qZ+NFsr+TYDg== useraccountcontrol: 512 badpwdcount: 0 codepage: 0 countrycode: 0 badpasswordtime: 0 lastlogoff: 0 lastlogon: 0 pwdlastset: 130795615020625000 primarygroupid: 513 objectsid:: AQUAAAAAAAUVAAAAIC8g6es1/M+zoF/SLBMAAA== accountexpires: 9223372036854775807 logoncount: 0 samaccountname: ntestuser1 samaccounttype: 805306368 userprincipalname: ntestuser1 objectcategory: CN=Person,CN=Schema,CN=Configuration,DC=tsar,DC=com dscorepropagationdata: 16010101000000.0Z lastlogontimestamp: 130795622230312500 Bind is successful, marking as VERIFIED. Thanks Viktor!. I tested the same user bind with older version of 389-ds-base-1.2.11.15-46 to reproduce the exact issue. The ldapsearch output throws error 49 if I pass wrong credentials. Where as the same search throws error 32, if I pass the right credentials. This was the bug all about. [root@dhcp35-49 MMR_WINSYNC]# ldapsearch -x -p 1189 -h localhost -D "cn=tuser3,cn=users,dc=tsar,dc=com" -w Secret1234 -b "cn=tuser3,cn=users,dc=tsar,dc=com" ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db0 [root@dhcp35-49 MMR_WINSYNC]# ldapsearch -x -p 1189 -h localhost -D "cn=tuser3,cn=users,dc=tsar,dc=com" -w Secret123 -b "cn=tuser3,cn=users,dc=tsar,dc=com" ldap_bind: No such object (32) Then, I upgraded the version to the latest 389-ds-base-1.2.11.15-60 and the ldapsearch worked as charm. [root@dhcp35-49 MMR_WINSYNC]# yum -y upgrade Loaded plugins: product-id, refresh-packagekit, security, subscription-manager This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. Setting up Upgrade Process Resolving Dependencies --> Running transaction check ---> Package 389-ds-base.x86_64 0:1.2.11.15-46.el6 will be updated ---> Package 389-ds-base.x86_64 0:1.2.11.15-60.el6 will be an update ---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-46.el6 will be updated ---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-60.el6 will be an update --- Updated: 389-ds-base.x86_64 0:1.2.11.15-60.el6 389-ds-base-libs.x86_64 0:1.2.11.15-60.el6 Complete! [root@dhcp35-49 MMR_WINSYNC]# ldapsearch -x -LLL -p 1189 -h localhost -D "cn=tuser3,cn=users,dc=tsar,dc=com" -w Secret123 -b "cn=tuser3,cn=users,dc=tsar,dc=com" |grep -i dn: dn: CN=tuser3,CN=Users,DC=tsar,DC=com Then, I disabled the user account in AD to check if the ldapsearch throws error 32. [root@dhcp35-49 MMR_WINSYNC]# ldapsearch -x -p 389 -h kungfupanda.lab.eng.pnq.redhat.com -D "cn=tuser2,cn=Users,dc=tsar,dc=com" -w Secret123 -b "cn=users,dc=tsar,dc=com" | grep -i dn: |wc -l ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 533, v1db0 0 [root@dhcp35-49 MMR_WINSYNC]# ldapsearch -x -LLL -p 1189 -h localhost -D "cn=tuser3,cn=users,dc=tsar,dc=com" -w Secret123 -b "cn=tuser3,cn=users,dc=tsar,dc=com" |grep -i dn:ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 533, v1db0 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 |