Bug 229513

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.

The change looks good.

Created attachment 149501 [details]
cvs commit message

Reviewed by Nathan (Thank you!).

Checked in into HEAD.

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?

> 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?

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

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.

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

Verified