> On Sep 30, 2022, at 3:48 AM, Emmanuel Lécharny <[email protected]> wrote:
>
>
> On 2022/09/29 16:57, Shawn McKinney wrote:
>>> On Sep 29, 2022, at 8:11 AM, Emmanuel Lécharny <[email protected]> wrote:
>>>
>>>>> * It's mentionned that some PasswordPolicies may be defined as
>>>>> subentries, and we may even define some administrativeRole to define the
>>>>> part of the DIT that is subject to this subentry. Again, a first
>>>>> implementation should focus on having the global PasswordPolicy working.
>>>>> Defining an AdminsitrativeRole induce some complexity that I'd rather
>>>>> move away atm.
>>>> Just a few words in favor of this. For example, min age. When a user
>>>> entry is created, they may need an admin reset. If the min age is long
>>>> duration the admin will be prevented.`
>>>
>>> I'm nut sure I get what you mean... I don't see a valid reason to do an
>>> admin reset when a user is created. Admin will create the user, and we may
>>> have a request for the user to change its password, but it may be unrelated
>>> to what you wrote. What is the min age has to do with the fact we don't
>>> implement administrativeRoles ?
>>>
>>> VCan you clarify?
>> Let’s take an example pw policy:
>> - name: default
>> sn: 'default'
>> cn: 'default'
>> description: 'test ppolicy'
>> pwdAttribute: userPassword
>> pwdAllowUserChange: 'TRUE'
>> pwdSafeModify: 'FALSE'
>> pwdInHistory: 5
>> pwdCheckQuality: 2
>> pwdMinLength: 6
>> pwdMinAge: 86400
>> pwdExpireWarning: 2880
>> pwdGraceAuthNLimit: 0
>> pwdLockout: 'TRUE'
>> pwdFailureCountInterval: 600
>> pwdMustChange: 'FALSE'
>> pwdLockoutDuration: 300
>> pwdMaxFailure: 5
>> pwdMaxAge: 94608000
>> Which is set as the default for the directory.
>> Here the minAge is set to 1 day. Next we create a user entry via some
>> automatic mechanism.
>
> So here this is a creation. This does nit count as a modification (reminder:
> Password Change is a Password Modify Operation operation when the current
> user performs the Password Change)
Actually, it happened recently in an OpenLDAP env on a newly created user. The
minAge prevented admin reset.
> For whatever reason the new user doesn’t know the password and requests a
> reset before 1 day has elapsed.
>
> The first modification should pass. The second won't.
>
>
> So, the admin attempts a pw reset but can’t b/c the min age has not expired.
>
> That should never happen, as I assume the password admin has a complete
> accesss to the policy and the passwords.
>
> Now, to be clear, the draft stipulates:
> "The access control that is used to determine whether an identity is a
> password administrator or password policy administrator is beyond the scope
> of this document"
>
> Which means there is no description on how the server detects that a user is
> a password admin.
>
>> With admin roles, the administrator is subjected to a different pw policy on
>> the user’s entry. Presumably one that doesn’t have the min age restriction.
>
> Are "admin roles" are equivalent to "Adminsistrative Roles" for you? In LDAP,
> Administrative Roles are a very specific thing. they define a specific DiT
> area on which applies a specific operation, like:
> - collective atributes (Which attribute should be added to en entry
> dependning on its position in teh DiT)
> - AccessControl (which kind of ACl applies to which part of teh DiT)
> - Schema (which schema applies to the defined DiT area)
Used the incorrect term. OpenLDAP calls them ‘rules’. It allows users who have
a matching attribute be subjected to a different policy.
This is part of their support for ppolicy10.
>
> In the PasswordPolicy use case, the Administrative Role would simply cover
> the definition of the area that will be subject to the password policy, but
> it says nothiong about which user can leverage it.
>
> This is a grey area, to be frank ;-)-
Agreed
—
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
