389-ds-base

Clone
Source Code
GIT

#48369 [RFE] response control for password age should be sent by default by RHDS
Closed: wontfix None Opened 8 years ago by rmeggins.

Closed: wontfix
Reopen Issue

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1287475

Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.

1. Proposed title of this feature request
     like Oracle Directory server  RHDS-10 or higher should also send a
response code for password expiry for every request.

    3. What is the nature and description of the request?
       In customers own words:
<snip>
Directory Server Enterprise Edition password policy provides the following
features:
? A grace login limit, specified by the pwdGraceLoginLimit attribute. This
attribute specifies the number of times that an expired password can be used to
authenticate. If the attribute is not present or if it is set to 0,
authentication will fail.
? Safe password modification, specified by the pwdSafeModify attribute. This
attribute specifies whether the existing password must be sent when changing a
password. If the attribute is not present, the existing password does not need
to be sent.
In addition, the password policy provides two controls, passwordPolicyRequest
and passwordPolicyResponse. These controls enable LDAP clients to obtain the
account status information on LDAP add,delete, modrdn, compare, and search
operations.
The following information is available, using the OID 1.3.6.1.4.1.42.2.27.8.5.1
in the search:

? Period of time before the password expires
? Number of grace login attempts remaining
? The password has expired
? The account is locked
? The password must be changed after being reset
? Password modifications are allowed
? The user must supply his/her old password
? The password quality (syntax) is insufficient
? The password is too short
? The password is too young
? The password already exists in history


From <https://docs.oracle.com/cd/E20295_01/html/821-1223/gdrus.html>

So it would seem as long as password expiry is setup in the password policy a
response code will be returned, it doesn't look like this is the case for
Redhat DS.

The reponse control for password age is sent by default by Sun/oracle DS,  so
in SUN/Oracle DS even though password warn is set to 1 day the resonse control
still sends back the time until the password expires. to get the same
functionality in Redhat DS i have to set the password warn time to the same  as
the password expires time.

</snip>

    4. Why does the customer need this? (List the business requirements here)
      Customer is about to migrate from the Oracle Directory Server to the RHDS
10. One of custom application depends on above mentioned response. This
application is failing on RHDS-10.
    5. How would the customer like to achieve this? (List the functional
requirements here)


    6. For each functional requirement listed, specify how Red Hat and the
customer can test to confirm the requirement is successfully implemented.
      Yes
    7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
      No
    8. Does the customer have any specific timeline dependencies and which
release would they like to target (i.e. RHEL5, RHEL6)?

    9. Is the sales team involved in this request and do they have any
additional input?
      No
    10. List any affected packages or components.

    11. Would the customer be able to assist in testing this functionality if
implemented?

Hi Mark,

Python code looks good for me, I have looked over it and didn't find any mistakes. Thank you.

But I didn't test it, so if anybody will build package with these changes, please, test it with this test case. (I still don't know how to build our packages by hand and to test changes from *.patch files that were manually applied)

Thanks,
Simon

Built and ran tests. Looks good to me. Ack.

b408ffc..d9f37f1 master -> master
commit d9f37f1
Author: Mark Reynolds mreynolds@redhat.com
Date: Fri Dec 4 15:55:46 2015 -0500

e621e1f..ed1ad6c 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit ed1ad6c

The following steps have been performed to verfiy whether or not the 'passwordSendExpiringTime' attribute works with local password policy but even after editing the schema, this feature does not work with the local password policy

1) Edited the schema in the /etc/dirsrv/slapd-myds1/ directory and added the attribute ''''passwordSendExpiringTime'''' to the ''''passwordPolicy'''' object class as follows
{{{
[root@corp schema]# vim 02common.ldif
objectClasses: ( 2.16.840.1.113730.3.2.13 NAME 'passwordPolicy' DESC 'Netscape defined password policy objectclass' SUP top MAY ( passwordMaxAge $ passwordExp $ passwordMinLength $ passwordKeepHistory $ passwordInHistory $ passwordChange $ passwordWarning $ passwordLockout $ passwordMaxFailure $ passwordResetDuration $ passwordUnlock $ passwordLockoutDuration $ passwordCheckSyntax $ passwordMustChange $ passwordStorageScheme $ passwordMinAge $ passwordResetFailureCount $ passwordGraceLimit $ passwordMinDigits $ passwordMinAlphas $ passwordMinUppers $ passwordMinLowers $ passwordMinSpecials $ passwordMin8bit $ passwordMaxRepeats $ passwordMinCategories $ passwordMinTokenLength $ passwordTrackUpdateTime $ passwordAdminDN $ passwordSendExpiringTime) X-ORIGIN 'Netscape Directory Server' )
}}}

2) Reloaded the schema
{{{
[root@corp ~]# cd /etc/dirsrv/slapd-myds1
[root@corp slapd-myds1]# schema-reload.pl -D 'cn=Directory Manager' -w secret123
Successfully added task entry "cn=schema_reload_2016_4_29_16_13_7, cn=schema reload task, cn=tasks, cn=config"
}}}

