zjicp (zjicp) asked a question.
Our current Authentication policy doesn't have the password age section configured (I know, it's bad).
I am testing a new self serve policy with password age configured. I'm concerned as during my test, when I turned on the policy, my test user's password (upon login) received a password expired prompt and that it should change it.
This is what I expected and I foresee that we will get hit with tickets from customers stating that their password has expired due to a new push that we made in OKTA and I'd like to try and avoid this.
I was thinking, is there a way that support, from a database perspective, touch the password fields to avoid this when the policy is turned on? I'm requesting some feedback on the best way to go about this.
Essentially, you'd like to start the password expiration clock at zero when you turn on the new policy, otherwise everyone that's been in Okta for longer than your password reset period (say, 90 days) will immediately be prompted to do so, yes?
How long have you been an Okta customer? If it's less than ~2.5 years perhaps you can turn the new policy on, set the password expiration age to something up to 999 days (so they won't all expire immediately) and then do an internal communication campaign to have people start their password resets so it doesn't happen all at once.
Were most of your users all imported at once, and therefore set their passwords all around the same time? If they did, then whether they all reset now, or they all reset in N days from now, or whether Okta Support resets password age counters (which I'm pretty sure they won't be able or willing to do) then isn't it going to be a big bang scenario at some point in time?
Could you create a new group and only have the new password policy assigned to that group and then do a gradual, controlled addition of all users to that group until eventually everyone's in it?
I think it will be difficult to avoid educating your users about doing a password change due to the new policy.