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 Agentless DSSO is re-enabled, 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-in 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 22.214.171.124 and later are supported.