A correction (in line, at the end)
On 2022/09/30 10:48, Emmanuel Lécharny wrote:
Hi Shawn,
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)
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)
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.
Actually, the 'admin' user - whoever that is - would have an
PasswordPolicy AdministrativeRole identifying it as the user being able
to reset passwords.
So it would be more than just defining the area on which this 'admin'
user can act on, it will define it as this special user,; otherwise it
would be arbitrary.
We may need to add this new AdministrativeRole for that purpose, indeed.
--
*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]
