On 25 Mar 2021, at 12:00, Mark Reynolds <mreynolds(a)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.
>
> 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