Okta Agentless Desktop Single Sign-On Fails With Error "Kerberos validation failed with result=GSS_ERROR"

When using Okta Agentless Desktop Single Sign-On (ADSSO), a service account validates the Kerberos ticket. An issue with the Service Principal Name (SPN) service account's ability to validate itself against the Generic Security Service (GSS) API causes a Kerberos validation error in Okta. Verify the Active Directory (AD) service account configuration, reset the service account password, and recreate the SPN record to resolve the error.

Kerberos validation failed with result=GSS_ERROR

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Agentless Desktop Single Sign-On (ADSSO)
• Active Directory (AD)

The Service Principal Name (SPN) service account fails to validate itself against the Generic Security Service (GSS) API.

How is the Kerberos validation GSS error resolved during Agentless Desktop Single Sign-On?

Verify the Active Directory service account settings, reset the service account password, and recreate the Service Principal Name record to resolve the Kerberos validation error.

1. Set the correct time on the host machine and Domain Controllers, as clock skew causes the GSS error.
2. Use a dedicated AD service account for the SPN that meets all the requirements listed in Create a service account and configure a Service Principal Name.
3. Verify that the service account remains active and unlocked in AD, with the password status set to Never Expires.

4. Match the casing of the service account used in the SPN command exactly with the casing listed in AD.
5. Match the service account User Principal Name (UPN) prefix and sAMAccountName in AD.
   NOTE: Use the UPN and not the User log on name (pre-Windows 2000) in the configuration, as this generates a GSS error.
6. Verify that the account and the domain use Advanced Encryption Standard (AES) encryption and that the option to use Data Encryption Standard (DES) encryption remains cleared.
7. Reset the service account password in AD and enter the new password in Okta under Delegated Authentication.
8. Remove the existing SPN record by running the following command:

setspn -d HTTP/<myorg>.kerberos.<okta|oktapreview|okta-emea>.com <ServiceAccountName>

Replace <myorg> with the organization name, <okta|oktapreview|okta-emea> with the appropriate Okta URL for the instance, and <ServiceAccountName> with the name of the target service account.

9. Add the SPN by running the following command:

Replace <myorg> with the organization name, <okta|oktapreview|okta-emea> with the appropriate Okta URL for the instance, and <ServiceAccountName> with the name of the created service account. Match the casing for the service account exactly between AD and the SPN command.

10. Recreate the SPN service account, reset the credentials in Okta, and add a new SPN record to the account if the issue persists.

NOTE: Test the Agentless DSSO configuration after each step to determine if the error resolves. If the issue persists after performing all steps, an environmental issue exists that requires investigation by the Active Directory team.