I think I know the answer but sanity check here - There’s no way to provide a “self-service” authenticator reset, correct? It makes sense to me why this isn’t possible (nor encouraged if it is) as allowing external users to reset a factor(s) in the case of forgetting, lost device, etc. may lead to MFA becoming a single point of failure.
Given that we can’t necessarily rid ourselves of help desk tickets requesting authenticator resets, are there any thoughts on how to best streamline the process? While still a manual process, the introduction of the TAC authenticator seems like a good option.
One way could be to have the end user enroll in multiple MFAs so that, in case they want to reset their MFA, they can access their Okta dashboard and manage their MFA methods.
Thanks for the response @akanksha_bhasin ! Yes this is something I will definitely advocate for as a preemptive measure moving forward - But even then I suppose the specific factors required matters. It does a user no good if they have Google Authenticator and Okta Verify (both device bound) and they lose their device. Unless the user has a 2nd factor that isn’t device bound it seems like there is no way to reset factors without the involvement of an admin.
One way I have solved for this was to leverage Okta Workflows to allow them to place themselves within scope of a group, which is then targeted for an additional authenticator (knowledge factor). This would allow them to get themselves in, reset their primary factor, and automatically revoke that group/additional factor. It worked like a charm and InfoSec was more than happy to play ball. It involves requiring them to setup that knowledge factor upon enrolling/activating in Okta. The knowledge factor can be swapped out for any factor you’d like so long as it makes everyone happy.
Hey @kiv following up on this - I’m curious if you can elaborate on this a bit:
How exactly were you able to identify the user and trigger the workflow to allow them to place themselves within the group?
For context we’ve already got a group that allows email factor, but our IT admins are just manually adding users here currently. It would be awesome to automate this like you’ve mentioned.
We needed a system that was outside the confines of Okta because if the user couldn’t get into Okta due to MFA, we needed to ensure that this process would continue to work. For us, that system was Slack. While users authenticated via SSO to establish a session, we did not have a time limit on desktop client sessions. This meant that even though users were unable to get into Okta, their Slack client would still function. We added a slash command to allow users to invoke the Okta Workflow. As soon as a user typed in “/mfa reset” into Slack, we knew all we needed to know.
The Slack app ingested the command. (Along with the user who executed it) and sent it to the API endpoint in Workflows. I looked up the Slack UsernID to get the email, looked that up in Okta to get the Okta User ID, added the user to a specific Okta group and sent the user a DM stating that they had been added, they had 15 minutes, and a link to a public facing PDF guide that outlined the process step by step. Once the 15 mins expired, they were removed from the group and another DM was sent informing them that they had been removed and if they hadn’t completed the process, they would need to perform the process again.
On the back end, the Okta group they’re added to is scoped to another Authenticator that our InfoSec team had approved. This is something that would need to be setup in advance and then removed from their scoped authenticators. All we do is put them back into scope for 15 mins and then remove them again. It was relatively easy to build out the process and flow but the hard part was ensuring that end users remembered they had the slash command as an option months if not years after they started.
This was the first Okta Workflow I had ever built and, to this day, is still one of my favorites.