When an end-user resets their Active Directory (AD) or Azure Active Directory (AAD) password, Microsoft invalidates all existing application sessions. To restore functionality, the end-user must be redirected to re-authenticate through Okta, which then issues new session tokens to Microsoft. While most web applications handle this redirect correctly, some applications, such as Microsoft Teams phones, may fail to trigger it, preventing users from signing back in.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Single Sign-On (SSO)
• Active Directory (AD)
• Azure Active Directory (AAD)

In an environment where Microsoft 365 is federated with Okta, Okta acts as the Identity Provider (IdP), and Microsoft acts as the Service Provider (SP). A password reset in AD or AAD triggers a security event that invalidates the user's Microsoft session tokens (including the Primary Refresh Token). Because Okta is the authority for identity, the SP (Microsoft) must redirect the user to the IdP (Okta) to re-verify their identity and establish a new session.

Why is re-authentication required after a password reset?

• End-users must re-authenticate through Okta after a password change. This allows Okta, as the Identity Provider, to issue a new session token to Microsoft's applications, which restores functionality.

Handling re-authentication on non-browser devices or dedicated apps

• Certain applications, particularly those that do not use a standard web browser for login (such as Microsoft Teams phones), may fail to automatically redirect users to Okta after a password reset. In these cases, the application may get stuck in a login loop or show an error. Manually signing out of the application and signing back in is often required to force the re-authentication process through Okta.

Related References

• Provision users to Office 365