About Active Directory Desktop Single Sign-on and Just-In-Time provisioning

When you implement on-premises or agentless Desktop Single Sign-on (DSSO) in your environment, this is the process flow when importing users using Just-in-Time (JIT) provisioning:

• For on-premises DSSO, IWA sends Okta the Universal Principal Name (UPN). Okta uses the UPN to locate a user. Okta doesn't perform user authentication because Kerberos validation occurs on the IIS side.

• For agentless DSSO, the web browser sends the Kerberos ticket to Okta, and relies on the Okta Active Directory (AD) agent to look up the UPN. Kerberos validation occurs in the cloud in Okta.

When a user signs in using DSSO:

• If their information is already imported and active in Okta: Okta uses the UPN to look up the user. If Okta finds the user, the profile reloads from Active Directory (AD) and the user signs in successfully.
• If their information has been imported but isn't yet active in Okta: Okta uses the UPN to look up the user. If Okta finds the user, the user profile loads from AD, activation of the user occurs, and the user signs in successfully.
• If their information hasn't been imported into Okta and JIT is enabled: Okta uses the UPN to validate users. If the Okta username format isn't a UPN and instead uses another format, Okta ignores this setting and uses the UPN validation. Examples of other formats include an email address or SamAccountName.
• If their information has not been imported into Okta and JIT is off the user's sign-in attempt fails.
• If a custom username format is used: When a new user signs in using a custom username format with JIT, Okta uses the previously used authentication method for AD user validation. UPN, SAMAccountName, or email are examples of previously used authentication methods. Okta ignores the custom setting for existing users and uses the UPN for AD user validation.