Buchan, Howard,

 

Thank you very much for your responses!

Yes, that is completely how I imagined ppolicy functionality.

The thing confusing me is that having a large number of users with different lifetimes I will need to store and manage a large number of pwdPolicy subentries. However, that is undesirable, but not critical.

 

Now please imagine the following extension of requirement:

This time I need to control global lifetime of user entry, not users' credentials lifetime. The difference is that user should be able to change password and that should not impact or extend lifetime. The only possibility to change global lifetime should be some kind of manual reset procedure (performed by LDAP administrator).

Described approach:

will not be valid anymore, because if user will change own password, then lifetime will be extended to the value of "pwdMaxAge" once again (as far as I understand).

 

Probably, solution could be to control user password change actions and modify also assigned ppolicy each time when user decides to change password (subtact seconds from last pwd change from "pwdMaxAge").

Similar for the use case, when administrator decides to reset lifetime for user entry - check "pwdChangedTime", calculate difference and set "pwdMaxAge" correspondingly. Something like this:

"pwdMaxAge" = "newLifetime_InSec" + difference_in_sec("currentTime","pwdChangeTime")

 

However, I'm not sure that it is correct approach...

What do you think, will described solution work?

Maybe there are another slapd(8) features to control global user entry lifetime?
I have heard about "shadowAccount" objectclass, is it supported by OpenLDAP and could it be helpful?

 

Thank you,

On 1/3/07, Howard Chu <hyc@symas.com> wrote:

Buchan Milne wrote:
> On Tuesday 02 January 2007 13:34, Alina Dubrovska wrote:
>> I have inspected slapo-ppolicy(5) overlay functionality, seems that:
>>
>> "pwdMaxAge=<lifetime>" + "pwdGraceAuthnLimit=0"
>>
>> would help, but then I need to setup separate policy for each user with
>> different lifetime (not acceptable).
>
> To be completely accurate, you would create a policy, and apply that policy to
> individual entries by setting the pwdPolicySubentry attribute of that entry
> to the DN of the policy.

This is completely true and correct today, but that's not how it is meant to
work in the future. Just a little FYI... Subentries are actually intended to
follow the X.500 administration model, using subtree search specifications to
define the range of the tree over which they apply. I.e., in X.500 you would
create a pwdPolicy subentry at some administration point in the DIT, defining
the policy and the range of entries that are to be subject to the policy. And
then the directory is supposed to dynamically populate the pwdPolicySubentry
operational attribute of all the affected entries, indicating which subentry
controls them. For now OpenLDAP lacks true subentry support. When the support
is added in the future, these pwdPolicySubentry operational attributes will
be read-only, dynamically generated based on the specifications in the actual
pwdPolicy subentries.

Given the lack of real subentry support it was easier to do things this way,
but in hindsight we should have made the ppolicy overlay dynamically generate
the operational attributes itself. The current implementation gives a wrong
indication of how subentries should normally work...

>> I would like to ask if slapd(8) offers features (in addition to
>> slapo-ppolicy) to control the lifetime of directory users' credentials? Is
>> there a convenient way to implement such requirement?
>
> Note the ppolicy_default option, documented in the man page, which allows you
> to have a default password policy for the entire database (which you would
> override if necessary as above).
>
> Regards,
> Buchan
>


--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun         http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/