On 3/25/21 11:28 PM, William Brown wrote:
On 25 Mar 2021, at 17:49, thierry bordaz <tbor...@redhat.com> wrote:
On 3/25/21 3:20 AM, William Brown wrote:
On 25 Mar 2021, at 12:00, Mark Reynolds <mreyno...@redhat.com> wrote:
On 3/24/21 8:32 PM, William Brown wrote:
I think maybe it could be easy to visualise it.
We have time going from past to future like:
past ---------------------------------------------------------> future
So we want a window of:
* When can the OTP start to be used?
* When is the OTP no longer able to be used?
So my thinking is:
past ---------------------------------------------------------> future
^ ^ ^
| | |
otp created | |
otp valid from |
otp expire at
So I would say otp valid from and the otp expire should be *absolute* date
times in UTC.
Hi William
Good idea of that graphic. I am sorry to be so slow to understand but still
things are not clear.
There are the attributes of the password policy and the operational attribute
of the user account.
I think you meant and I agree with you that operational attributes (in the user
account) should be absolute date.
What is not clear to me is how to compute those operational attributes from the
password policy.
I see three options:
• password policy contains absolute time (e.g. passwordOTPValidFromUTC)
=> account.validFrom = policyValidFromUTC
• password policy contains a delay after OTP create/reset (e.g.
passwordOTPValidFromDelay) => account.validFrom = Now + policyValidFromDelay
• password policy contains both and if both are set we should give the
priority to one or the other
If a password policy is a stable entry, then they should not contain absolute
time. If we imagine password policy created on purpose to do a bunch of
registration, then that is okay if they contain absolute time.
Do you think we should support password policy with absolute time ?
No we should not store actual times in the config. These time values need to
live in the entry itself, just like passwordExpirationtime. Perhaps this is a
good candidate to handle through the CLI (maybe even a new task that uses a
filter, base, etc)?
I'm a bit confused about this answer but:
Theirry thought you wanted to set:
dn: cn=config
passwordOTPStartTime: 2021034578489754Z
But I was saying it should be in the entry, not cn=config, like how we use
passwordExpirationtime:
uid=mark,dc=example,dc=com
passwordOTPStartTime: 2021034578489754Z
Yep, this is exactly what I meant :)
Mark
I think there are no "operational" attributes here. These should all be
absolute dates, set on the entry. No calculation or whatever needed.
Thanks Mark, William for the clarification.
Actually OTP is an extension of the current password policy. So there are new
attribute in the password policy entry and new (operational) attributes in the
account entry.
I understand and agree that attributes (in the account entry) that represent a
window of validity will be absolute time.
For example we will have, assuming that an admin reset the userpassword of
'uid=mark' at 10AM we will have
dn: cn=config
passwordMustChange: on
passwordOTPValidFromDelay: 1800
passwordOTPExpireDelay: 3600
passwordOTPMaxUse: 3
I actually don't think any of these fields in cn=config are required, and
actually limit the capability of this.
This was an example for global password policy settings. These new
attributes are supported in global pwp but also in pwpolicysubentries.
dn: uid=mark,dc=example,dc=com
userpassword: xxx
pwdOTPReset: true
pwdOTPUseCount: 0
pwdOTPValidFrom: 20210325103000Z
pwdOTPExpireAt: 20210325110000Z
You should add pwdOTPMaxUse: X here.
The reason I say this is it grants flexibility. Imagine say ... we are
enrolling 10,000 students to a university and creating their new accounts. We
want to set exact times on their accounts and say ... given them 10 tries or
something.
But at the same time we need to reset someones account. For them, we want them
to have say ... 1 attempt to do the reset, and have a different time window.
All the cn=config fields do here is confuse and complicate the system - what is their
purpose but to "template" out some values into the entry?
The only benefit I see (but I may miss something) in adding pwdOTPMaxUse
in the account entry is in the case the password policies may change
frequently. If we want to be sure the exact setting of the password
policy at the time of the reset will be enforced, even if the password
policy change later, then we have to copy that value in the entry.
During a bind attempts, we are retrieving the password policy that
applies to that target bind entry and we can enforce the pwp without
storing it in the target entry.
thanks
thierry
In this matter, I think that all the OTP fields should be on the entry to allow
more possibilities of how the pwdOTP can be used in diverse situations.
Meaning the user 'Mark' should complete his registration between 10:30AM and
11AM and he will be granted 3 tries to bind with the registration password and
change his password
thanks
thierry
There is no policy at all. Basicly you just have a mechanic that sets on the
account that this password is only valid in these time windows, and can only be
used a maximum number of times.
Mark
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
--
389 Directory Server Development Team
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
