Oh right, how did I miss this. So one needs to set "altStateAttrName: createTimestamp", and configure "accountInactivityLimit". In this case this will globally apply to all accounts with the policy, isn't it? It still won't allow me to set expiration date per account (Unless I create a policy for each account?)
Cenk On Tue, Oct 3, 2023 at 9:39 AM Thierry Bordaz <tbor...@redhat.com> wrote: > > 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 <tbor...@redhat.com> 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 <marey...@redhat.com> >> 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@lists.fedoraproject.org >>> > To unsubscribe send an email to >>> 389-users-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-users@lists.fedoraproject.org >>> > 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@lists.fedoraproject.org >> To unsubscribe send an email to 389-users-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-users@lists.fedoraproject.org >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> >>
_______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-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-users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
