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]