Bug 1170709 - Account lockout attributes incorrectly updated after failed SASL Bind
Summary: Account lockout attributes incorrectly updated after failed SASL Bind
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-04 16:23 UTC by mreynolds
Modified: 2015-03-05 09:39 UTC (History)
3 users (show)

Fixed In Version: 389-ds-base-1.3.3.1-10.el7
Doc Type: Bug Fix
Doc Text:
Cause: A failed SASL bind operation, and Account Lockout enabled Consequence: The Root DSE entry gets incorrectly updated with passwordRetryCount Fix: Do not update the Account Lockout settings when the failed bind is a SASL bind Result: The root DSE entry is not modified when a SASL bind fails.
Clone Of:
Environment:
Last Closed: 2015-03-05 09:39:57 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0416 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description mreynolds 2014-12-04 16:23:57 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47970

When a SASL bind fails, the target DN is not set.  If password policy account lockout is configured, it attempts to update the password retry count on the dn ("") - which is the Root DSE entry, not a user entry.

This also confuses the COS plugin, and it incorrectly triggers a COS cache rebuild after the failed login.

Comment 1 mreynolds 2014-12-04 21:41:07 UTC
Fixed upstream:

Verification steps

[1]  Setup DS
[2]  Enable Account lockout

ldapmodify ...
dn: cn=config
changetype: modify
replace: passwordLockout
passwordLockout: on

[3]  Attempt a SASL BInd (this is expected to fail)

 ldapsearch -h <host> -p <port>  -b "dc=example,dc=com" -v -LLL -Y GSSAPI "uid=*" dn

[4]  Check the root DSE entry for passwordRetryCount:


 ldapsearch -b "" -s base -xLLL passwordRetryCount=* passwordRetryCount

[5]  If the entry is NOT returned, the fix is verified

Comment 3 Amita Sharma 2014-12-26 12:59:48 UTC
[root@dhcp201-126 pwpolicy]# ldapmodify -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF
> dn: cn=config
> changetype: modify
> replace: passwordLockout
> passwordLockout: on
> EOF
modifying entry "cn=config"

[root@dhcp201-126 pwpolicy]# ldapsearch -h localhost -p 389  -b "dc=example,dc=com" -v -LLL -Y GSSAPI "uid=*" dn
ldap_initialize( ldap://localhost:389 )
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
	additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (No Kerberos credentials available)
[root@dhcp201-126 pwpolicy]# ldapsearch -b "" -s base -xLLL passwordRetryCount=* passwordRetryCount
[root@dhcp201-126 pwpolicy]# 

Hence VERIFIED

Comment 5 errata-xmlrpc 2015-03-05 09:39:57 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/RHSA-2015-0416.html


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