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-baseAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED ERRATA QA Contact: Viktor Ashirov <vashirov>
Severity: high Docs Contact:
Priority: high    
Version: 6.0CC: 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:

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@tsar.com
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