Active Directory Desktop Single Sign-on prerequisites
These are the prerequisites for implementing a new Desktop Single Sign-on (DSSO) configuration or migrating an existing DSSO configuration:
- You have an Active Directory (AD) domain (or multiple domains) integrated with your Okta org.
- You have permissions in AD to configure a Service Principal Name (SPN). See Delegating Authority to Modify SPNs (https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/cc731241(v=ws.11).
- To use AES128/256 encryption with agentless DSSO or MS App silent activation, you must enable AES for both the AD domain as well as the service account for Okta DSSO. If it isn't enabled for the AD domain, the Kerberos error KDC_ERR_ETYPE_NOTSUPP appears in the Kerberos events log.
To enable encryption, see Windows Configurations for Kerberos Supported Encryption Type.
- Make sure that all sign-in flows and browser bookmarks use the correct URL.
- An AD service account. For this service account:
- A domain user account for the Okta tenant Kerberos service instead of a domain admin account. This is a security best practice.
- The logon to restriction is turned on with a fictitious host name and the account marked as Account is sensitive and cannot be delegated. This is a security best practice.
- You have Okta Super Administrator permissions to update the DelAuth page. App administrators may also have sufficient permissions if granted access to manage AD.