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 for LDAP.
- 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 isn't supported. To use AES128/256 encryption with agentless DSSO or MS App silent activation, you must enable AES for both the AD domain and 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 including the following security best practices:
- A domain user account for the Okta tenant Kerberos service instead of a domain admin account.
- The logon to restriction is turned on with a fictitious host name and the account marked as Account is sensitive and cannot be delegated.
-
Okta super administrator permissions to update the DelAuth page. App administrators may also have sufficient permissions if granted access to manage AD.