Are there settings in FreeIPA similar to the setting available from the chage command ? I am specifically looking for a setting for the time after a password expires to allow the user to update it.
I am looking for the same "grace period" that the non-IPA shell password has. From the change man page: -M, --maxdays MAX_DAYS Set the maximum number of days during which a password is valid. When MAX_DAYS plus LAST_DAY is less than the current day, the user will be required to change his/her password before being able to use his/her account. -I, --inactive INACTIVE Set the number of days of inactivity after a password has expired before the account is locked. The INACTIVE option is the number of days of inactivity. A user whose account is locked must contact the system administrator before being able to use the system again.
I find nothing like this in the documentation. I do know, however, that when a user is initially created, the password expire time is set to the current clock time. When the user logs in for the first time, they are prompted to change their password. I am looking for a parameter -- like chage's INACTIVE -- that defines a grace period from the time the password expires until the account is locked and requires admin intervention. Or does that only happen for the account creation ? ______________________________________________________________________________________________
Daniel E. White daniel.e.white@nasa.govmailto:daniel.e.white@nasa.gov NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290
White, Daniel E. (GSFC-770.0)[NICS] via FreeIPA-users wrote:
Are there settings in FreeIPA similar to the setting available from the chage command ? I am specifically looking for a setting for the time after a password expires to allow the user to update it.
I am looking for the same "grace period" that the non-IPA shell password has. From the change man page:
-M, --maxdays MAX_DAYS Set the maximum number of days during which a password is valid. When MAX_DAYS plus LAST_DAY is less than the current day, the user will be required to change his/her password before being able to use his/her account. -I, --inactive INACTIVE Set the number of days of inactivity after a password has expired before the account is locked. The INACTIVE option is the number of days of inactivity. A user whose account is locked must contact the system administrator before being able to use the system again.
I find nothing like this in the documentation.
I do know, however, that when a user is initially created, the password expire time is set to the current clock time. When the user logs in for the first time, they are prompted to change their password. I am looking for a parameter -- like chage's INACTIVE -- that defines a grace period from the time the password expires until the account is locked and requires admin intervention.
Or does that only happen for the account creation ?
There is nothing automated to do this. Theoretically you could use krbprincipalexpiration to enforce this but there is nothing that will add some offset to it when a password is changed.
I think it would be fairly straightforward to add but it would require a new policy attribute, new CLI/UI to manage that attribute, etc.
The actual setting of the attribute is probably like 5 lines of code.
rob
On Mon, Jul 6, 2020 at 10:12 PM Rob Crittenden via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
White, Daniel E. (GSFC-770.0)[NICS] via FreeIPA-users wrote:
Are there settings in FreeIPA similar to the setting available from the chage command ? I am specifically looking for a setting for the time after a password expires to allow the user to update it.
I am looking for the same "grace period" that the non-IPA shell password has. From the change man page:
-M, --maxdays MAX_DAYS Set the maximum number of days during which a password is valid. When MAX_DAYS plus LAST_DAY is less than the current day, the user will be required to change his/her password before being able to use his/her account. -I, --inactive INACTIVE Set the number of days of inactivity after a password has expired before the account is locked. The INACTIVE option is the number of days of inactivity. A user whose account is locked must contact the system administrator before being able to use the system again.
I find nothing like this in the documentation.
I do know, however, that when a user is initially created, the password expire time is set to the current clock time. When the user logs in for the first time, they are prompted to change their password. I am looking for a parameter -- like chage's INACTIVE -- that defines a grace period from the time the password expires until the account is locked and requires admin intervention.
Or does that only happen for the account creation ?
There is nothing automated to do this. Theoretically you could use krbprincipalexpiration to enforce this but there is nothing that will add some offset to it when a password is changed.
I think it would be fairly straightforward to add but it would require a new policy attribute, new CLI/UI to manage that attribute, etc.
Or ipa-epn ( https://pagure.io/freeipa/issue/3687 ) could be enhanced to do that. It is able to warn users their passwords will expire in the near future ; locking accounts might require running on a replica but adding that feature should be straightforward.
The actual setting of the attribute is probably like 5 lines of code.
Yes, the change is probably very small.
rob _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Merci, François (I remember that much high school French) ______________________________________________________________________________________________
Daniel E. White daniel.e.white@nasa.govmailto:daniel.e.white@nasa.gov NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290
On Mon, Jul 6, 2020 at 10:25 PM White, Daniel E. (GSFC-770.0)[NICS] daniel.e.white@nasa.gov wrote:
Merci, François
You're welcome Daniel.
(I remember that much high school French)
Hah :)
Daniel E. White daniel.e.white@nasa.gov
NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771
Office: (301) 286-6919
Mobile: (240) 513-5290
For your amusement: Red Hat Support referred me to
https://bugzilla.redhat.com/show_bug.cgi?id=1273040 (A RHEL 7 RFE)
and
https://bugzilla.redhat.com/show_bug.cgi?id=1654395 (The same RFE, pushed to RHEL 8)
…, saying, "You can also set a policy to automatically disable an account if the password has not been changed within X number of weeks after the password has expired"
Maybe I can get some technical detail here.
When a new login is created, it has a "temporary" password that must be changed. I have logins I created 4 months ago that have not yet been used. Will the initial password still work ?
In the documentation about password policy, referencing the "Max lifetime" attribute, it says , "Example: Max lifetime = 90 -- User passwords are valid only for 90 days. After that, IdM prompts users to change them. "
How long can the user wait and still be able to update the password ?
What controls these behaviors ?
______________________________________________________________________________________________
Daniel E. White daniel.e.white@nasa.govmailto:daniel.e.white@nasa.gov NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290
From: François Cami fcami@redhat.com Date: Monday, July 6, 2020 at 16:22 To: FreeIPA freeipa-users@lists.fedorahosted.org Cc: Daniel White daniel.e.white@nasa.gov, Rob Crittenden rcritten@redhat.com Subject: [EXTERNAL] Re: [Freeipa-users] Re: Password Policy Question
On Mon, Jul 6, 2020 at 10:12 PM Rob Crittenden via FreeIPA-users <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org> wrote:
White, Daniel E. (GSFC-770.0)[NICS] via FreeIPA-users wrote:
Are there settings in FreeIPA similar to the setting available from the chage command ? I am specifically looking for a setting for the time after a password expires to allow the user to update it.
I am looking for the same "grace period" that the non-IPA shell password has. From the change man page:
-M, --maxdays MAX_DAYS Set the maximum number of days during which a password is valid. When MAX_DAYS plus LAST_DAY is less than the current day, the user will be required to change his/her password before being able to use his/her account. -I, --inactive INACTIVE Set the number of days of inactivity after a password has expired before the account is locked. The INACTIVE option is the number of days of inactivity. A user whose account is locked must contact the system administrator before being able to use the system again.
I find nothing like this in the documentation.
I do know, however, that when a user is initially created, the password expire time is set to the current clock time. When the user logs in for the first time, they are prompted to change their password. I am looking for a parameter -- like chage's INACTIVE -- that defines a grace period from the time the password expires until the account is locked and requires admin intervention.
Or does that only happen for the account creation ?
There is nothing automated to do this. Theoretically you could use krbprincipalexpiration to enforce this but there is nothing that will add some offset to it when a password is changed.
I think it would be fairly straightforward to add but it would require a new policy attribute, new CLI/UI to manage that attribute, etc.
Or ipa-epn ( https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_freeipa_issue... ) could be enhanced to do that. It is able to warn users their passwords will expire in the near future ; locking accounts might require running on a replica but adding that feature should be straightforward.
The actual setting of the attribute is probably like 5 lines of code.
Yes, the change is probably very small.
rob _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.orgmailto:freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_... List Guidelines: https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_... List Archives: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_...
White, Daniel E. (GSFC-770.0)[NICS] wrote:
For your amusement:
Red Hat Support referred me to
https://bugzilla.redhat.com/show_bug.cgi?id=1273040 (A RHEL 7 RFE)
and
https://bugzilla.redhat.com/show_bug.cgi?id=1654395 (The same RFE, pushed to RHEL 8)
IMHO those contain a different question than you're asking. Those BZ are about marking unused accounts vs allowing a grace period after password expiration.
…, saying, "You can also set a policy to automatically disable an account if the password has not been changed within X number of weeks after the password has expired"
No, you can't, there is no policy setting for that. And I don't believe that is in the scope of the BZ either. Password expiration isn't a consideration and is, IMHO, a separate policy question like you suggested: a grace period after expiration before marking account inactive.
Maybe I can get some technical detail here.
When a new login is created, it has a "temporary" password that must be changed. I have logins I created 4 months ago that have not yet been used. Will the initial password still work ?
Yes.
In the documentation about password policy, referencing the "Max lifetime" attribute, it says ,
"Example: Max lifetime = 90 -- User passwords are valid only for 90 days. After that, IdM prompts users to change them. "
How long can the user wait and still be able to update the password ?
Forever. Max life is password expiration, min life prevents changing passwords too frequently.
What controls these behaviors ?
As I said before, I think only krbprincipalexpiration would help here. There is no policy/setting in IPA to disable an account X days after a password has expired.
That said, this is probably scriptable using LDAP to find the entries and call ipa user-disable <id> to mark inactive the users.
rob
*______________________________________________________________________________________________*
* *
*Daniel E. White** **daniel.e.white@nasa.gov mailto:daniel.e.white@nasa.gov***
*NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771***
*Office: (301) 286-6919***
*Mobile: (240) 513-5290*
*From: *François Cami fcami@redhat.com *Date: *Monday, July 6, 2020 at 16:22 *To: *FreeIPA freeipa-users@lists.fedorahosted.org *Cc: *Daniel White daniel.e.white@nasa.gov, Rob Crittenden rcritten@redhat.com *Subject: *[EXTERNAL] Re: [Freeipa-users] Re: Password Policy Question
On Mon, Jul 6, 2020 at 10:12 PM Rob Crittenden via FreeIPA-users
<freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org> wrote:
White, Daniel E. (GSFC-770.0)[NICS] via FreeIPA-users wrote: > Are there settings in FreeIPA similar to the setting available from the > chage command ? I am specifically looking for a setting for the time > after a password expires to allow the user to update it. > > > > I am looking for the same "grace period" that the non-IPA shell password > has. From the change man page: > > -M, --maxdays MAX_DAYS > Set the maximum number of days during which a password is valid. When > MAX_DAYS plus LAST_DAY is less than the current day, the user will be > required to change his/her password before being able to use his/her > account. > -I, --inactive INACTIVE > Set the number of days of inactivity after a password has expired before > the account is locked. The INACTIVE option is the number of days of > inactivity. A user whose account is locked must contact the system > administrator before being able to use the system again. > > > > I find nothing like this in the documentation. > > I do know, however, that when a user is initially created, the password > expire time is set to the current clock time. > When the user logs in for the first time, they are prompted to change > their password. > I am looking for a parameter -- like chage's INACTIVE -- that defines a > grace period from the time the password expires until the account is > locked and requires admin intervention. > > Or does that only happen for the account creation ? There is nothing automated to do this. Theoretically you could use krbprincipalexpiration to enforce this but there is nothing that will add some offset to it when a password is changed. I think it would be fairly straightforward to add but it would require a new policy attribute, new CLI/UI to manage that attribute, etc.Or ipa-epn ( https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_freeipa_issue...) could be enhanced
to do that.
It is able to warn users their passwords will expire in the near
future ; locking accounts might require running on a replica but
adding that feature should be straightforward.
The actual setting of the attribute is probably like 5 lines of code.Yes, the change is probably very small.
rob _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_en-2DUS_project_code-2Dof-2Dconduct_&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=ef_FKlWa7jWGmQqTrjkcoDY1VuVtcI_10ClISjA3_V8&m=RA2y7EwwWifTxZve3lLTsSYYbawQbs5j5mSVBSXHG48&s=GudRxlrLOBc4jj0aypGXFIp2ej1smDQ3xLSpEwboPHc&e= List Guidelines: https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=ef_FKlWa7jWGmQqTrjkcoDY1VuVtcI_10ClISjA3_V8&m=RA2y7EwwWifTxZve3lLTsSYYbawQbs5j5mSVBSXHG48&s=tNn6K6JZCBNp2raUPJn5G7rm3NGmTlaz6YT_GrJ1qcc&e= List Archives: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_archives_list_freeipa-2Dusers-40lists.fedorahosted.org&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=ef_FKlWa7jWGmQqTrjkcoDY1VuVtcI_10ClISjA3_V8&m=RA2y7EwwWifTxZve3lLTsSYYbawQbs5j5mSVBSXHG48&s=jpZ3DatYvFaw-7xD5N6XRk8oXCRkoE7tObit6Z6S4Xo&e=
Rob Crittenden wrote:
White, Daniel E. (GSFC-770.0)[NICS] wrote:
For your amusement:
Red Hat Support referred me to
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_sho... (A RHEL 7 RFE)
and
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_sho... (The same RFE, pushed to RHEL 8)
IMHO those contain a different question than you're asking. Those BZ are about marking unused accounts vs allowing a grace period after password expiration.
This is why I started with "For your amusement"
…, saying, "You can also set a policy to automatically disable an account if the password has not been changed within X number of weeks after the password has expired"
No, you can't, there is no policy setting for that. And I don't believe that is in the scope of the BZ either. Password expiration isn't a consideration and is, IMHO, a separate policy question like you suggested: a grace period after expiration before marking account inactive.
Maybe I can get some technical detail here.
When a new login is created, it has a "temporary" password that must be changed. I have logins I created 4 months ago that have not yet been used. Will the initial password still work ?
Yes.
Thank you
In the documentation about password policy, referencing the "Max lifetime" attribute, it says ,
"Example: Max lifetime = 90 -- User passwords are valid only for 90 days. After that, IdM prompts users to change them. "
How long can the user wait and still be able to update the password ?
Forever. Max life is password expiration, min life prevents changing passwords too frequently.
Again, thank you.
What controls these behaviors ?
As I said before, I think only krbprincipalexpiration would help here. There is no policy/setting in IPA to disable an account X days after a password has expired.
That said, this is probably scriptable using LDAP to find the entries and call ipa user-disable <id> to mark inactive the users.
rob
Actually, I do not want to disable accounts at all.
A user requested a password reset. I found out he was trying to log in to an application that uses IdM for credentials - one of the few we were able to get working. Based on this new information, I suspect that there were multiple attempts to log in to the app, eventually causing a lockout due to "failed" authentication.
When authenticating to IdM/FreeIPA thru an app, I suspect it won't tell you that your password expired, just that the login failed. Is that a reasonable suspicion ?
Again, thanks to all you FreeIPA folks for being here to answer questions that Tier One Red Hat support cannot answer. ______________________________________________________________________________________________
Daniel E. White daniel.e.white@nasa.gov NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290
White, Daniel E. (GSFC-770.0)[NICS] wrote:
Rob Crittenden wrote:
White, Daniel E. (GSFC-770.0)[NICS] wrote:
...
What controls these behaviors ?
As I said before, I think only krbprincipalexpiration would help here. There is no policy/setting in IPA to disable an account X days after a password has expired.
That said, this is probably scriptable using LDAP to find the entries and call ipa user-disable <id> to mark inactive the users.
rob
Actually, I do not want to disable accounts at all.
A user requested a password reset. I found out he was trying to log in to an application that uses IdM for credentials - one of the few we were able to get working. Based on this new information, I suspect that there were multiple attempts to log in to the app, eventually causing a lockout due to "failed" authentication.
When authenticating to IdM/FreeIPA thru an app, I suspect it won't tell you that your password expired, just that the login failed. Is that a reasonable suspicion ?
Over LDAP, yes. https://pagure.io/freeipa/issue/1539
Again, thanks to all you FreeIPA folks for being here to answer questions that Tier One Red Hat support cannot answer.
The advantage I have is that I wrote the password policy code.
rob
Is it worth a Feature Request ? Either here or at Red Hat ?
______________________________________________________________________________________________
Daniel E. White daniel.e.white@nasa.govmailto:daniel.e.white@nasa.gov NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290
From: Rob Crittenden rcritten@redhat.com Date: Monday, July 6, 2020 at 16:12 To: FreeIPA freeipa-users@lists.fedorahosted.org Cc: Daniel White daniel.e.white@nasa.gov Subject: [EXTERNAL] Re: [Freeipa-users] Password Policy Question
White, Daniel E. (GSFC-770.0)[NICS] via FreeIPA-users wrote: Are there settings in FreeIPA similar to the setting available from the chage command ? I am specifically looking for a setting for the time after a password expires to allow the user to update it.
I am looking for the same "grace period" that the non-IPA shell password has. From the change man page:
-M, --maxdays MAX_DAYS Set the maximum number of days during which a password is valid. When MAX_DAYS plus LAST_DAY is less than the current day, the user will be required to change his/her password before being able to use his/her account. -I, --inactive INACTIVE Set the number of days of inactivity after a password has expired before the account is locked. The INACTIVE option is the number of days of inactivity. A user whose account is locked must contact the system administrator before being able to use the system again.
I find nothing like this in the documentation.
I do know, however, that when a user is initially created, the password expire time is set to the current clock time. When the user logs in for the first time, they are prompted to change their password. I am looking for a parameter -- like chage's INACTIVE -- that defines a grace period from the time the password expires until the account is locked and requires admin intervention.
Or does that only happen for the account creation ?
There is nothing automated to do this. Theoretically you could use krbprincipalexpiration to enforce this but there is nothing that will add some offset to it when a password is changed.
I think it would be fairly straightforward to add but it would require a new policy attribute, new CLI/UI to manage that attribute, etc.
The actual setting of the attribute is probably like 5 lines of code.
rob
On Mon, Jul 6, 2020 at 10:23 PM White, Daniel E. (GSFC-770.0)[NICS] via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Is it worth a Feature Request ? Either here or at Red Hat ?
Ideally through Red Hat Support yes.
Daniel E. White daniel.e.white@nasa.gov
NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771
Office: (301) 286-6919
Mobile: (240) 513-5290
From: Rob Crittenden rcritten@redhat.com Date: Monday, July 6, 2020 at 16:12 To: FreeIPA freeipa-users@lists.fedorahosted.org Cc: Daniel White daniel.e.white@nasa.gov Subject: [EXTERNAL] Re: [Freeipa-users] Password Policy Question
White, Daniel E. (GSFC-770.0)[NICS] via FreeIPA-users wrote:
Are there settings in FreeIPA similar to the setting available from the
chage command ? I am specifically looking for a setting for the time
after a password expires to allow the user to update it.
I am looking for the same "grace period" that the non-IPA shell password
has. From the change man page:
-M, --maxdays MAX_DAYS
Set the maximum number of days during which a password is valid. When
MAX_DAYS plus LAST_DAY is less than the current day, the user will be
required to change his/her password before being able to use his/her
account.
-I, --inactive INACTIVE
Set the number of days of inactivity after a password has expired before
the account is locked. The INACTIVE option is the number of days of
inactivity. A user whose account is locked must contact the system
administrator before being able to use the system again.
I find nothing like this in the documentation.
I do know, however, that when a user is initially created, the password
expire time is set to the current clock time.
When the user logs in for the first time, they are prompted to change
their password.
I am looking for a parameter -- like chage's INACTIVE -- that defines a
grace period from the time the password expires until the account is
locked and requires admin intervention.
Or does that only happen for the account creation ?
There is nothing automated to do this. Theoretically you could use
krbprincipalexpiration to enforce this but there is nothing that will
add some offset to it when a password is changed.
I think it would be fairly straightforward to add but it would require a
new policy attribute, new CLI/UI to manage that attribute, etc.
The actual setting of the attribute is probably like 5 lines of code.
rob
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
freeipa-users@lists.fedorahosted.org
-
François Cami -
Rob Crittenden -
White, Daniel E. (GSFC-770.0)[NICS]