Re: Setting "lock" time of an account in the future

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 10/3/23 09:34, Cenk Y. wrote:
Thanks Mark, Thierry,

I've looked quite a bit into account policy. It allows locking an account after an inactivity limit, but from my understanding, it doesn't offer a way to lock it in a pre-configured future time without inactivity.


Not only inactivity but also account expiration (createtimestamp). https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/account-policy-plugin#account-policy-plugin-config

regards
thierry


I think this would be a useful feature. I may open a RFE.

Cheers
Cenk

On Tue, Oct 3, 2023 at 8:55 AM Thierry Bordaz <tbordaz@xxxxxxxxxx> wrote:


On 10/3/23 01:11, Mark Reynolds wrote:


On 10/2/23 4:13 AM, Cenk Y. wrote:
Hi Mark, thanks for the response.

We already use password lockout plugin, but what I need is the opposite.

I want to
* Create an account, activate it
* Set an expiration date, so that after that date account is locked.


Hi Cenk,

I agree with Mark, password base expiration is likely not what you are looking for (because of reset).

Before opening a RFE, you may check if the account policy plugin may match you need https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/account-policy-plugin

best regards
thierry

Yeah there is no way to "lock" an account that way.  You can set the password to expire, but its not the same thing and a password reset will bump that expiration time anyway.

Please file an RFE for this feature, but it could take some time until it's implemented.

https://github.com/389ds/389-ds-base/issues/new

Thanks,
Mark


Cheers
Cenk

On Fri, Sep 29, 2023 at 9:50 PM Mark Reynolds <mareynol@xxxxxxxxxx> wrote:
Actually, I was wrong there is more you need to do.

You need to enable account lockout and set a max failure count:

# dsconf slapd-INSTANCE config set passwordLockout=on passwordMaxFailure=3

Then set in each user entry:

     passwordRetryCount: 3  --> number equal to passwordMaxFailure

     retryCountResetTime: 20230929193912Z   --> you must calculate this
value (and use it for these two attributes)

     accountUnlockTime: 20230929193912Z


That works for me.

HTH,

Mark


On 9/29/23 11:40 AM, Cenk Y. wrote:
> Hello,
>
> We are running 389-ds-base.2.2.7 .
>
> While creating accounts, sometimes we know until when they need to be
> active. Is there a way to manually set a "expiration date" for the
> account, so after that date nsAccount is set to true?
>
> Having gone through rhds and 389-ds pages, it seems it's only possible
> to create a policy to deactivate accounts after an inactivity limit.
>
> I can always create a mechanism myself (such as adding a new attribute
> and checking it by a cron job ...) , but I want to see if there is a
> native way to do this?
>
> Thanks
> Cenk
>
> _______________________________________________
> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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-users@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

--
Directory Server Development Team

-- 
Directory Server Development Team

_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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-users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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-users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux