TroubleShooting WindowsDesktop SSO in Openam

[OpenAM] WindowsDesktopSSO problem - ERROR: Authentication failed with GSSException

When working on Openam Windows desktop SSO we had the following error " [OpenAM] WindowsDesktopSSO problem - ERROR: Authentication failed with GSSException"

As part of the Kerberos negotiation process, DNS lookups will be done to confirm that the server you're authenticating against is who it says it is.

So if your service is at openam.example.com <http://openam.example.com> then you need to make sure that:

1. It's an A record and not a CNAME and  - Looks good in our case
2. The reverse (PTR) record for that IP also resolves back to openam.example.com <http://openam.example.com> - - Looks good in our case
3. We verified the KVNO (Key version number) in key tab file to match the kvno is AD sp account
4. We also made sure that we are not using aliasing when we created the SP principal name in AD.
5. The service principal name can only exist on one account and is not linked to multiple accounts.
6. Also verified that we are using the load balancer url with full qualified name when in Key tab fil
7. The IDP is part of Our Intranet zone
8. Integrated Windows Authentication in IE is enabled
9. The server is not local to the browser.
10. The clients Kerberos systems is authenticated to a domain controller.
11. Your Active Directory principal and/or SPNs may be setup incorrectly. One gotcha: the SPN can only exist on one account; if you associate it to multiple then you'll have problem.

 

 Even after enabling all debug levels all we can see in Openam  debug.log is "*ERROR: Authentication failed with GSSException.":*

 Here is the exception snippet from debug.log

 (I did not copy the entire SPNEG token here. There are several lines of these hexadecimal numbers)

 ...

 ....

  e2 92 2e e9 a6 c3 4b 40 25 28 22 6c 75 79 41 f5

  fc 41 eb 49 03 4b 55 2a 7c fe 56 7c 80 f9 3c b4

  f1 f4 8e 47 0b 76 68 e2 c5 be e7 d9 cb b7 6c 98

  1c 06 eb 7e 7c 06 da e8 f3 f1 13 63 41 fe 22 15

  ec 71 1a 27 3e 8f f7 44 8a 9a ac 93 14 ca 2b b1

  

This tells that the KVNO (Key version number ) in your key tab file doesn’t match what’s in AD.
Verify Keytab file  kvno  by

ktab -l –k  yourkeytabfilename.keytab

 

You can change the KVNO number in key tab file to match the one in Active directory by using
Lets say if we need to set KVNO to you key tab file to 4
 

ktab -l -a HTTP/xyz@yourdomain.com ******** -n 4 -k yourkeytabfilename.keytab

where ******** is the password

How do I know what the value of KVNO in ActiveDirectory is ? 

Login to AD machine and use  "ADSIEdit.msc" on AD server and open the user account
and verify the  value of attribute "msDS-KeyVersionNumber" . If the  KVNO in keytab and AD accoun don’t match then WINDOWSDESKTOPSSO
within openam will not work. 

 Ok further we found that on Active Directory for a given user there is a flag
"Do not require Kerberos preauthentication" which we turned off.

Once we did that now we have the below error -
" Caused by: java.security.GeneralSecurityException: Checksum failed"

It so happened that our dev environment had AD on windows 2008.
Higher environments had AD on windows 2003.
The keytab that was generated using ktpass command that's on win 2003 was causing  the issue.
So our admin copied ktpass executable from win 2008 to win 2003 machine and regenerated 
the Keytab file on win 2003 machines and windows desktop sso started working.
So if you have Win 2003 there is every chance that you will have the above issues.

 

How does OpenAM work with Windows Desktop SSO ?

How does OpenAM work with Windows Desktop SSO ?

Or Kerberos Desktop SSO with OpenAM and Active Directory.

Or OpenAM and Windows Desktop SSO .

Or Using the windows desktop Single sign on with Openam.

Or OpenAM Windows Desktop SSO Authentication

On your openam IDP instance login and go to

Access control > realm (root or whichever realm you are using) >Authentication >

(Here I am showing you how to get windows desktop sso and in case it doesn’t work for some reason it will fall back to web login where  openam login screen will still allow you to login with user id password) If you just want windows desktop  sso this solution will still work just don’t use “ldapService” module in authentication chain  below.

1. You can create another module for Active Directory service as shown below and let’s call it as “DataStore”. (Here we assume you have already configured active directory)

2. Create new module instance of type windows desktop sso

Now click on your windowsDesktopSSO module instance and configure with your keytab files. (How to generate keytab files is a separate topic. Here I am assuming you have some knowledge of it already)

Now still on the same page Access control > realm (root or whichever realm you are using) >Authentication  

• Go to “Authentication Chaining” section.

• Create new authentication chaining called “WinDesktopSSOAuthChain”

• Add windowsDesktopSSO module as primary module and for fall back add “DataStore” module which will use Active directory in case desktop sso fails. (If you don’t want  exclude Datastore module here)

Also we can create another authentication chain called “ldapservice” which will use you Active Directory (ie. Use the Data store module we created above)

So now when you are at Authentication tab you will see 

• Two  module instances (DataStore, windowsDesktopSSO)

• Two Authentication Chaining  items(WinDesktopSSOAuthChain and ldapservice)

All we now need to tell openam is what “authentication chain” to use for aunthentication.

For

Organization Authentication Configuration:==> WinDesktopSSOAuthChain

Administrator Authentication Configuration:===> ldapService

By doing this we are telling openam to use “ldapservice”  for Admin authentication and “winDesktopSSOAuth” chain for user’s verification.

Some more links that may be helpful

http://troubleshootingrange.blogspot.com/2012/08/kerberos-desktop-sso-with-openam-and.html

https://wikis.forgerock.org/confluence/display/openam/How+does+OpenAM+work+with+Windows+Desktop+SSO

Once the above settings are done we still need to tweak the browser settings so that browser can send kerberos token.

Configuring the browser for SSO with OpenAM

or configuring Internet explorer for sso with OpenAm

or configuring Firefox for sso with OpenAm

or configuring Chrome for sso with OpenAm

Let’s assume the OpenAM idp url that you are using is http://idp.abc.com.

The OpenAM IDP returns a “401” authorization error to the browser. Each browser responds differently to this 401. What we want is for the browser to attempt authorization with the Kerberos data.

Internet Explorer

By default IE will automatically send your logged-on Windows credentials only to Intranet web sites. The OpenAM IDP can be manually added to the trusted list of Intranet sites until we can engage systems engineering to set it up as a web site that can be automatically recognized as Intranet (and therefore trusted).

1.       Check the User Authentication settings:  Click Tools – Internet Options – Security – Local Intranet. Click the “Custom Level” button, and scroll to the User Authentication section. 

1.       Add the IDP to the list of trusted intranet sites. Click Tools – Options – Local Intranet. Click the “Sites” button, and then click the “Advanced” button.

s

You may also do this via a manual registry update as shown below:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\abc.com\idp]

"http"=dword:00000001

   Confirm Windows Integrated Security. Click Tools – Options – Advanced. Scroll down to the security section and ensure “Enable Integrated Windows Authentication” is checked. 

d  You are done with IE settings.

Configuring Chrome for sso with OpenAm

Chrome uses the same internet settings as IE, so once IE works, Chrome works too. To confirm this, click Settings, then type network into the search box. Click the “Change Proxy Settings” button. You should see the same Internet Explorer dialog.

Configuring FireFox for sso with OpenAm

When Firefox gets the 401, it can be configured to fall back to a negotiated authentication protocol that achieves SSO. Firefox must be configured to trust the OpenAM IDP for this negotiation to be successful. Launch Firefox, and in the address bar, type about:config

Click the “I’ll be careful” button. In the Search box, type network.negotiate to filter the configurations to only the network negotiation options. Change two values. Both values will be the same. Use the appropriate IDP for the environment you want to test in.

(1)    network.negotiate-auth.delegation-uris

(2)    network.negotiate-auth.trusted-uris

Note: If you have more than one URL that you need to add you can add a COMA SEPARATED LIST in firefox. (For this example I will consider another idp say idp.xyz.com)

In order to make Firefox send the Kerberos ticket you can also use about:config to set 

network.automatic-ntlm-auth.trusted-uris

With this configuration your windows desktop SSO setup should work.

If you liked this article or have suggestion or correction please post your valuable comments.