RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1219990 - bind on db chained to AD returns err=32
Summary: bind on db chained to AD returns err=32
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-08 22:46 UTC by Noriko Hosoi
Modified: 2020-09-13 21:24 UTC (History)
7 users (show)

Fixed In Version: 389-ds-base-1.2.11.15-57.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-22 06:37:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1514 0 None None None 2020-09-13 21:24:41 UTC
Red Hat Product Errata RHBA-2015:1326 0 normal SHIPPED_LIVE 389-ds-base bug fix and enhancement update 2015-07-20 17:53:07 UTC

Description Noriko Hosoi 2015-05-08 22:46:04 UTC
bind is doing a search for the entry post bind, which fails because we don't enable password policy chaining by default.  I think in this case, we should not look up password policy, because if the remote is AD or some other non-389 server, we can't use the password policy information.  We should instead rely on the remote server to evaluate the password policy.

This code should not run if using a remote_db:
    /* 
     * There could be a race that bind_target_entry was not added 
     * when bind_target_entry was retrieved before be_bind, but it
     * was in be_bind.  Since be_bind returned SLAPI_BIND_SUCCESS,
     * the entry is in the DS.  So, we need to retrieve it once more.
     */
    if (!bind_target_entry) {
        bind_target_entry = get_entry(pb, slapi_sdn_get_ndn(sdn));
        ...

That is
    if (! slapi_be_is_flag_set(be, SLAPI_BE_FLAG_REMOTE_DATA)) {

I think this problem is a regression introduced by 4fc53e1a and 4f11606b

Comment 2 Sankar Ramalingam 2015-06-16 10:19:29 UTC
Hi Noriko, requesting you to add steps to verify this bug.

Comment 3 Noriko Hosoi 2015-06-16 16:49:20 UTC
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!

Comment 4 Sankar Ramalingam 2015-06-23 14:32:47 UTC
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.

Comment 5 Rich Megginson 2015-06-23 14:39:55 UTC
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"

Comment 6 Sankar Ramalingam 2015-06-23 15:27:06 UTC
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

Comment 7 Rich Megginson 2015-06-23 16:09:17 UTC
> [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"

Comment 8 Viktor Ashirov 2015-06-23 16:34:36 UTC
[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?

Comment 9 Noriko Hosoi 2015-06-23 16:52:21 UTC
Viktor, if you increase the log level to PLUGIN, do you see more messages in the error log?

Comment 10 Viktor Ashirov 2015-06-23 17:23:55 UTC
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.

Comment 11 Sankar Ramalingam 2015-06-24 10:52:22 UTC
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

Comment 12 errata-xmlrpc 2015-07-22 06:37:39 UTC
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


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