Active Directory Desktop Single Sign-on known issues
These are the known issues when implementing a new Desktop Single Sign-on (DSSO) configuration or migrating an existing DSSO configuration:
- Agentless DSSO does not work if a single user has memberships to more than 600 security groups. If a user with more than 600 security groups implements or migrates Agentless DSSO, a 400 response appears and they are redirected to the regular sign in page.
- Windows functional level 2008 or below uses a less secure encryption RC4. Okta recommends upgrading to Windows functional level 2008 or above to make sure you are using the most secure encryption algorithm.
- When re-enabling Agentless DSSO, Identity Provider (IDP) routing rules must be manually reactivated.
- Agentless DSSO does not work when delegated authentication is disabled and Don't create Okta password is selected. To learn more about delegated authentication, see Delegated authentication.
- The default sign-in page used for automatic DSSO failover does not support HTML customization.
- An infinite redirection loop can occur when the Identity Provider (IdP) customer error page and the org URL are the same.
- When the service account user name and the Active Directory user account name don’t match, Agentless DSSO can fail. When this happens, you are returned to the default sign on page and a GSS_ERR error appears in the Syslog. The service account user name and the Active Directory user account are case sensitive and must match.
- RC4_HMAC_MD5 encryption is not supported with ADSSO and Office 365 Silent Activation. When using ADSSO or Office 365 Silent Activation, Okta recommends using AES 128-bit (AES-128) or AES 256-bit (AES-256) encryption. If the KDC_ERR_ETYPE_NOTSUPP error appears in the Windows Event Viewer when you implement AES encryption, see Kerberos Unsupported etype error.
- Microsoft Edge (Legacy) is not supported. New Chromium-based Edge is supported.
- Microsoft Teams versions 220.127.116.11 and later are supported.