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 users are imported 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 does not perform user authentication because Kerberos validation is done 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 is done 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 is not yet active in Okta: Okta uses the UPN to look up the user. If Okta finds the user, the user profile loads from AD, the user is activated, and the user signs in successfully.
- If their information has not been imported into Okta and JIT is enabled: Okta uses the UPN to validate users. If the Okta user name format is not a UPN and another format such as an email address or SamAccountName is used, this setting is ignored and the UPN is used for validation.
- 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 custom username format is used with JIT and a new user signs in, the previously used authentication method (UPN, SAMAccountName, or email) is used for AD user validation. For existing users, the custom setting is ignored and the UPN is used for AD user validation.