On 2022/09/21 15:31, Shawn McKinney wrote:
On Sep 20, 2022, at 3:25 PM, Emmanuel Lécharny <[email protected]> wrote:
After a first pass through the ApacheDS issues, and a removal of some of them
(down to 379 from 410 issues), I'm going to work on the PasswordPolicy part of
the server. On eof the reason is that 17 issues are related to this part, and
also because there is some inconsistency in the way we deal with transaction
when updating some entries, causing some JDBM breakage.
There is also a new version for the PasswordPolicy draft [1] and it would be
useful to have our implementation folloiwng the few changes.
Here is how I'll process:
- First review the existing logic, wrt the RFC draft.
- Then probably create a dedicated interceptor, which will be set before the
authentication interceptor: there is no technical or functionnal reason to mix
those two interceptors AFAICT, that makes the code more complex to implement.
There are 3 areas where I think I will not follow the draft, at least in this
version:
* The userPassword attribute is not considered as the only one that can contain
some password. There is an attributeType that is defined which gives the list
of attribute that may contain the password. I think a first step is to ignore
that value. Once it works, going further should not really be such a pain...
Agreed, renaming pw attribute is limited, if not dubious value.
It's not a rename, it's defining the attribute which will contain the
password. It can be whatever the user wants. But again, it's of little
value.
* 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?
Thanks !
Having said that, it’s still a bit of a corner case. I’m sure there are other
reasons though.
Having said that, this work should progress at a comfortable pace, so I’m good
with a phased approach.
* Last not least, and it relates to the first point, I will not handle the
attributeType option used to defined with password attribute is impacted by a
PasswordPolicy rule. For instance:
pwdChangedTime;pwd-userPassword: 20000103121520Z
will not be taken into account now.
Feel free to comment !
I’m +1 on this work. My goal is to update fortress to follow, adding tests for
verification.
Thanks
—
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]
