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. To resolve this issue, verify the Active Directory (AD) service account configuration, reset the service account password, and recreate the SPN record.

Kerberos validation failed with result=GSS_ERROR

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

The SPN service account fails to validate itself against the GSS API.

How is the "Kerberos validation failed with result=GSS_ERROR" error during ADSSO resolved?

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

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

4. Ensure that the casing of the service account used in the SPN command exactly matches the casing listed in AD.
5. Ensure the service account's User Principal Name (UPN) prefix and sAMAccountName match in AD.
   NOTE: Ensure the configuration uses the UPN and not the User log on name (pre-Windows 2000), as this can generate a GSS error.
6. Verify that the account and the domain use AES encryption and that the option to use 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. Ensure the casing for the service account matches exactly between AD and the SPN command.

10. If the issue persists, recreate the SPN service account, reset the credentials in Okta, and add a new SPN record to the account, following all recommendations listed in Create a service account and configure a Service Principal Name.

NOTE: Test the Agentless DSSO configuration after each step to determine if the error is resolved. If the issue persists after performing all steps, an environmental issue exists that requires investigation by the org's AD team.