3) Checked the logs, the schema has been reloaded properly
{{{
[root@corp slapd-myds1]# vim /var/log/dirsrv/slapd-myds1/errors
[29/Apr/2016:16:08:00.463106450 +051800] slapd started. Listening on All Interfaces port 389 for LDAP requests
[29/Apr/2016:16:13:07.315038246 +051800] schemareload - Schema reload task starts (schema dir: default) ...
[29/Apr/2016:16:13:07.532582592 +051800] schemareload - Schema validation passed.
[29/Apr/2016:16:13:07.602516128 +051800] schemareload - Schema reload task finished.
}}}

4) Added a new user entry and applied a local password policy to it as follows:

{{{
[root@corp testing]# ldapadd -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389
dn: uid=tuser1,ou=people,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: inetorgperson
uid: tuser1
cn: test user1
sn: user1
userpassword: secret123
adding new entry "uid=tuser1,ou=people,dc=example,dc=com"

[root@corp testing]# ns-newpwpolicy.pl -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 -U 'uid=tuser1,ou=people,dc=example,dc=com'
Container entries added.

[root@corp testing]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389
dn: uid=tuser1,ou=people,dc=example,dc=com
changetype: modify
replace: pwdpolicysubentry
pwdpolicysubentry: cn="cn=nsPwPolicyEntry,uid=tuser1,ou=people,dc=example,dc=com",
cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
modifying entry "uid=tuser1,ou=people,dc=example,dc=com"

[root@corp testing]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389
dn: cn="cn=nsPwPolicyEntry,uid=tuser1,ou=people,dc=example,dc=com",
cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
changetype: modify
replace: passwordExp
passwordExp: on
-
replace: passwordMaxAge
passwordMaxAge: 86400
-
replace: passwordSendExpiringTime
passwordSendExpiringTime: on
modifying entry "cn="cn=nsPwPolicyEntry,uid=tuser1,ou=people,dc=example,dc=com", cn=nsPwPolicyContainer,ou=people,dc=example,dc=com"
}}}

5) As can been below the entry has been properly modified with all the required attributes
{{{
[root@corp testing]# ldapsearch -xLLL -b 'dc=example,dc=com' -h localhost -p 389 "(objectclass=ldapsubentry)"
dn: cn=cn\3DnsPwPolicyEntry\2Cuid\3Dtuser1\2Cou\3Dpeople\2Cdc\3Dexample\2Cdc\3
Dcom,cn=nsPwPolicyContainer,ou=People,dc=example,dc=com
objectClass: top
objectClass: ldapsubentry
objectClass: passwordpolicy
cn: cn=nsPwPolicyEntry,uid=tuser1,ou=people,dc=example,dc=com
passwordExp: on
passwordMaxAge: 86400
passwordSendExpiringTime: on
}}}

6) Requested the password expiry warning for that user but it didn't work
{{{
[root@corp testing]# ldapsearch -xLLL -D 'uid=tuser1,ou=people,dc=example,dc=com' -h localhost -p 389 -w secret123 -b 'dc=example,dc=com' -e ppolicy uid=tuser1 dn
dn: uid=tuser1,ou=People,dc=example,dc=com
}}}

We need to use the -e ppolicy option to get the password expiry warning time for an entry like this
{{{
ldapsearch -xLLL -D 'uid=tuser,ou=people,dc=example,dc=com' -w secret123 -h localhost -p 389 -b 'dc=example,dc=com' -e ppolicy uid=tuser dn
}}}

but any usage examples like this are not present in the design document, it would be nice to have some usage examples like this included in the design document

Also, the '''passwordWarning''' attribute is set to 86400 implicitly and if the global password policy configured as follows:
'''passwordExp''' : on
'''passwordMaxAge''' : 86400
'''passwordSendExpiringTime''' : off

the server will return password expiry warning, since the password is already in the warning period. So this information should be mentioned somewhere in the design document

Replying to [comment:12 spichugi]:

The test looks good. As a precautionary step I'm requesting that you add a time.sleep(0.5) at the end of:

global_policy()
global_policy_default()
local_policy()
set_conf_attr()

When I was getting all the tests in order I found that when updating password policy, or any anything in cn=config, a short sleep was needed before trying to test that config change. Just trying to prevent false positive failures. Thanks!

Replying to [comment:13 mreynolds]:

Replying to [comment:12 spichugi]:

The test looks good. As a precautionary step I'm requesting that you add a time.sleep(0.5) at the end of:

global_policy()
global_policy_default()
local_policy()
set_conf_attr()

When I was getting all the tests in order I found that when updating password policy, or any anything in cn=config, a short sleep was needed before trying to test that config change. Just trying to prevent false positive failures. Thanks!

Thank you! Yeah, we've suffered enough with that "timing" stuff. :)
I've implemented your suggestions, the tests PASSed once again.

To ssh://git.fedorahosted.org/git/389/ds.git

Pushed to master:
43997fa..4cbde48 master -> master
commit 4cbde48
Author: Simon Pichugin spichugi@redhat.com
Date: Tue Aug 30 10:13:50 2016 +0200

Metadata Update from @pkundal:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.5.0
7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1700

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)
3 years ago

Login to comment on this ticket.

Metadata
None
None
None
major
ack
RHCust
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.