13 thoughts on “Exploring password lifetime and grace period

  1. Hi, Ed. I have an issue with profile’s settings of password_life_time and password_grace_time. I’m totally agree with your comments & tests cases, but in my database (11GR2), i have a profile created with password_life_time and password_grace_time settings (not default). The weird is the “password_life_time” behavior: It doesn’t count the days from the last date of password’s change (or it seems that ignore that value or something like that.. ). Example:

    – last password change time = 24-feb-2015
    – password_life_time = 4
    – password_grace_time = 2

    Based on these settings, we can determinate:

    – expire_date = 28-feb-2015

    I logon into the db on March 02 (I expected an advice about “grace time login” or a request to password’s change inmediately, because “expire_date = 28-feb-2015” then on March 02 the password should expire….) but i received an advice of the type “ORA-28002: the password will expire within 2 days”.

    This means that days defined through “password_life_time” are not considerated as “continous days”. This is correct??? Is the behavior expected?

    Please let me know your opinion.
    Thanks.

    Nicolás

    • The key elements at logon time (and thus, which return message you get) are expiry_date and account_status (see dba_users). Password lifetime is not involved at this point. The first time a user logs on after the current value of expiry_date, he will receive ORA-28002 and two things happen to his account. One, the account_status will be changed from ‘OPEN’ to ‘EXPIRED(GRACE)’ and (two) expiry_date is recalculated to sysdate + profile grace_period. The only time the profile settings for password lifetime comes into play is at the time a password is changed, and then it is only used to compute a new expiry_date.

      I hope this helps clarify. If not, let’s try again.

      • Ed! Thanks for your time & explanation.
        I understood everything that you told me and i confirme that’s the expected behavior.
        Again, thanks a lot!
        Regards.

      • Hello Ed,
        In other words we should not expect a user, that has not signed on for days or months after the expiration date, to be immediately expired. They will always be given the Password_Grace_Time. Thank you, Guy

      • Exactly.
        Think about it from a database performance perspective. What would be the cost of constantly (and I mean CONSTANTLY) trawling through the user table, comparing everyone’s expiry_date to sysdate so that it could expire someone without warning? And not only a performance cost within the database. What if your expiry_date was on a weekend. You wouldn’t want to come to work Monday morning and find yourself totally locked out, requiring a call to the help desk (probably forwarded to the DBA) to reinstate. And since expiry_date and sysdate resolve down to the second, you could even get locked out in the middle of a work day.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s