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:
- An Active Directory (AD) domain (or multiple domains) integrated with your Okta org.
- Delegated authentication must be enabled. See Enable delegated authentication.
- 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).
- AES encryption type (AES128_HMAC_SHA1 and/or AES256_HMAC_SHA1) for Okta agentless DSSO. RC4 encryption is not supported. 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.
- All sign-in flows and browser bookmarks use the correct URL.
An AD service account with:
- 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 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.
Okta super administrator permissions to update the DelAuth page. App administrators may also have sufficient permissions if granted access to manage AD.