Kerberos token is not valid error when authenticating with Windows Desktop SSO in AM (All versions) using Microsoft Edge

Last updated Jan 16, 2023

The purpose of this article is to provide assistance if you receive an "Error: kerberos token is not valid" when authenticating with the Windows Desktop SSO (WDSSO) authentication module in AM and using the Microsoft® Edge browser. WDSSO only works with Microsoft Edge when the server uses HTTP persistent connection. The user sees a "401 Unauthorized / Access denied" error.

2 readers recommend this article

Symptoms

The user sees a 401 Unauthorized / Access denied error when they attempt to access a resource protected by AM, even though they are logged in to Microsoft Windows and another authentication module exists in the authentication chain. An authentication dialog may also display prior to the 401 error.

An error similar to the following is shown in the Authentication log:

amAuthWindowsDesktopSSO:06/06/2014 08:39:06:540 AM CEST: Thread[http-bio-8080-exec-3,5,main] Init WindowsDesktopSSO. This should not happen often. amAuth:06/06/2014 08:39:06:540 AM CEST: Thread[http-bio-8080-exec-3,5,main] spi authLevel :0 amAuth:06/06/2014 08:39:06:540 AM CEST: Thread[http-bio-8080-exec-3,5,main] module configuration authLevel :0 amAuth:06/06/2014 08:39:06:540 AM CEST: Thread[http-bio-8080-exec-3,5,main] levelSet :false amAuthWindowsDesktopSSO:06/06/2014 08:39:06:540 AM CEST: Thread[http-bio-8080-exec-3,5,main] New Service Login ... amAuthWindowsDesktopSSO:06/06/2014 08:39:06:669 AM CEST: Thread[http-bio-8080-exec-3,5,main] Service login succeeded. amAuthWindowsDesktopSSO:06/06/2014 08:39:06:671 AM CEST: Thread[http-bio-8080-exec-3,5,main] SPNEGO token: 4e 54 4c 4d 53 53 50 00 01 00 00 00 97 82 08 e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 02 f0 23 00 00 00 0f amAuthWindowsDesktopSSO:06/06/2014 08:39:06:671 AM CEST: Thread[http-bio-8080-exec-3,5,main] token tag:4e amAuthWindowsDesktopSSO:06/06/2014 08:39:06:671 AM CEST: Thread[http-bio-8080-exec-3,5,main] ERROR: kerberos token is not valid.

Recent Changes

Implemented the Windows Desktop SSO authentication module.

Causes

Microsoft Edge returns a NTLM token instead of a Kerberos™ token during the SPNEGO handshake because it cannot retrieve a Kerberos service ticket for AM from Active Directory®. This is indicated by the token tag in the Authentication log, where 4e is a NTLM token; if it was a Kerberos token, the token tag would be 60.

Two common reasons for the browser failing to send a Kerberos token are:

The AM FQDN is not listed as a trusted host in the browser.
The Service Principal Name (SPN) is not set up correctly in Active Directory.

Solution

This issue can be resolved by checking the following:

Check if the Kerberos service ticket was retrieved for AM using the Klist utility from Microsoft:
- If the Kerberos service ticket does exist for the AM FQDN - check your browser settings to ensure the browser is correctly set up for Windows authentication and update where necessary. See How do I set up Kerberos authentication in AM (All versions)? for further information.
- If the Kerberos service ticket does not exist for the AM FQDN - proceed to the next step.

For example, running the klist command:$ klistProduces an output such as the following:

Server: HTTPS/am.example.com @ FORGEROCK.COM KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize Start Time: 3/17/2016 11:33:06 (local) End Time: 3/17/2016 21:31:54 (local) Renew Time: 3/24/2016 11:31:54 (local) Session Key Type: RSADSI RC4-HMAC(NT) Cache Flags: 0 Kdc Called: SVR1

Check the AM FQDN is listed as a trusted host (trusted site list) in the browser and add it if it's not listed (Security tab > Trusted Sites > Sites).
Check the SPN for the AM service in Active Directory and correct if necessary. Ensure the FQDN (which matches the SPN in AD) is used and the specified authcontext matches the auth module/chain for WDSSO. You can use the following command to check the SPN: $ setspn -l [account]replacing [account] with the name of the account created for AM. An example command looks like this: $ setspn -l amand gives an output as follows: Registered ServicePrincipalNames for CN=am,OU=employees,DC=example,DC=com: HTTPS/am.example.com

Note

If none of these resolve the issue, another problem must exist with the Kerberos protocol between the browser and Active Directory; you can attempt to track this down using utilities such as the Microsoft Network Monitor or the Microsoft Message Analyzer.

Related Training

N/A

Related Issue Tracker IDs

N/A