Active Directory Desktop Single Sign-On known issues

The following are known issues when implementing a new Desktop Single Sign-On (DSSO) configuration or migrating an existing DSSO configuration:

Agentless DSSO doesn't work if a single user is a member of more than 600 security groups or if the Kerberos token is too large for Okta to consume. If a user with a large Kerberos packet implements or migrates agentless DSSO, a 400 response appears and they're 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're using the most secure encryption algorithm.
When agentless DSSO is re-enabled, Identity Provider (IdP) routing rules must be manually reactivated.
Agentless DSSO doesn't 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 doesn't 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 username and the Active Directory user account name don't match, agentless DSSO can fail. When this happens, you're returned to the default sign-in page and a GSS_ERR error appears in the System Log. The service account username and the Active Directory user account are case sensitive and must match.
RC4_HMAC_MD5 encryption isn't 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) isn't supported. The new Chromium-based Edge is supported.
Microsoft Teams versions 4.0.8.0 and later are supported.