Bug 229513 - CRM #1160370 RHDS does not reset passwordRetryCount to 0 upon a successful BIND
CRM #1160370 RHDS does not reset passwordRetryCount to 0 upon a successful BIND
Status: CLOSED CURRENTRELEASE
Product: Red Hat Directory Server
Classification: Red Hat
Component: Security - Password Policy (Show other bugs)
7.1
All Linux
medium Severity medium
: DS8.0
: ---
Assigned To: Noriko Hosoi
Noriko Hosoi
:
Depends On:
Blocks: 152373 159328 240316
  Show dependency treegraph
 
Reported: 2007-02-21 12:34 EST by Issue Tracker
Modified: 2016-05-06 10:37 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-06 10:37:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
cvs commit message (713 bytes, text/plain)
2007-03-07 17:07 EST, Noriko Hosoi
no flags Details

  None (edit)
Description Issue Tracker 2007-02-21 12:34:18 EST
Escalated to Bugzilla from IssueTracker
Comment 2 Noriko Hosoi 2007-03-07 14:19:44 EST
How to reproduce the problem.
0. Set password policy such that:
 * account lock out: on (password lock out count: 3, e.g.)
 * password never expires

1. Failure case: 2-times
$ ./ldapsearch -p <port> -D "uid=puser0,ou=People,dc=example,dc=com" -w "wrong"
-b "ou=People,dc=example,dc=com" "(cn=*)" dn
ldap_simple_bind: Invalid credentials
$ ./ldapsearch -p <port> -D "uid=puser0,ou=People,dc=example,dc=com" -w "wrong"
-b "ou=People,dc=example,dc=com" "(cn=*)" dn
ldap_simple_bind: Invalid credentials

2. Check passwordRetryCount is 2
$ ./ldapsearch -p <port> -D "cn=Directory Manager" -w <pw> -b
"uid=puser0,ou=People,dc=example,dc=com" "(cn=*)" dn passwordretrycount
dn: uid=puser0,ou=People, dc=example,dc=com
passwordretrycount: 2

3. Success case: passwordRetryCount is supposed to be reset
$ ./ldapsearch -p <port> -D "uid=puser0,ou=People,dc=example,dc=com" -w
"correct" -b "ou=People,dc=example,dc=com" "(cn=*)" dn
version: 1
dn: uid=puser0,ou=People, dc=example,dc=com
dn: cn=nsPwPolicyContainer,ou=People, dc=example,dc=com

4. Check passwordRetryCount is reset
$ ./ldapsearch -p <port> -D "cn=Directory Manager" -w <pw> -b
"uid=puser0,ou=People,dc=example,dc=com" "(cn=*)" dn passwordretrycount
dn: uid=puser0,ou=People, dc=example,dc=com
passwordretrycount: 0    <== [Expected result]

[Real result]
Step 3 above fails to reset passwordRetryCount and Step 4 shows 
  passwordretrycount: 2

[Problem description]
The function need_new_pw (pw_mgmt.c) is called via do_bind if the bind is
successful as follows:
(gdb) bt
#0  need_new_pw (pb=0x996ba08, t=0xb43ba1e8, e=0x996fa28, pwresponse_req=1)
    at pw_mgmt.c:101
#1  0x08053b01 in do_bind (pb=0x996ba08) at bind.c:550
#2  0x08055f56 in connection_dispatch_operation (conn=0xb6bc9d20,
    op=0x9971728, pb=0x996ba08) at connection.c:462
#3  0x080574ea in connection_threadmain () at connection.c:2117
#4  0x003bb81e in _pt_root (arg=0x948e150)
    at ../../../../pr/src/pthreads/ptthread.c:214
#5  0x00120371 in start_thread () from /lib/tls/libpthread.so.0
#6  0x00708ffe in clone () from /lib/tls/libc.so.6

And if pw_lockout is on, it tries to set passwordRetryCount to 0 in smods, but
if passwordExpirationTime is not set and password never expires, the smods is
not applied and discarded.

This change fixes the problem.
Index: pw_mgmt.c
===================================================================
RCS file: /cvs/dirsec/ldapserver/ldap/servers/slapd/pw_mgmt.c,v
retrieving revision 1.8
diff -t -w -U4 -r1.8 pw_mgmt.c
--- pw_mgmt.c   27 Feb 2007 02:57:30 -0000      1.8
+++ pw_mgmt.c   7 Mar 2007 18:51:51 -0000
@@ -100,8 +100,10 @@
                         slapi_ch_free((void **)&timestring);
                         slapi_mods_add_string(&smods, LDAP_MOD_REPLACE,
"passwordExpWarned", "0");

                         pw_apply_mods(dn, &smods);
+                } else if (pwpolicy->pw_lockout == 1) {
+                        pw_apply_mods(dn, &smods);
                 }
                 slapi_mods_done(&smods);
                 delete_passwdPolicy(&pwpolicy);
                 return ( 0 );

I checked the rest of the function and verified this is the only case the smods
are trashed.

Please note that this bug exists in 6.2x, 7.1 as well as 7.2.
Comment 3 Nathan Kinder 2007-03-07 14:58:29 EST
The change looks good.
Comment 4 Noriko Hosoi 2007-03-07 17:07:03 EST
Created attachment 149501 [details]
cvs commit message

Reviewed by Nathan (Thank you!).

