On 2022/10/04 15:06, Shawn McKinney wrote:


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.

Well, I suspect this was an implementation dependent issue.



  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.

Understood. Thez pwdPolicySubEntry attribute is used to point to the policy that applies for this specific entry. This is probably what OpenLDAP uses.

Administrative role is a different mechanism which allows the definition of a set of entries in the DiT that are subject of a policy, without having to update each entry: either the entry is part of the defined administrative area, or not. It's convenient, but it requires some extra work.


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]


--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
[email protected] https://www.busit.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to