Checked in into HEAD.
Comment 6 Noriko Hosoi 2007-03-12 13:27:31 EDT
The password retry count info is stored in the value of the attribute
"passwordretrycount":
$ ./ldapsearch -p <port> -D "cn=Directory Manager" -w <passwd> -b
"uid=puser1,ou=People,dc=example,dc=com" "(cn=*)" dn passwordretrycount
version: 1
dn: uid=puser1,ou=People, dc=example,dc=com
passwordretrycount: 1

The value can be manually modified by Directory Manager as follows:
$ ./ldapmodify  -p <port> -D "cn=Directory Manager" -w <passwd>
dn: uid=puser1,ou=People,dc=example,dc=com
changetype: modify
replace: passwordretrycount
passwordretrycount: 0

The value is not allowed to be modified by the user by default.  Once an ACI to
give the permission to modify the attribute value is set, the user can update
the value by him/herself, as well. 
aci: (targetattr = "passwordRetryCount || nsLIElementType") (target = "ldap://
 /uid=puser1,ou=People, dc=sfbay,dc=redhat,dc=com") (version 3.0;acl "<Unname
 d ACI>";allow (all)(userdn = "ldap:///anyone");)

$ ./ldapmodify  -p <port> -D "uid=puser1,ou=People,dc=sfbay,dc=redhat,dc=com" -w
puser1
dn: uid=puser1,ou=People,dc=sfbay,dc=redhat,dc=com
changetype: modify
replace: passwordretrycount
passwordretrycount: 0

Could there be any way to run such an extra reset command after the successful
login?
Comment 8 Noriko Hosoi 2007-03-13 21:33:15 EDT
> Is there any other workaround we can provide the customer for this issue?
Customer unwilling to workaround this bug by enabling Directory Server
PasswordExpiration. 

Satish; could you please elaborate this paragraph you sent me?  If you set
password expiration in the fine-grained password policy (the attribute type is
passwordExpirationTime), then this bug is worked around, indeed.  You could set
as high as 11268 days, which is about 30 years and 10 months.  Most likely,
their Directory Server would be upgraded to the bug fixed version by the time...
 Do you happen to know the reason why they are unwilling to do it?
Comment 9 Issue Tracker 2007-07-06 01:57:57 EDT
I am closing this IT now. I would re-open this if anything needed from you.

Internal Status set to 'Resolved'
Status set to: Closed by Tech
Resolution set to: 'Netscape Applications'

This event sent from IssueTracker by sputhenp 
 issue 114168
Comment 10 Chandrasekar Kannan 2007-07-25 15:00:36 EDT
DS7.2 is not a valid milestone anymore. Anything thats set to DS7.2 should be
set to DS8.0. Will make further changes per bug council on 07/24/2007, after this.
Comment 11 Anh Nguyen 2007-12-07 17:28:55 EST
Verified.
[root@babylon1 ~]# /usr/lib/mozldap/ldapsearch -b "dc=dsqa, dc=sjc2, dc=redhat,
dc=com" -D "uid=TTestUserLastName, ou=people, dc=dsqa, dc=sjc2, dc=redhat,
dc=com" -w "wrong" -p 389 -h babylon1.dsqa.sjc2.redhat.com "cn=TestUser
TestUserLastName" password
ldap_simple_bind: Invalid credentials
[root@babylon1 ~]# /usr/lib/mozldap/ldapsearch -b "dc=dsqa, dc=sjc2, dc=redhat,
dc=com" -D "uid=TTestUserLastName, ou=people, dc=dsqa, dc=sjc2, dc=redhat,
dc=com" -w "wrong" -p 389 -h babylon1.dsqa.sjc2.redhat.com "cn=TestUser
TestUserLastName" password
ldap_simple_bind: Invalid credentials
[root@babylon1 ~]# /usr/lib/mozldap/ldapsearch -b "dc=dsqa, dc=sjc2, dc=redhat,
dc=com" -D "cn=directory manager" -w "redhat12" -p 389 -h
babylon1.dsqa.sjc2.redhat.com "cn=*" dn passwordretrycount
dn: uid=TTestUserLastName,ou=People, dc=dsqa, dc=sjc2, dc=redhat, dc=com
passwordretrycount: 2
[root@babylon1 ~]# /usr/lib/mozldap/ldapsearch -b "dc=dsqa, dc=sjc2, dc=redhat,
dc=com" -D "uid=TTestUserLastName, ou=people, dc=dsqa, dc=sjc2, dc=redhat,
dc=com" -w "redhat" -p 389 -h babylon1.dsqa.sjc2.redhat.com "cn=TestUser
TestUserLastName" password
version: 1
dn: uid=TTestUserLastName,ou=People, dc=dsqa, dc=sjc2, dc=redhat, dc=com
[root@babylon1 ~]# /usr/lib/mozldap/ldapsearch -b "dc=dsqa, dc=sjc2, dc=redhat,
dc=com" -D "cn=directory manager" -w "redhat12" -p 389 -h
babylon1.dsqa.sjc2.redhat.com "cn=*" dn passwordretrycount
dn: uid=TTestUserLastName,ou=People, dc=dsqa, dc=sjc2, dc=redhat, dc=com
passwordretrycount: 0




Comment 12 Anh Nguyen 2007-12-17 15:39:33 EST
Verified

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