Configuring and troubleshooting WDSSO in AM/OpenAM

This book provides information on configuring and troubleshooting Windows Desktop SSO (WDSSO) in AM/OpenAM. Known issues are included along with solutions.


Configuring WDSSO


How do I set up Windows Desktop SSO in AM/OpenAM (All versions)?

The purpose of this article is to provide information that will help guide you through understanding and configuring the Windows Desktop SSO (WDSSO) authentication module in AM/OpenAM. This functionality uses the Kerberos™ capabilities of Active Directory®.

Background information

The WDSSO authentication module allows users logged in to Microsoft® Windows® to access a resource protected by AM/OpenAM without further authentication. Prior to setting up the WDSSO module, you should ensure Kerberos is configured correctly; in particular, you should ensure the krb5.conf file has been set up (see krb5.conf for details) and that your firewall allows necessary communications (see Kerberos and Firewalls for the required ports). 

Some key things to be aware of when configuring the WDSSO module are:

  • If you are using Oracle® JDK 7, you must ensure both TCP port 88 and UDP port 88 are open in your firewall to allow communication between AM/OpenAM and Kerberos.
  • If you are using the WDSSO authentication module as part of an authentication chain and Windows Desktop SSO fails, you may no longer be able to POST data to non-NTLM-authenticated web sites. For information on a possible workaround, see KB251404: You cannot post data to a non-NTLM-authenticated Web site.
  • The userPrincipalName must be unique for all users.
  • The key version number (kvno) in the keytab file must equal the value of the msDS-KeyVersionNumber attribute for the AM/OpenAM principal in Active Directory +1. This is because Active Directory increases the value of kvno by 1 when you use the keypass command to create the keytab file and these values must match.
  • You must restart the web application container in which AM/OpenAM runs after making configuration changes to the WDSSO authentication module per known issue: OPENAM-5107 (Configuration changes of WindowsDesktopSSO auth module require restart)
Note

You can query the value of msDS-KeyVersionNumber in Active Directory using the ldapsearch command.

Setting up WDSSO

The following steps are required to set up WDSSO; below these steps is a video demonstration that covers the same process:

  1. Configure your browser for Windows authentication. The settings needed are specific to the browser you are using as detailed in the Browser Settings section below.
  2. Configure the WDSSO authentication module in the console:
    • AM / OpenAM 13.x console: navigate to: Realms > [Realm Name] > Authentication > Modules > [Module Name].
    • Pre-OpenAM 13 console: navigate to: Access Control > [Realm Name] > Authentication > Module Instances > [Module Name].
    See Authentication and Single Sign-On Guide › Implementing Authentication › Windows Desktop SSO Authentication Module for further information on these options.
  3. Restart the web application container in which AM/OpenAM runs to apply these configuration changes.
  4. Set the login URL for the resource you are protecting so that it includes your WDSSO module. For example:
    • AM 5 and later:
      http://host1.example.com:8080/openam/XUI/?realm=/myrealm#login&module=WDSSO
    • Pre-AM 5:
      http://host1.example.com:8080/openam/XUI/#login&realm=/myrealm&module=WDSSO
    This means a user won't need to authenticate again when accessing this URL providing they are already logged in to Microsoft Windows.

Video demonstration 

Note

This video demonstration uses OpenAM 10.0.0; although the appearance has changed between OpenAM 10.x and later versions, the principles and processes are still applicable. In AM / OpenAM 13.x, the options under Access Control are now under Realms.

Browser Settings

The configuration required varies according to the browser you are using, as summarized below:

Internet Explorer® or Microsoft Edge

If you use Internet Explorer or Microsoft Edge, there are three settings you need to check and configure in Internet Options:

  • Ensure the Enable Integrated Windows Authentication option is selected. This option is found on the Advanced tab under Security.
  • Ensure the Automatic logon only in Intranet zone option is selected. This option can be accessed from the Security tab. Select Local Intranet and then click the Custom Level button. This option can then be found under User Authentication > Logon.
  • Add the AM/OpenAM FQDN to the trusted Intranet site list. This list can be accessed from the Security tab. Select Local Intranet and then click the Sites button, followed by the Advanced button.

You must restart Internet Explorer or Microsoft Edge for these settings to take effect.

Note

WDSSO only works with Internet Explorer and Microsoft Edge when the server uses HTTP persistent connection.

Chrome™

Chrome inherits its settings from Internet Explorer or Microsoft Edge when you are using Microsoft Windows so will work providing you have configured Internet Explorer or Microsoft Edgeas detailed above.

Firefox®

If you use Firefox, you can use a plugin called Integrated Authentication. You should ensure the AM/OpenAM FQDN is added to the Integrated Authentication Sites list (Tools > Integrated Authentication Sites) if you're using the Integrated Authentication plugin.

Alternatively, you can change the equivalent Firefox setting (network.negotiate-auth.trusted-uris) via about:config.

Safari®

Safari has built-in support for Kerberos SSO and no additional configuration is required.

See Also

OpenAM Windows Desktop SSO deep dive – part 1

How do I set up the WDSSO authentication module in AM/OpenAM (All versions) in a load balanced environment?

How do I troubleshoot WDSSO and Kerberos issues in AM/OpenAM (All versions)?

How do I enable debug logging for troubleshooting WDSSO and Kerberos issues in AM/OpenAM (All versions)?

Configuring and troubleshooting WDSSO in AM/OpenAM

Kerberos token is not valid error when authenticating with Windows Desktop SSO in AM/OpenAM (All versions) using Internet Explorer

Authenticating with Windows Desktop SSO in AM/OpenAM (All versions) does not proceed when using non-Internet Explorer browser

Authentication and Single Sign-On Guide › Implementing Authentication › Windows Desktop SSO Authentication Module

Related Training

N/A

Related Issue Tracker IDs

OPENAM-3400 (Chain authentication not working when using Internet Explorer 9, 10, 11)

OPENAM-3826 (WindowsDesktopSSO auth-module does not log details about GSSException)

OPENAM-5107 (Configuration changes of WindowsDesktopSSO auth module require restart)

OPENAM-6180 (Uncheck “Enable Integrated Windows Authentication” statement in docs)


How do I set up the WDSSO authentication module in AM/OpenAM (All versions) in a load balanced environment?

The purpose of this article is to provide information on setting up the Windows Desktop SSO (WDSSO) authentication module in AM/OpenAM in a load balanced environment, where multiple AM/OpenAM instances are running in a site. This article assumes you already have a working WDSSO authentication module and want to scale your WDSSO solution.

Overview

Typically, AM/OpenAM is deployed in a site environment with multiple AM/OpenAM instances running behind a load balancer, where:

  • Authentication modules share the same configuration across all AM/OpenAM instances behind the load balancer; the configuration is not server specific. In terms of the WDSSO authentication module, this means the keytab file is also shared.
  • Multiple AM/OpenAM instances in a site act as one under the configured load balancer's hostname.

When you configure the WDSSO authentication module in this environment, you need to ensure the service provider name is set to the load balancer host/domain rather than to a single AM/OpenAM instance and that this service provider name is used to create the keytab file. The steps you should follow to complete this setup are detailed in the following section.

Setting up the WDSSO authentication module in a load balanced environment

The following example details are used in this process:

  • Load balancer / site FQDN - http://lb.openam.com:8080/openam
  • Service principal name: HTTP/lb.openam.com@FORGEROCK.COM

You can configure the WDSSO authentication module in a load balanced environment as follows:

  1. Set up your separate AM/OpenAM instances in a site with a load balancer:
  2. Create an Active Directory® account to use as your Kerberos™ principal (user), for example: openamKerberos. See OpenAM Windows Desktop SSO deep dive – part 1 (Create an account in active directory for your Kerberos principal section) for further information on this step if required.
  3. Formulate a Service Principal in Active Directory that uses the load balancer URL, this is being formulated to use in the next step when creating the keytab file. You should specify the Kerberos™ principal for authentication in the following format, where DC-DOMAIN-NAME is in upper case and is typically the Kerberos realm name (the FQDN of the Active Directory domain):
    HTTP/lbhost.domain@DC-DOMAIN-NAME
    For example:
    HTTP/lb.openam.com@FORGEROCK.COM
  4. Create the keytab file for the WDSSO authentication module using a ktpass command such as:
    $ ktpass -out lb.HTTP.keytab -princ HTTP/lb.example.com@FORGEROCK.COM -pass +rndPass -maxPass 256 -mapuser openamKerberos -crypto All -ptype KRB5_NT_PRINCIPAL -kvno n
    
    Where:
    • -princ is the name of the service principal you formulated in step 3.
    • -pass is set to use a very robust password with the +rndpass and -maxpass options setting a random 256 character password on the account, which is then used to derive the key in the Kerberos service principal.
    • -mapuser is the name of the user you created in step 2. 
    • -crypto is set to All to allow all supported crypto types to be used. If you do specify a specific encryption type and use AES256-SHA1, you must have the Oracle® Java JCE unlimited strength jars installed in the $JAVA_HOME/jre/lib/security/ directory and your Microsoft® Windows® machine must also support this encryption.
    • -kvno - the key version number (kvno) in the keytab file must equal the value of the msDS-KeyVersionNumber attribute for the AM/OpenAM principal in Active Directory +1. This is because Active Directory increases the value of kvno by 1 when you use the keypass command to create the keytab file and these values must match.
    This ktpass command gives the following output:
    Targeting domain controller: WIN2012LAB.forgerock.com
    Successfully mapped HTTP/lb.example.com to openamKerberos.
    Password successfully set!
    Key created.
    Output keytab to lb.HTTP.keytab:
    Keytab version: 0x502
    keysize 84 HTTP/lb.example.com@FORGEROCK.com ptype 1 (KRB5_NT_PRINCIPAL) vno 0 e
    type 0x12 (AES256-SHA1) keylength 32 (0xc2072ad3157629437adbc7c2fa637fa4f8b6569e
    12c446d5970cd52cf35f6b71)
    
    See OpenAM Windows Desktop SSO deep dive – part 1 (Creating a KeyTab file) for further information on this step if required.
  5. Copy the generated keytab file to all AM/OpenAM instances in your site. You must place this keytab file in the exact same location on all servers as the keytab location can only be set in one place and this location is then shared across all instances (for example: /tmp/openam.HTTP.keytab).
  6. Update the WDSSO authentication module on one AM/OpenAM instance to use the service principal name you formulated in step 3 (for example: HTTP/lb.openam.com@FORGEROCK.COM). You can do this in the console as follows:
    • AM / OpenAM 13.x console: navigate to Realms > [Realm Name] > Authentication > Modules > [Module Name] > Service Principal and enter the new value.
    • Pre-OpenAM 13 console: navigate to Access Control > [Realm Name] > Authentication >  Module Instances > [Module Name] > Service Principal and enter the new value.
  7. Update the WDSSO authentication module on one AM/OpenAM instance to set the location of the keytab file to match where you placed it in step 5 (for example: /tmp/openam.HTTP.keytab). You can do this in the console as follows:
    • AM / OpenAM 13.x console: navigate to Realms > [Realm Name] > Authentication > Modules > [Module Name] > Keytab File Name and enter the new value.
    • Pre-OpenAM 13 console: navigate to Access Control > [Realm Name] > Authentication >  Module Instances > [Module Name] > Keytab File Name and enter the new value.
  8. Restart the web application container in which AM/OpenAM runs to apply these changes.
  9. Test the WDSSO authentication module going through the load balancer; that is, check that the protected sites and policy agents are configured to use the load balancer FQDN instead of an individual OpenAM server. For example, you can authenticate with the WDSSO authentication module via:
    http://lb.openam.com:8080/openam

See Also

How do I set up Windows Desktop SSO in AM/OpenAM (All versions)?

OpenAM Windows Desktop SSO deep dive – part 1

How do I specify multiple Kerberos servers in AM/OpenAM (All versions) for failover purposes?

How do I redirect users to a different login module if Kerberos/WDSSO authentication fails with a 401 error in OpenAM 11.x and 12.x using the Classic UI?

Configuring and troubleshooting WDSSO in AM/OpenAM

Installation Guide › Installing and Starting Servers › Installing Multiple Servers

Authentication and Single Sign-On Guide › Implementing Authentication › Windows Desktop SSO Authentication Module

Related Training

N/A

Related Issue Tracker IDs

N/A


How do I specify multiple Kerberos servers in AM/OpenAM (All versions) for failover purposes?

The purpose of this article is to provide information on specifying multiple Kerberos™ Domain Controllers (DCs) in AM/OpenAM for failover purposes when configuring the Windows Desktop SSO (WDSSO) authentication module.

Specifying multiple Kerberos DCs

If you have multiple Kerberos DCs configured for failover purposes, you can specify them when configuring the WDSSO authentication module at the global or realm level.

Note

If you have set up the WDSSO module with multiple Kerberos DCs and have used a keytab file from one of the trusted DCs, you should be aware that all users from the trusted domains can authenticate through the WDSSO module. Configuring and managing Active Directory Domain Trusts is outside the scope of this article and ForgeRock Support.

Global level

You can configure multiple Kerberos DCs at the global level using either the console or ssoadm:

  • AM / OpenAM 13.5 console: navigate to: Configure > Authentication > Windows Desktop SSO > Kerberos Server Name and specify the server names using a colon as a separator, for example:
    primary_server:secondary_server:tertiary_server
  • Pre-OpenAM 13.5 console: navigate to: Configuration > Authentication > Windows Desktop SSO > Kerberos Server Name and specify the server names using a colon as a separator, for example:
    primary_server:secondary_server:tertiary_server
  • ssoadm: enter the following command:
    $ ./ssoadm set-attr-defs -s iPlanetAMAuthWindowsDesktopSSOService -t organization -u [adminID] -f [passwordfile] -a iplanet-am-auth-windowsdesktopsso-kdc="[servers]"
    
    replacing [adminID], [passwordfile] and [servers] with appropriate values, where [servers] must be contained within " " and each server name is separated with a colon.

An example ssoadm command to add two Kerberos DCs at the global level looks like this:

$ ./ssoadm set-attr-defs -s iPlanetAMAuthWindowsDesktopSSOService -t organization -u amadmin -f pwd.txt -a iplanet-am-auth-windowsdesktopsso-kdc="kdc.example.com:kdc2.example.com"

Realm level

You can configure multiple Kerberos DCs at the realm level using either the console or ssoadm:

  • AM / OpenAM 13.x console: navigate to: Realms > [Realm Name] > Authentication > Modules > [WDSSO Module] > Kerberos Server Name and specify the server names using a colon as a separator, for example:
    primary_server:secondary_server:tertiary_server
  • Pre-OpenAM 13 console: navigate to: Access Control > [Realm Name] > Authentication > Module Instances > [WDSSO Module] > Kerberos Server Name and specify the server names using a colon as a separator.
  • ssoadm: enter the following command:
    $ ./ssoadm set-realm-svc-attrs -s iPlanetAMAuthWindowsDesktopSSOService -e [realmname] -u [adminID] -f [passwordfile] -a iplanet-am-auth-windowsdesktopsso-kdc="[servers]"
    
    replacing [realmname], [adminID], [passwordfile] and [servers] with appropriate values, where [servers] must be contained within " " and each server name is separated with a colon.

An example ssoadm command to add two Kerberos DCs at the realm level looks like this:

$ ./ssoadm set-realm-svc-attrs -s iPlanetAMAuthWindowsDesktopSSOService -e employees -u amadmin -f pwd.txt -a iplanet-am-auth-windowsdesktopsso-kdc="kdc.example.com:kdc2.example.com"

See Also

How do I set up Windows Desktop SSO in AM/OpenAM (All versions)?

OpenAM Windows Desktop SSO deep dive – part 1

Configuring and troubleshooting WDSSO in AM/OpenAM

Authentication and Single Sign-On Guide › Implementing Authentication › Windows Desktop SSO Authentication Module

Related Training

N/A

Related Issue Tracker IDs

N/A


How do I redirect users to a different login module if Kerberos/WDSSO authentication fails with a 401 error in OpenAM 11.x and 12.x using the Classic UI?

The purpose of this article is to provide information on redirecting users who see a "HTTP 401" error when attempting to authenticate to Kerberos / Windows Desktop SSO (WDSSO). This can be achieved with a custom 401.jsp that will redirect users to failover to a different authentication type when this error occurs.

Redirecting users to a different login module

Note

Only users who have already authenticated with a Kerberos KDC can authenticate to WDSSO without entering their credentials again. If a user attempts to authenticate without a valid Kerberos token, the attempt will fail and the user will see a standard 401 Unauthorized / Access denied error page instead of failing over to the next authentication module in the chain. 

You can workaround this by implementing a custom application or container level 401 error page, which redirects the user (using the refresh meta tag within the HTML head tag) to the OpenAM login page to allow authentication to continue using a different authentication module.

The following example refers to Apache Tomcat™:

  1. Create a custom 401 page (for example 401.jsp) in the /path/to/tomcat/webapps directory where OpenAM is deployed. You can use the following code as the basis for a simple redirect in your custom 401 jsp page:
    <html>
      <head>
        <meta HTTP-EQUIV="refresh" content="0;url=http://host1.example.com:8080/openam/UI/Login?module=AuthModule">
      </head>
      <body>Authentication is required. You will automatically be redirected to the Login page...</body>
    </html>
    
    If you have a complex authentication chain, you may want the refresh URL to send users to a new authentication chain that does not include the WDSSO module. Therefore you'd have one authentication chain that includes the WDSSO module and a second chain that is a copy of the first chain minus the WDSSO module. You could then set the refresh URL to send them to the second chain, for example:
    <html>
      <head>
        <meta HTTP-EQUIV="refresh" content="0;url=http://host1.example.com:8080/openam/UI/Login?service=AuthChain2">
      </head>
      <body>Authentication is required. You will automatically be redirected to the Login page...</body>
    </html>
    
    For a more dynamic custom 401 error page, you can refer to this third-party website for an example: Chaining kerberos with OpenAM – part 3.
  2. Update the web.xml file (located in the /path/to/tomcat/webapps/openam/WEB-INF directory where OpenAM is deployed) to reference your custom 401 page. For example, add the following code to the bottom of the web.xml file:
    <error-page>
        <error-code>401</error-code>
        <location>/401.jsp</location>
    </error-page>
    </web-app>
    
  3. Restart Tomcat to apply these changes. When a 401 error is encountered now, the browser will automatically redirect the user to your custom 401 page.

See Also

How do I set up Windows Desktop SSO in AM/OpenAM (All versions)?

OpenAM Windows Desktop SSO deep dive – part 1

Authenticating with Windows Desktop SSO in AM/OpenAM (All versions) does not proceed when using non-Internet Explorer browser

Configuring and troubleshooting WDSSO in AM/OpenAM

Chaining kerberos with OpenAM – part 3

Related Training

N/A

Related Issue Tracker IDs

OPENAM-8422 (OpenAM 12 WindowsDesktopSSO module does not fallback to the next module in the chain)


How do I get the WDSSO authentication module to work in AM/OpenAM (All versions) with the IBM Kerberos implementation?

The purpose of this article is to provide information on getting the Windows Desktop SSO (WDSSO) authentication module to work in AM/OpenAM using the IBM® Kerberos™ implementation. This applies when you have deployed AM/OpenAM on IBM WebSphere® and are using the IBM JVM.

Enabling the IBM Kerberos implementation

The WDSSO authentication module uses the Oracle® Kerberos implementation by default. If you are using the IBM JVM, you must enable the IBM Kerberos implementation to allow the WDSSO authentication module to function correctly.

Note

When enabling the IBM Kerberos implementation via the console or ssoadm, you will get a warning about unidentified property or invalid property; you can ignore this warning as the property is still added successfully.

You can enable the IBM Kerberos implementation using either the console or ssoadm:

  • AM / OpenAM 13.5 console: navigate to: Configure > Server Defaults > Advanced and add the following property and value:
    com.sun.identity.authentication.module.WindowsDesktopSSO.Krb5LoginModule = com.ibm.security.auth.module.Krb5LoginModule
    Once you have entered the property and value, click + to add followed by Save Changes.
  • Pre-OpenAM 13.5 console: navigate to: Configuration > Servers and Sites > Default Server Settings > Advanced and add the following property and value:
    com.sun.identity.authentication.module.WindowsDesktopSSO.Krb5LoginModule = com.ibm.security.auth.module.Krb5LoginModule
  • ssoadm: enter the following command:
    $ ./ssoadm update-server-cfg -s default -u [adminID] -f [passwordfile] -a com.sun.identity.authentication.module.WindowsDesktopSSO.Krb5LoginModule=com.ibm.security.auth.module.Krb5LoginModule
    replacing [adminID] and [passwordfile] with appropriate values. 

Adding this property to the Server Defaults ensures it will be inherited by any AM/OpenAM server sharing the same configuration store.

Note

You must restart the web application container in which AM/OpenAM runs to apply these configuration changes. 

See Also

How do I set up Windows Desktop SSO in AM/OpenAM (All versions)?

OpenAM Windows Desktop SSO deep dive – part 1

How do I set up the WDSSO authentication module in AM/OpenAM (All versions) in a load balanced environment?

How do I specify multiple Kerberos servers in AM/OpenAM (All versions) for failover purposes?

How do I redirect users to a different login module if Kerberos/WDSSO authentication fails with a 401 error in OpenAM 11.x and 12.x using the Classic UI?

Configuring and troubleshooting WDSSO in AM/OpenAM

Authentication and Single Sign-On Guide › Implementing Authentication › Windows Desktop SSO Authentication Module

Related Training

N/A

Related Issue Tracker IDs

N/A


How do I use the WDSSO module to authenticate via REST in AM/OpenAM (All versions)?

The purpose of this article is to provide information on using the Windows Desktop Single-Sign On (WDSSO) module to authenticate via the REST API in AM/OpenAM.

Background information

The WDSSO authentication module uses Kerberos authentication. The user presents a Kerberos token to AM/OpenAM through the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) protocol. 

In order to authenticate via the REST API, the REST client needs to have access to the Kerberos side of things. For example, you can use curl because it has support for SPNEGO and Kerberos (as of version 7.10.6), but Postman currently does not. 

You can check that your version of curl does support SPNEGO and Kerberos using the -V option as follows:

$ curl -V

curl 7.54.0 (x86_64-apple-darwin16.0) libcurl/7.54.0 SecureTransport zlib/1.2.8
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets

Using the WDSSO module to authenticate via REST

To authenticate using the WDSSO module, you need to include the following options:

  • -u  - this is a fake user option needed to activate the authentication code.
  • --negotiate - this enables the Negotiate (SPNEGO) authentication.

For example, you can authenticate with a command such as the following:

$ curl "http://host1.example.com:8080/openam/json/authenticate?service=winsso&authIndexType=service&authIndexValue=winsso" -X POST -u : --negotiate 

Example response:

{ "tokenId": "AQIC5wM2LY4SfcxsuvGEjcsppDSFR8H8DYBSouTtz3m64PI.*AAJTSQACMDIAAlNLABQtNTQwMTU3NzgxODI0NzE3OTIwNAEwNDU2NjE0*", "successUrl": "/openam/console"}

See Also

How do I troubleshoot WDSSO and Kerberos issues in AM/OpenAM (All versions)?

FAQ: REST API in AM/OpenAM

Using the REST API in AM/OpenAM

Configuring and troubleshooting WDSSO in AM/OpenAM

Postman: New feature: Support API endpoints protected by kerberos

Related Training

N/A

Related Issue Tracker IDs

N/A


Troubleshooting WDSSO


How do I troubleshoot WDSSO and Kerberos issues in AM/OpenAM (All versions)?

The purpose of this article is to provide information on troubleshooting Windows Desktop SSO (WDSSO) and Kerberos™ issues in AM/OpenAM. You can use the collected data to troubleshoot issues yourself or include it when you raise a ticket to enable us to help you more effectively.

Troubleshooting WDSSO and Kerberos issues

If you are experiencing issues with your WDSSO module and/or Kerberos setup in AM/OpenAM, you can use the following troubleshooting steps to debug your issue:

  1. Generate a full set of message level debug logs and capture the HTTP trace while reproducing the issue. Required debug logs include the AM/OpenAM ones and the debug logs for the How do I enable debug logging for troubleshooting WDSSO and Kerberos issues in AM/OpenAM (All versions)? of the JVM (this module is called by AM/OpenAM for WDSSO purposes).
  2. Verify a Kerberos token has been sent (rather than a NTLM token).
  3. Enable Kerberos event logging on the Microsoft® Windows® / Active Directory® server as detailed in: Microsoft - How to enable Kerberos event logging.
  4. Export the configuration for your WDSSO module - it is essential to check if a configuration issue is contributing to your issues.
  5. Check your keytab file details are correct.
  6. Check your browser settings are correct.
  7. Check other configuration details.
  8. Check connection to Kerberos Key Distribution Center (KDC).

Additionally, information is included about the expected access flows for WDSSO authentication (with a policy agent protected resource) and a federated environment. These flows can help you track down where the breakdown in WDSSO is occurring, which can help focus your troubleshooting efforts. 

If you need to raise a ticket to troubleshoot an issue, you should include relevant information to help us investigate your issues more effectively. Refer to Best practice for raising a ticket with ForgeRock Support for further information on creating a ticket.

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.

Understanding access flows for WDSSO

Windows Desktop SSO Authentication​

The expected access flow for WDSSO single sign-on (SSO) with a policy agent protected resource is as follows: 

  1. The user attempts to access the protected resource with a SPNEGO-enabled browser.
  2. The policy agent intercepts the request and redirects to the AM/OpenAM server.
  3. The AM/OpenAM server returns a HTTP 401 Authenticate/Negotiate response.
  4. The browser sends the following to the Active Directory server:
    • a request for the Ticket Granting Ticket (TGT) if a TGT does not already exist. 
    • a request (accompanied by the TGT) for a Kerberos Service Ticket.
  5. The Kerberos Domain Controller sends a Service Ticket to the browser.
  6. The browser sends HTTP, POST, GET, Web-Service and SPNEGO tokens to the AM/OpenAM server.
  7. The WDSSO module validates the SPNEGO token and retrieves the user profile from the user data store.
  8. The AM/OpenAM server creates an SSO Token.
  9. The AM/OpenAM server returns a HTTP 200 OK response and the SSO Token to the browser.
  10. The browser sends the SSO token to the policy agent and the policy agent grants access to the protected resource.

Federated environment

The expected access flow for WDSSO in a federated environment is as follows: 

  1. The user attempts to access the protected resource at the service provider (SP).
  2. The SP sends the authorization request to the AM/OpenAM identity provider (IdP).
  3. The AM/OpenAM IdP returns a HTTP 401 Authenticate/Negotiate response.
  4. The browser sends the following to the Active Directory server:
    • a request for the Ticket Granting Ticket (TGT) if a TGT does not already exist. 
    • a request (accompanied by the TGT) for a Kerberos Service Ticket.
  5. The Kerberos Domain Controller sends a Service Ticket to the browser.
  6. The browser sends HTTP, POST, GET, Web-Service and SPNEGO tokens to the AM/OpenAM IdP.
  7. The WDSSO module validates the SPNEGO token and retrieves the user profile from the user data store.
  8. The AM/OpenAM IdP creates an SSO Token.
  9. The AM/OpenAM IdP returns a HTTP 200 OK response and the SSO Token to the browser.
  10. The AM/OpenAM IdP sends the authorization response of Success to the SP and the SP grants access.

Generating debug logs and capturing the HTTP trace

It is important to ensure your debug logs and HTTP trace have corresponding date and timestamps. You should follow this process:

  1. Enable message level debugging as described in How do I enable Message level debugging in AM/OpenAM (All versions) debug files? 
  2. Clear the AM/OpenAM debug logs as described in How do I clear debug logs in AM/OpenAM (All versions)?
  3. Enable debug logging for the Krb5Login module of the JVM; this adds additional logging to the container's standard logs. You can enable debug logging as detailed in How do I enable debug logging for troubleshooting WDSSO and Kerberos issues in AM/OpenAM (All versions)?
  4. Start a HTTP trace in your browser. There are free third-party tools you can use, for example, in Firefox®, you can use Live HTTP Headers.
  5. Reproduce the issue using your browser.
  6. Stop the HTTP trace.

Verifying a Kerberos token has been sent

Microsoft Windows will first try Kerberos; unless all the requirements are met, it will fallback to NTLM authentication. 

You can use the output from the HTTP trace captured in the above section to check that a Kerberos token has been sent as follows:

  1. Examine the output from the HTTP trace tool. You are looking for the Authorization: Negotiate section:
    • If this begins YII, then Kerberos is being used, for example:
      Authorization: Negotiate YIIVDAYGKwYBE...
    • If this begins TlR, then Kerberos is not being used,  for example:
      Authorization: Negotiate TlRMTVNTUA...

You can also check the Authentication log to see if it has fallen back to NTLM authentication. If it has, you will see the following error:

ERROR: kerberos token is not valid 

See Kerberos token is not valid error when authenticating with Windows Desktop SSO in AM/OpenAM (All versions) using Internet Explorer for further information on this error.

Exporting the WDSSO module configuration

You can export this configuration using the following ssoadm command:

$ ./ssoadm get-auth-instance -e [realmname] -m [modulename] -u [adminID] -f [passwordfile]

Replacing [realmname], [modulename], [adminID] and [passwordfile] with appropriate values.

For example:

$ ./ssoadm get-auth-instance -e / -m wdsso -u amadmin -f pwd.txt

Example response:

Authentication Instance profile:
iplanet-am-auth-windowsdesktopsso-returnRealm=false
iplanet-am-auth-windowsdesktopsso-auth-level=0
iplanet-am-auth-windowsdesktopsso-kerberos-realm=forgerock.com
iplanet-am-auth-windowsdesktopsso-lookupUserInRealm=false
iplanet-am-auth-windowsdesktopsso-kdc=host1.example.com
iplanet-am-auth-windowsdesktopsso-principal-name=HTTP/openam.forgerock.com@forgerock.com
iplanet-am-auth-windowsdesktopsso-keytab-file=/tmp/keytab

Checking keytab file details

First you should check the keytab file exists in the location detailed in the WDSSO module export; if it does not, you should update the WDSSO module details. You should also ensure that the user that AM/OpenAM is running as has read access permissions to the keytab file.

You can then output details for your keytab file using either the Kerbtray or Klist utilities from Microsoft (depending on Microsoft Windows version). For example:

$ klist

An example output from the Klist utility is:

Server: HTTP/host1.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

You can then check the following and resolve as applicable:

  • Check the Kerberos service ticket was retrieved for AM/OpenAM:
    • If the Kerberos service ticket does exist for the AM/OpenAM FQDN - check your browser settings to ensure the browser is correctly set up for Windows authentication and update where necessary. See the Checking your browser settings are correct section below for further information.
    • If the Kerberos service ticket does not exist for the AM/OpenAM FQDN - continue troubleshooting.
  • Check you have used an appropriate encryption type (KerbTicket Encryption Type in example Klist output) when generating the keytab file and that you have updated the user account properties in Active Directory to match. The corresponding encryption type should be selected in the user account properties. If you want to use a 256-bit AES encryption type, you must have the Oracle® Java JCE unlimited strength jars installed in the $JAVA_HOME/jre/lib/security/ directory and your Microsoft Windows machine must also support this encryption. 
  • Check the service principal defined in AM/OpenAM (iplanet-am-auth-windowsdesktopsso-principal-name in WDSSO module export) matches the one in the keytab file (Server in Klist output). This can be determined by looking at the Kerberos ticket with klist to see what Principal was actually authenticated in Kerberos.
  • The key version number (kvno) in the keytab file must equal the value of the msDS-KeyVersionNumber attribute for the AM/OpenAM principal in Active Directory +1. This is because Active Directory increases the value of kvno by 1 when you use the keypass command to create the keytab file and these values must match.
Note

You can query the value of msDS-KeyVersionNumber in Active Directory using the ldapsearch command.

Checking your browser settings are correct

You should check the following specific browser settings: 

  • Check the AM/OpenAM FQDN is listed as a trusted host in the browser and add it if it's not listed. You can check as follows according to which browser you are using:
    • Internet Explorer® and Microsoft Edge - the AM/OpenAM FQDN should be added to the trusted Intranet site list (Security tab > Local Intranet > Sites > Advanced).
    • Chrome™ - since Chrome uses the Internet Explorer or Microsoft Edgesettings, you should check the AM/OpenAM FQDN is added to the trusted Intranet site list per the previous bullet.
    • Firefox - the AM/OpenAM FQDN should be added to the Integrated Authentication Sites list (Tools > Integrated Authentication Sites) if you're using the Integrated Authentication plugin. The equivalent Firefox setting is network.negotiate-auth.trusted-uris (accessed via about:config).
  • If you use Internet Explorer or Microsoft Edge, there are two more settings you need to check and configure in Internet Options:
    • Ensure the Enable Integrated Windows Authentication option is selected. This option is found on the Advanced tab under Security.
    • Ensure the Automatic logon only in Intranet zone option is selected. This option can be accessed from the Security tab. Select Local Intranet and then click the Custom Level button. This option can then be found under User Authentication > Logon.
    You must restart Internet Explorer or Microsoft Edge for these settings to take effect.
Note

WDSSO only works with Internet Explorer and Microsoft Edge when the server uses HTTP persistent connection.

  • If you use Chrome, Chrome inherits its settings from Internet Explorer or Microsoft Edge when you are using Microsoft Windows so will work providing you have configured Internet Explorer or Microsoft Edge as detailed above.
  • If you use Firefox, you can use a plugin called Integrated Authentication. You should ensure the AM/OpenAM FQDN is added to the Integrated Authentication Sites list (Tools > Integrated Authentication Sites) if you're using the Integrated Authentication plugin. Alternatively, you can change the equivalent Firefox setting (network.negotiate-auth.trusted-uris) via about:config.
  • If you use Safari®, Safari has built-in support for Kerberos SSO and no additional configuration is required.

Checking other configuration details

You should also check the following configuration details: 

  • The krb5.conf file has been set up; this file contains the Kerberos configuration information (see krb5.conf for details).
  • An Active Directory datastore is configured for the realm you are using and you can see the Active Directory users on the Identities page (previously the Subjects tab) in that realm. 
  • Your credentials are correct. You can check them by logging into the realm for the authentication chain that includes the WDSSO module using your Active Directory user credentials. For example, the URL would be similar to this, where the authentication chain is ldapService and the realm is top level:
    http://host1.example.com:8080/openam/XUI/#login/&service=ldapService
  • The Service Principal Name (SPN) for the AM/OpenAM service is correct in Active Directory; ensure the FQDN, which matches the SPN in Active Directory is used and the specified authcontext matches the authentication 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/OpenAM. An example command looks like this:
    $ setspn -l openam
    and gives an output as follows:
    Registered ServicePrincipalNames for CN=OpenAM,OU=employees,DC=example,DC=com:
    
    HTTP/host1.example.com
  • The userPrincipalName must be unique for all users.
  • If you are using Oracle® JDK 7, you must ensure both TCP port 88 and UDP port 88 are open in your firewall to allow communication between AM/OpenAM and Kerberos.
  • The Kerberos Server Name is an A record and not a CNAME, and that the reverse (PTR) record for that IP also resolves back to that Server Name.
  • If you are using the Windows Desktop SSO module as part of an authentication chain and Windows Desktop SSO fails, you may no longer be able to POST data to non-NTLM-authenticated web sites. For information on a possible workaround, see KB251404: You cannot post data to a non-NTLM-authenticated Web site.

Checking connection to Kerberos Key Distribution Center (KDC)

Your firewall must be configured to allow necessary communications with Kerberos; see Kerberos and Firewalls for the required ports. 

You can test the connection to the Kerberos KDC using a third-party tool called HelloKDC.java. This tool will determine if there is a connection issue and give you guidance on what the issue might be. If it shows there is a connection issue, it means the issue is outside of AM/OpenAM and will need resolving before you attempt any further configuration / testing within AM/OpenAM.

Note

This is a third-party tool that we suggest can be used for troubleshooting but is not supported by ForgeRock.

The following links provide information about the HelloKDC.java tool:

Example

The following example shows a connection issue returned from HelloKDC.java, which correlates to an exception in the Authentication logs:

  • HelloKDC.java output:
    >>>KRBError:
         sTime is Thu Jul 20 14:21:25 GMT 2017 1498776265000
         suSec is 154839
         error code is 25
         error Message is Additional pre-authentication required
    ...
    KRBError received: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ
    
  • Authentication logs:
    amAuth:20/07/2017 20 14:21:25 GMT: Thread[http-nio-8443-exec-1,5,main]: TransactionId[daffa5fe-cca9-4a16-8cc3-dec02f21a81f-57]
    Exception : 
    com.sun.identity.authentication.spi.AuthLoginException: Service authentication failed.
    Additional pre-authentication required (25) - Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ
    

As you can see, both are showing an error code 25: Additional pre-authentication required (Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ). Seeing the same error returned from HelloKDC.java confirms this issue is independent of AM/OpenAM and will need to be resolved outside of ForgeRock support. 

See Also

How do I set up Windows Desktop SSO in AM/OpenAM (All versions)?

OpenAM Windows Desktop SSO deep dive – part 1

Configuring and troubleshooting WDSSO in AM/OpenAM

WDSSO authentication fails with GSSException: Failure unspecified at GSS-API level error in AM/OpenAM (All versions)

Kerberos token is not valid error when authenticating with Windows Desktop SSO in AM/OpenAM (All versions) using Internet Explorer

Authenticating with Windows Desktop SSO in AM/OpenAM (All versions) does not proceed when using non-Internet Explorer browser

How do I collect all the data required for troubleshooting AM/OpenAM and Policy Agents (All versions)?

Java 8 - Troubleshooting Kerberos Login

Java 7 - Troubleshooting Kerberos Login

Related Training

N/A

Related Issue Tracker IDs

OPENAM-3826 (WindowsDesktopSSO auth-module does not log details about GSSException)

OPENAM-5894 (Can't update WindowsDesktopSSO module with ssoadm)


How do I enable debug logging for troubleshooting WDSSO and Kerberos issues in AM/OpenAM (All versions)?

The purpose of this article is to provide information on enabling debug logging for troubleshooting Windows Desktop SSO (WDSSO) and Kerberos™ issues in AM/OpenAM. Debug logging applies to the Krb5Login module of the JVM used by the web application container; this module is called by AM/OpenAM for WDSSO purposes.

Enabling debug logging

You can enable debug logging for the Krb5Login module of the JVM by setting the following JVM options to true in the application web container in which AM/OpenAM runs:

-Dsun.security.krb5.debug
-Dsun.security.jgss.debug

This adds additional debug output from the Krb5Login module to the stdout.

Additionally, you can set the following JVM option to true to enable debug logging for the SPNEGO token:

-Dsun.security.spnego.debug
Note

You should also ensure you have enabled Message level debugging in the AM/OpenAM debug logs as this provides much more information in the Authentication log. See How do I enable Message level debugging in AM/OpenAM (All versions) debug files? for further information.

Example using Apache Tomcat™ web container

With AM/OpenAM running in the Tomcat web container, you would enable debug logging by specifying CATALINA_OPTS settings in the setenv.sh file (typically located in the /tomcat/bin/ directory). If this file doesn't exist, you should create it in the same directory as the catalina.sh file (located in the /tomcat/bin/ directory).

To enable debug logging:

  1. Add the following line to the setenv.sh file:
    export CATALINA_OPTS="-Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true -Dsun.security.spnego.debug=true"
  2. Restart the web container.

The additional debug output will be sent to the Tomcat catalina.out log file by default.

Note

If you can't find an issue on the AM/OpenAM side or instead believe it to be an issue on the Microsoft® Windows® side, you can enable Kerberos event logging on the Windows / Active Directory® server as detailed in: Microsoft - How to enable Kerberos event logging.

See Also

How do I troubleshoot WDSSO and Kerberos issues in AM/OpenAM (All versions)?

How do I set up Windows Desktop SSO in AM/OpenAM (All versions)?

OpenAM Windows Desktop SSO deep dive – part 1

Configuring and troubleshooting WDSSO in AM/OpenAM

How do I collect all the data required for troubleshooting AM/OpenAM and Policy Agents (All versions)?

How do I record troubleshooting information in AM (All versions) and OpenAM 13.x?

Best practice for recording troubleshooting information in AM (All versions) and OpenAM 13.x

Java 8 - Troubleshooting Kerberos Login

Java 7 - Troubleshooting Kerberos Login

Related Training

N/A

Related Issue Tracker IDs

OPENAM-3826 (WindowsDesktopSSO auth-module does not log details about GSSException)

OPENAM-5894 (Can't update WindowsDesktopSSO module with ssoadm)


Known issues


WDSSO authentication fails with java.lang.ArrayIndexOutOfBoundsException after upgrading to, or installing AM 5.1.1

The purpose of this article is to provide assistance if you encounter a "javax.security.auth.login.LoginException: java.lang.ArrayIndexOutOfBoundsException" when Kerberos / Windows Desktop SSO (WDSSO) authentication fails after upgrading to, or installing AM 5.1.1. You will see "SETTING Failure Module name.... :WDSSOmodule" and "failureModuleSet is : [WDSSOmodule]" errors instead if you are using an authentication chain with the WDSSO module.

Symptoms

You will see one of the following errors in the Authentication debug log depending on whether you are using an authentication chain or not.

No authentication chain

If you are authenticating using a URL such as:

http://host1.example.com:8080/openam/XUI/?realm=/employees#login&module=WDSSO

You will see the following error in the Authentication debug log when WDSSO authentication fails:

amAuth:12/11/2017 09:32:47:736 AM CEST: Thread[http-nio-8080-exec-3,5,main]: TransactionId[a4ecba01-9bb4-e309-4441-14b6500b1cb9-249] 
Error during login.. 
amAuth:12/11/2017 09:32:47:736 AM CEST: Thread[http-nio-8080-exec-3,5,main]: TransactionId[a4ecba01-e309-9bb4-4441-14b6500b1cb9-249] 
Exception 
javax.security.auth.login.LoginException: java.lang.ArrayIndexOutOfBoundsException: 7 
   at com.sun.identity.authentication.modules.windowsdesktopsso.WindowsDesktopSSO.initWindowsDesktopSSOAuth(WindowsDesktopSSO.java:591) 
   at com.sun.identity.authentication.modules.windowsdesktopsso.WindowsDesktopSSO.process(WindowsDesktopSSO.java:158) 
   at com.sun.identity.authentication.spi.AMLoginModule.wrapProcess(AMLoginModule.java:1083) 
   at com.sun.identity.authentication.spi.AMLoginModule.login(AMLoginModule.java:1274) 
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
   at java.lang.reflect.Method.invoke(Method.java:498) 
   at com.sun.identity.authentication.jaas.LoginContext.invoke(LoginContext.java:219) 
   at com.sun.identity.authentication.jaas.LoginContext.login(LoginContext.java:127) 
   at com.sun.identity.authentication.service.AMLoginContext.runLogin(AMLoginContext.java:559) 
   at com.sun.identity.authentication.server.AuthContextLocal.submitRequirements(AuthContextLocal.java:586) 
   at org.forgerock.openam.core.rest.authn.core.wrappers.AuthContextLocalWrapper.submitRequirements(AuthContextLocalWrapper.java:107) 
   at org.forgerock.openam.core.rest.authn.core.LoginProcess.next(LoginProcess.java:167) 
   at org.forgerock.openam.core.rest.authn.RestAuthenticationHandler.processAuthentication(RestAuthenticationHandler.java:260) 
   at org.forgerock.openam.core.rest.authn.RestAuthenticationHandler.authenticate(RestAuthenticationHandler.java:165) 
   at org.forgerock.openam.core.rest.authn.RestAuthenticationHandler.initiateAuthentication(RestAuthenticationHandler.java:96) 
   at org.forgerock.openam.core.rest.authn.http.AuthenticationServiceV1.authenticate(AuthenticationServiceV1.java:159) 

Authentication chain

If you are authenticating using a URL such as:

http://host1.example.com:8080/openam/XUI/?realm=/employees#login&service=WDSSOchain

You will see the following error in the Authentication debug log when WDSSO authentication fails, where WDSSOmodule is the module name in this example:

amAuthWindowsDesktopSSO:12/11/2017 09:32:47:736 AM CEST: Thread[tomcat-http--50,5,main]: TransactionId[a4ecba01-e309-9bb4-4441-14b6500b1cb9-249]
Service login succeeded.
amLoginModule:12/11/2017 09:32:47:736 AM CEST: Thread[tomcat-http--50,5,main]: TransactionId[a4ecba01-e309-9bb4-4441-14b6500b1cb9-249]
SETTING Failure Module name.... :WDSSOmodule
amAuth:12/11/2017 09:32:47:736 AM CEST: Thread[tomcat-http--50,5,main]: TransactionId[a4ecba01-e309-9bb4-4441-14b6500b1cb9-249]
Module name is .. WDSSOmodule
amAuth:12/11/2017 09:32:47:736 AM CEST: Thread[tomcat-http--50,5,main]: TransactionId[a4ecba01-e309-9bb4-4441-14b6500b1cb9-249]
failureModuleSet is : [WDSSOmodule]
amAuth:12/11/2017 09:32:47:736 AM CEST: Thread[tomcat-http--50,5,main]: TransactionId[a4ecba01-e309-9bb4-4441-14b6500b1cb9-249]
getUserDN: null
amJAAS:12/11/2017 09:32:47:736 AM CEST: Thread[tomcat-http--50,5,main]: TransactionId[a4ecba01-e309-9bb4-4441-14b6500b1cb9-249]
Method login LoginModuleControlFlag: sufficient failure.

Recent Changes

Upgraded to AM 5.1.1 with an existing WDSSO module.

Configured the WDSSO authentication module after upgrading to, or installing AM 5.1.1.

Causes

The WDSSO authentication module stores service schema attributes in a String array and references them using index numbers. Following recent changes to resolve OPENAM-5153 (Auth modules should call setAuthLevel after successful login), the index numbers got out of sync and caused the ArrayIndexOutOfBoundsException.

Solution

This issue can be resolved by upgrading to AM 5.5 or later; you can download this from BackStage.

Additionally, there is an existing patch fix available for AM 5.1.1 that can be obtained by raising a ticket with ForgeRock Support.

See Also

How do I set up Windows Desktop SSO in AM/OpenAM (All versions)?

How do I enable debug logging for troubleshooting WDSSO and Kerberos issues in AM/OpenAM (All versions)?

Configuring and troubleshooting WDSSO in AM/OpenAM

Related Training

N/A

Related Issue Tracker IDs

OPENAM-11610 (WindowSSO module broken in AM 5.1.1 after upgrade)


WDSSO authentication fails with GSSException: Failure unspecified at GSS-API level error in AM/OpenAM (All versions)

The purpose of this article is to provide assistance if Windows Desktop SSO (WDSSO) authentication fails with a "GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)" error in AM/OpenAM.

Symptoms

The following error is shown in the Authentication debug log when authentication fails:

amAuthWindowsDesktopSSO:12/10/2016 10:02:47:186 AM GMT: Thread[http-nio-8082-exec-8,5,main]: TransactionId[5abc2e7a-5281-477d-8f2e-afd6b4a51cf9-132]
ERROR: Authentication failed with PrivilegedActionException wrapped GSSException. Stack Trace
GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)
   at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Unknown Source)
   at sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source)
   at sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source)
   at com.sun.identity.authentication.modules.windowsdesktopsso.WindowsDesktopSSO$1.run(WindowsDesktopSSO.java:265)
...
Caused by: KrbException: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled
   at sun.security.krb5.EncryptionKey.findKey(Unknown Source)
   at sun.security.krb5.KrbApReq.authenticate(Unknown Source)
   at sun.security.krb5.KrbApReq.<init>(Unknown Source)
   at sun.security.jgss.krb5.InitSecContextToken.<init>(Unknown Source)
   ... 58 more

Recent Changes

The keytab file was created using a key with 256-bit AES encryption, for example with the following crypto option:

-crypto AES256-SHA1

Causes

256-bit AES encryption was not enabled on the machine where the keytab file was created. Java® does not support 256-bit AES encryption by default; only 128-bit AES encryption is supported.

Solution

This issue can be resolved by installing the Oracle® Java JCE unlimited strength jars in the $JAVA_HOME/jre/lib/security/ directory and your Microsoft® Windows® machine must also support this encryption. These jars can be downloaded from the following links depending on which Java version you are using:

You should then re-create the keytab file.

Note

You can check that the keytab file has AES256 enabled as detailed in How do I troubleshoot WDSSO and Kerberos issues in AM/OpenAM (All versions)? (Checking keytab file details).

See Also

WDSSO/Kerberos authentication fails in AM/OpenAM (All versions) with an HTTP 400 Bad Request response

Unable to obtain password from user error when WDSSO authentication fails in AM/OpenAM (All versions)

Clock skew too great (37) error when WDSSO authentication fails in AM/OpenAM (All versions)

SAML redirect is ignored when doing an IdP or SP initiated SSO with WDSSO/Kerberos authentication in OpenAM 13.0 and 13.5

How do I troubleshoot WDSSO and Kerberos issues in AM/OpenAM (All versions)?

Configuring and troubleshooting WDSSO in AM/OpenAM

Authentication and Single Sign-On Guide › Implementing Authentication › Windows Desktop SSO Authentication Module

Related Training

N/A

Related Issue Tracker IDs

N/A


WDSSO/Kerberos authentication fails in AM/OpenAM (All versions) with an HTTP 400 Bad Request response

The purpose of this article is to provide assistance if Windows Desktop SSO/Kerberos™ authentication fails in AM/OpenAM with an HTTP 400 Bad Request response.

Symptoms

The browser hangs when attempting WDSSO/Kerberos authentication and you see the following response:

HTTP 400 - Bad Request

This may only affect some users, especially those who are members of a large number of Active Directory® groups.

Recent Changes

N/A

Causes

AM/OpenAM does not put a limit on the token size. This issue occurs when the Kerberos token being sent by the browser (in the Authorization: Negotiate section of the HTTP request header) is bigger than the max header size specified in the web application container's configuration file (server.xml if you are using Apache Tomcat™). This can happen when a user is a member of a large number of Active Directory groups, which results in a much larger token.

The default max header size in Tomcat is 8KB:

<Connector port="443" maxHttpHeaderSize="8192" protocol="HTTP/1.1" SSLEnabled="true"

The maxHttpHeaderSize attribute may not be present in the server.xml file, but still defaults to 8KB.

See Problems with Kerberos authentication when a user belongs to many groups for further information.

Solution

You can resolve this issue by excluding the PAC when issuing service tokens, since AM/OpenAMM does not need the PAC in order for WDSSO auto-login to be successful. You can achieve this by adding the following bit flag to the existing User Account Control settings in Active Directory for the account associated with the Service Principal Name (SPN) of AM/OpenAM:

0x2000000:  When KDC emits ticket for this service accounts, do NOT include the Privilege Attribute Certificate (PAC)

You should consult your Active Directory administrator on how to make this change or use a script such as: UserAccountControl - Add/Remove Bits. This change is outside the scope of ForgeRock support; if you want more tailored advice, consider engaging Professional Services.

Optional workaround

Alternatively, you can increase the max header size in the web application container. You should increase it to a size that will accommodate your expected token sizes; capturing a HTTP trace when authentication fails can help you determine the size of the token being passed in the header. Otherwise, increasing it to 16KB is a good starting point.

Note

This option may consume more memory; you should test this to determine the optimal size in your environment.

For example, for Tomcat:

  1. Edit the server.xml file and amend the maxHttpHeaderSize value, for example, to increase it to 16KB:
    <Connector port="443" maxHttpHeaderSize="16384" protocol="HTTP/1.1" SSLEnabled="true"
    
    
    If this attribute is not present, you should add it with the new value.

See Apache Tomcat 8 Configuration Reference for further information.

See Also

How do I troubleshoot WDSSO and Kerberos issues in AM/OpenAM (All versions)?

How do I enable debug logging for troubleshooting WDSSO and Kerberos issues in AM/OpenAM (All versions)?

Configuring and troubleshooting WDSSO in AM/OpenAM

Problems with Kerberos authentication when a user belongs to many groups

Related Training

N/A

Related Issue Tracker IDs

N/A


Kerberos token is not valid error when authenticating with Windows Desktop SSO in AM/OpenAM (All versions) using Internet Explorer

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/OpenAM and using the Internet Explorer® or Microsoft® Edge browser. WDSSO only works with Internet Explorer or Microsoft Edge when the server uses HTTP persistent connection. The user sees a "401 Unauthorized / Access denied" error.

Symptoms

The user sees a 401 Unauthorized / Access denied error when they attempt to access a resource protected by AM/OpenAM, 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

Internet Explorer or 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/OpenAM 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/OpenAM 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:

  1. Check if the Kerberos service ticket was retrieved for AM/OpenAM using either the Kerbtray or Klist utilities from Microsoft (depending on Microsoft Windows version). For example:
    • If the Kerberos service ticket does exist for the AM/OpenAM 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 Windows Desktop SSO in AM/OpenAM (All versions)? for further information.
    • If the Kerberos service ticket does not exist for the AM/OpenAM FQDN - proceed to the next step.
    Running the klist command:
    $ klist
    Produces an output such as the following:
    Server: HTTP/host1.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
  2. Check the AM/OpenAM FQDN is listed as a trusted host (trusted Intranet site list) in the browser and add it if it's not listed (Security tab > Local Intranet > Sites > Advanced).
  3. Check the SPN for the AM/OpenAM service in Active Directory and correct if necessary. Ensure 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/OpenAM. An example command looks like this:
    $ setspn -l openam
    and gives an output as follows:
    Registered ServicePrincipalNames for CN=OpenAM,OU=employees,DC=example,DC=com:
    
    HTTP/host1.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.

See Also

How do I troubleshoot WDSSO and Kerberos issues in AM/OpenAM (All versions)?

Authenticating with Windows Desktop SSO in AM/OpenAM (All versions) does not proceed when using non-Internet Explorer browser

How do I set up Windows Desktop SSO in AM/OpenAM (All versions)?

How do I redirect users to a different login module if Kerberos/WDSSO authentication fails with a 401 error in OpenAM 11.x and 12.x using the Classic UI?

Configuring and troubleshooting WDSSO in AM/OpenAM

Kerbtray Utility Download

Klist Utility

Setspn Utility

Microsoft Network Monitor

Microsoft Message Analyzer

Related Training

N/A

Related Issue Tracker IDs

N/A


Authenticating with Windows Desktop SSO in AM/OpenAM (All versions) does not proceed when using non-Internet Explorer browser

The purpose of this article is to provide assistance if authenticating with Windows Desktop SSO (WDSSO) in AM/OpenAM does not proceed when using a non-Internet Explorer® browser, such as Chrome™ or Firefox®. The user sees a "401 Unauthorized / Access denied" error.

Symptoms

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

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

amLoginModule:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
Login, class = com.sun.identity.authentication.modules.windowsdesktopsso.WindowsDesktopSSO, module=WDSSO, file=/config/auth/default/WindowsDesktopSSO.xml
amLoginModule:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
AMLoginModuleiplanet-am-auth-shared-state-behavior-pattern is set to tryFirstPass
amLoginModule:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
This module is not done yet. CurrentState: 1
amLoginModule:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
callback stateLength in file = 1
amLoginModule:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
callback size for state 1=1
amLoginModule:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
clone #0 is PagePropertiesCallback
amLoginModule:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
Login, state = 1
amCallback:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
callback handler method
amAuth:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
Setting page timeout :120
amAuth:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
setting Last Callback Sent :1394578342563
amCallback:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
Set callbacks, throwing java.lang.Error.
amJAAS:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
LoginContext.invoke():Handling expected java.lang.Error
amAuth:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
Caught java.lang.Error returned from DSAMEHandler
java.lang.Error: return from DSAMECallback
	at com.sun.identity.authentication.service.DSAMECallbackHandler.handle(DSAMECallbackHandler.java:141)
	at com.sun.identity.authentication.spi.AMLoginModule.login(AMLoginModule.java:1134)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.sun.identity.authentication.jaas.LoginContext.invoke(LoginContext.java:208)
	at com.sun.identity.authentication.jaas.LoginContext.login(LoginContext.java:124)
	at com.sun.identity.authentication.service.AMLoginContext.runLogin(AMLoginContext.java:557)
	at com.sun.identity.authentication.service.AMLoginContext.executeLogin(AMLoginContext.java:515)
	at com.sun.identity.authentication.server.AuthContextLocal.login(AuthContextLocal.java:541)
	at com.sun.identity.authentication.server.AuthContextLocal.login(AuthContextLocal.java:433)
	at com.sun.identity.authentication.server.AuthContextLocal.login(AuthContextLocal.java:284)
	at com.sun.identity.authentication.server.AuthContextLocal.login(AuthContextLocal.java:216)
	at com.sun.identity.authentication.UI.LoginViewBean.getLoginDisplay(LoginViewBean.java:941)
	at com.sun.identity.authentication.UI.LoginViewBean.processLogin(LoginViewBean.java:887)
	at com.sun.identity.authentication.UI.LoginViewBean.forwardTo(LoginViewBean.java:538)
	at com.iplanet.jato.ApplicationServletBase.dispatchRequest(ApplicationServletBase.java:981)
	at com.iplanet.jato.ApplicationServletBase.processRequest(ApplicationServletBase.java:615)
	at com.iplanet.jato.ApplicationServletBase.doGet(ApplicationServletBase.java:459)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.forgerock.openam.validation.ResponseValidationFilter.doFilter(ResponseValidationFilter.java:44)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:95)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)

amAuth:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
AMLoginContext:Thread started... returning.
amAuthContextLocal:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
after AMLoginContext::exceuteLogin : 
amAuth:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
getStatus : status is... : 2
amAuth:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
getStatus : status is... : 2
amAuthContextLocal:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
Status at the end of login() : in_progress
amAuthContextLocal:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
AuthContextLocal::hasMoreRequirements()
amAuth:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
getStatus : status is... : 2
amAuth:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
getStatus : status is... : 2
amAuth:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
Recd Callback in amlc.getRequiredInfo : com.sun.identity.authentication.spi.PagePropertiesCallback@2f466880
amAuth:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
Recd Callback in amlc.getRequiredInfo : com.sun.identity.authentication.spi.HttpCallback@3776c3bf
amLoginViewBean:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
In getLoginDisplay, has More Requirements
amAuthContextLocal:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
AuthContextLocal::getRequirements()
amAuth:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
getStatus : status is... : 2
amAuth:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
getStatus : status is... : 2
amLoginViewBean:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
Start authorization negotiation...
amLoginViewBean:03/11/2014 11:52:22:563 PM CET: Thread[http-bio-8080-exec-8,5,main]
header: WWW-Authenticate, value: Negotiate, code: 401

Recent Changes

Implemented the Windows Desktop SSO authentication module.

Causes

The browser cannot return a Kerberos™ token during the SPNEGO handshake because it cannot retrieve a Kerberos service ticket for AM/OpenAM from Active Directory®.

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

  • The AM/OpenAM 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:

  1. Check if the Kerberos service ticket was retrieved for AM/OpenAM using either the Kerbtray or Klist utilities from Microsoft (depending on Microsoft Windows version). For example:
    • If the Kerberos service ticket does exist for the AM/OpenAM FQDN - check your browser settings to ensure the browser is correctly set up for SPNEGO (Integrated Windows Authentication) and update where necessary. See How do I set up Windows Desktop SSO in AM/OpenAM (All versions)? for further information.
    • If the Kerberos service ticket does not exist for the AM/OpenAM FQDN - proceed to the next step.
    Running the klist command:
    $ klist
    Produces an output such as the following:
    Server: HTTP/host1.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
  2. Check the AM/OpenAM FQDN is listed as a trusted host in the browser and add it if it's not listed. You can check as follows according to which browser you are using:
    • Chrome - since Chrome uses the Internet Explorer settings, you should check the AM/OpenAM FQDN is added to the trusted Intranet site list in Internet Explorer (Security tab > Local Intranet > Sites > Advanced).
    • Firefox - the AM/OpenAM FQDN should be added to the Integrated Authentication Sites list (Tools > Integrated Authentication Sites) if you're using the Integrated Authentication plugin. The equivalent Firefox setting is network.negotiate-auth.trusted-uris (accessed via about:config).
  3. Check the SPN for the AM/OpenAM 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/OpenAM. An example command looks like this:
    $ setspn -l openam
    and gives an output as follows:
    Registered ServicePrincipalNames for CN=OpenAM,OU=employees,DC=example,DC=com:
    
    HTTP/host1.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.

Custom 401 Page (Classic UI in OpenAM 12.x)

You can additionally implement a custom application or container level 401 error page if you are using the Classic UI. This page redirects the user (using the refresh meta tag within the html head tag) to the OpenAM login page to allow authentication to continue using the next authentication module in the authentication chain. This provides a better user experience, as users can either authenticate with the WDSSO module or be redirected to a different login module for authentication depending on whether their browser is configured to retrieve a Kerberos token or not.

See How do I redirect users to a different login module if Kerberos/WDSSO authentication fails with a 401 error in OpenAM 11.x and 12.x using the Classic UI? for further information on creating this page.

See Also

How do I troubleshoot WDSSO and Kerberos issues in AM/OpenAM (All versions)?

How do I redirect users to a different login module if Kerberos/WDSSO authentication fails with a 401 error in OpenAM 11.x and 12.x using the Classic UI?

Kerberos token is not valid error when authenticating with Windows Desktop SSO in AM/OpenAM (All versions) using Internet Explorer

How do I set up Windows Desktop SSO in AM/OpenAM (All versions)?

Kerbtray Utility Download

Klist Utility

Setspn Utility

Microsoft Network Monitor

Microsoft Message Analyzer

Related Training

N/A

Related Issue Tracker IDs

N/A


SAML redirect is ignored when doing an IdP or SP initiated SSO with WDSSO/Kerberos authentication in OpenAM 13.0 and 13.5

The purpose of this article is to provide assistance if SAML redirection is ignored when doing an IdP or SP initiated SSO in OpenAM 13.0 and 13.5. This issue occurs when you are using a realm DNS alias for federation and that Realm is setup for Windows Desktop SSO/Kerberos authentication.

Symptoms

XUI

If you are using the XUI, you will observe the following behavior after successfully authenticating with the WDSSO authentication module:

  • You are redirected to the default SuccessURL if one has been set up for the WDSSO authentication module, OR
  • You are redirected to OpenAM and see the following message in the browser:
    You have already logged in. Do you want to log out and then login to a different organization?

Expected behavior: you are redirected to the IdP or SP depending on your setup.

Classic UI

If you are using the Classic UI, you will see the following message in the browser:

An internal authentication error has occurred. Contact your system administrator.

The following error is shown in the Authentication debug log when this happens:

ERROR: LoginViewBean.forwardTo(): There was an Exception doing the forward/redirect 
org.apache.jasper.JasperException: java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to java.lang.String 
   at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:555) 
   at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:476) 
   at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:396) 
   at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:340) 
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) 
   at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291) 
   at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 
   at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) 
...
Caused by: java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to java.lang.String 
   at com.sun.identity.saml2.common.SAML2Utils.getParameter(SAML2Utils.java:1370) 
   at com.sun.identity.saml2.common.SAML2Utils.getRealm(SAML2Utils.java:1356) 
   at org.apache.jsp.saml2.jsp.idpSSOFederate_jsp._jspService(idpSSOFederate_jsp.java:131) 
   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) 
   at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:438) 
... 72 more

Recent Changes

Upgraded to, or installed OpenAM 13.0 or 13.5.

Made changes to your configuration so that you now have the combination of using a realm DNS alias for federation purposes and have the WDSSO authentication module configured in that realm for authentication.

Causes

The realm context is lost in the process when the realm DNS alias is used, which prevents you being correctly redirected to the IdP or SP as expected. 

Solution

This issue can be resolved by upgrading to OpenAM 13.5.1 or later; you can download this from BackStage.

Workaround

Alternatively, the following options are available to resolve this issue:

  • You can update your configuration so that you use the OpenAM DNS URL for federation rather than the realm DNS alias.
  • You can use an alternative authentication module.

See Also

N/A

Related Training

N/A

Related Issue Tracker IDs

OPENAM-8351 (SAML2 JSP pages making use of the SAML2Auditor are calling the SAML2Utils.getRealm with an incorrect Map structure)

OPENAM-8971 (currentGoto : null is received in XUI when a realm dns is being used for Federation and authentication is done via wdsso/kerberos auth module)


Unable to obtain password from user error when WDSSO authentication fails in AM/OpenAM (All versions)

The purpose of this article is to provide assistance if you receive a "javax.security.auth.login.LoginException: Unable to obtain password from user" error when attempting to log into AM/OpenAM using the Windows Desktop SSO (WDSSO) authentication module.

Symptoms

The following error is shown in the Authentication log when WDSSO authentication fails:

amAuthWindowsDesktopSSO:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-4,5,main]
WindowsDesktopSSO params:
principal: HTTP/host1.forgerock.com@WINDOWS.EXAMPLE.COM
keytab file: /etc/openam.HTTP.keytab
realm : WINDOWS.EXAMPLE.COM
kdc server: windows.example.com
domain principal: false
Lookup user in realm:false
Accepted Kerberos realms: []
auth level: 0
amAuthWindowsDesktopSSO:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-4,5,main]
Init WindowsDesktopSSO. This should not happen often.
amAuth:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-4,5,main]
spi authLevel :0
amAuth:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-4,5,main]
module configuration authLevel :0
amAuth:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-4,5,main]
levelSet :false
amAuthWindowsDesktopSSO:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-4,5,main]
New Service Login ...
amAuthWindowsDesktopSSO:04/10/2016 16:43:11:136 PM PDT: Thread[http-bio-12023-exec-4,5,main]
ERROR: Service Login Error:
amAuthWindowsDesktopSSO:04/10/2016 16:43:11:136 PM PDT: Thread[http-bio-12023-exec-4,5,main]
Stack trace:
javax.security.auth.login.LoginException: Unable to obtain password from user
     at com.sun.security.auth.module.Krb5LoginModule.promptForPass(Krb5LoginModule.java:856)
     at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:719)
     at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:584)
...

You will also see a similar error in the amAuthWindowsDesktopSSO debug log:

04/10/2016 16:43:11:135 PM PDT: Thread[service-j2ee,5,main] 
ERROR: Service Login 
Error: 04/10/2016 16:43:11:135 PM PDT: Thread[service-j2ee,5,main] 
Stack trace: javax.security.auth.login.LoginException: 
Unable to obtain password from user at com.sun.security.auth.module.
Krb5LoginModule.promptForPass(Krb5LoginModule.java:745) 
     at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication
(Kr b5LoginModule.java:624) at com.sun.security.auth.module.
Krb5LoginModule.login(Krb5LoginModule.java:512) 
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
... 

Recent Changes

Configured the WDSSO module.

Updated your keytab file.

Causes

There is an issue with your keytab file and/or the configured service principal. Alternatively, this can be caused by an incorrect version of Java® being used for your AM/OpenAM version.

Solution

You should use either the Kerbtray or Klist utilities from Microsoft® (depending on Microsoft Windows version) to display details about your keytab file.

This is an example output from the Klist utility:

Server: HTTP/host1.example.com @ WINDOWS.EXAMPLE.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

You can then check the following and resolve as applicable:

  • Check you have used an appropriate encryption type (KerbTicket Encryption Type in example Klist output) when generating the keytab file and that you have updated the user account properties in Active Directory® to match. The corresponding encryption type should be selected in the user account properties.
  • Check the configured service principal in AM/OpenAM matches the one in the keytab file (Server in example Klist output). You can check the configured service principal in the console as follows:
    • AM / OpenAM 13.x console: navigate to Realms > [Realm Name] > Authentication > Modules > [Module Name] > Service Principal and update if it does not match the value in the keytab file.
    • Pre-OpenAM 13 console: navigate to Access Control > [Realm Name] > Authentication >  Module Instances > [Module Name] > Service Principal and update if it does not match the value in the keytab file.

If this fails to resolve your issue, you should check you are using an appropriate Java® version for your AM/OpenAM version. Supported Java versions can be found in the release notes applicable to your AM/OpenAM version, for example, the latest supported Java versions can be found here: Release Notes › Before You Install › Java Requirements

See Also

WDSSO/Kerberos authentication fails in AM/OpenAM (All versions) with an HTTP 400 Bad Request response

WDSSO authentication fails with GSSException: Failure unspecified at GSS-API level error in AM/OpenAM (All versions)

Clock skew too great (37) error when WDSSO authentication fails in AM/OpenAM (All versions)

How do I troubleshoot WDSSO and Kerberos issues in AM/OpenAM (All versions)?

How do I enable debug logging for troubleshooting WDSSO and Kerberos issues in AM/OpenAM (All versions)?

Related Training

N/A

Related Issue Tracker IDs

N/A


Clock skew too great (37) error when WDSSO authentication fails in AM/OpenAM (All versions)

The purpose of this article is to provide assistance if you receive a "javax.security.auth.login.LoginException: Clock skew too great (37)" error when attempting to log into the Windows Desktop SSO (WDSSO) authentication module in AM/OpenAM.

Symptoms

The following error is shown in the Authentication log when WDSSO authentication fails:

amAuthWindowsDesktopSSO:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-8,5,main]
WindowsDesktopSSO params:
principal: HTTP/host1.example.com@WINDOWS.EXAMPLE.COM
keytab file: /etc/openam.HTTP.keytab
realm : WINDOWS.EXAMPLE.COM
kdc server: windows.example.com
domain principal: false
Lookup user in realm:false
Accepted Kerberos realms: []
auth level: 0
amAuthWindowsDesktopSSO:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-8,5,main]
Init WindowsDesktopSSO. This should not happen often.
amAuth:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-8,5,main]
spi authLevel :0
amAuth:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-8,5,main]
module configuration authLevel :0
amAuth:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-8,5,main]
levelSet :false
amAuthWindowsDesktopSSO:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-8,5,main]
New Service Login ...
amAuthWindowsDesktopSSO:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-8,5,main]
ERROR: Service Login Error:
amAuthWindowsDesktopSSO:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-8,5,main]
Stack trace:
javax.security.auth.login.LoginException: Clock skew too great (37)
    at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:763)
    at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:584)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
...
Caused by: KrbException: Identifier doesn't match expected value (906)
    at sun.security.krb5.internal.KDCRep.init(KDCRep.java:143)
    at sun.security.krb5.internal.ASRep.init(ASRep.java:65)
    at sun.security.krb5.internal.ASRep.<init>(ASRep.java:60)
    at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:60)
... 113 more

amLoginModule:04/10/2016 16:43:11:135 PM PDT: Thread[http-bio-12023-exec-8,5,main]
SETTING Failure Module name.... :wdsso

Recent Changes

N/A

Causes

The difference between the time on the Kerberos™ or Active Directory® Domain Controller and the AM/OpenAM server is too great.

Solution

This issue can be resolved by correcting the time on the Kerberos or Active Directory Domain Controller so it matches the time on the AM/OpenAM server.

See Also

WDSSO authentication fails with GSSException: Failure unspecified at GSS-API level error in AM/OpenAM (All versions)

WDSSO/Kerberos authentication fails in AM/OpenAM (All versions) with an HTTP 400 Bad Request response

Unable to obtain password from user error when WDSSO authentication fails in AM/OpenAM (All versions)

How do I troubleshoot WDSSO and Kerberos issues in AM/OpenAM (All versions)?

How do I enable debug logging for troubleshooting WDSSO and Kerberos issues in AM/OpenAM (All versions)?

Related Training

N/A

Related Issue Tracker IDs

N/A


Updating or creating the WindowsDesktopSSO authentication module via the configurator tool or ssoadm fails in OpenAM 12.0.0, 12.0.1 and 12.0.2

The purpose of this article is to provide assistance if you receive a "iplanet-am-auth-windowsdesktopsso-keytab does not match the service schema" error when updating or creating the Windows Desktop SSO (WDSSO) authentication module via the configurator tool in OpenAM 12.0.0, 12.0.1 and 12.0.2. Similarly, if you use ssoadm to configure the Windows Desktop SSO authentication module, you see a "File [path_to_keytab] did not exist" error.

Symptoms

An error similar to the following is shown in the ssoadm Configuration debug log if you use the configurator tool to configure the Windows Desktop SSO authentication module in OpenAM and include the iplanet-am-auth-windowsdesktopsso-keytab-file property:

amCLI:06/14/2015 10:17:25:789 AM PDT: Thread[main,5,main]
ERROR: UpdateAuthInstance.handleRequest
Message:The attribute name iplanet-am-auth-windowsdesktopsso-keytab does not match the service schema

                at com.sun.identity.sm.ServiceSchemaImpl.validateAttrValues(ServiceSchemaImpl.java:471)
                at com.sun.identity.sm.ServiceSchemaImpl.validateAttributes(ServiceSchemaImpl.java:291)
                at com.sun.identity.sm.ServiceConfig.setAttributes(ServiceConfig.java:536)
                at com.sun.identity.authentication.config.AMAuthenticationInstance.setAttributeValues(AMAuthenticationInstance.java:155)
                at com.sun.identity.cli.authentication.UpdateAuthInstance.handleRequest(UpdateAuthInstance.java:98)
                at com.sun.identity.cli.SubCommand.execute(SubCommand.java:291)
                at com.sun.identity.cli.CLIRequest.process(CLIRequest.java:212)
                at com.sun.identity.cli.CLIRequest.process(CLIRequest.java:134)
                at com.sun.identity.cli.CommandManager.serviceRequestQueue(CommandManager.java:573)
                at com.sun.identity.cli.CommandManager.<init>(CommandManager.java:170)
                at com.sun.identity.cli.CommandManager.main(CommandManager.java:147)

The following response is shown if you use a ssoadm command to add or update the iplanet-am-auth-windowsdesktopsso-keytab-file property:

File [path_to_keytab] did not exist. 

Recent Changes

Upgraded to OpenAM 12.0.0, 12.0.1 or 12.0.2

Created or updated the Windows Desktop SSO authentication module via the configurator tool or ssoadm; specifically setting the iplanet-am-auth-windowsdesktopsso-keytab-file property.

Causes

The UpdateAuthInstance class assumes that all properties ending with -file refer to a file rather than a value as is the case with the iplanet-am-auth-windowsdesktopsso-keytab-file property. Since it cannot locate a file when this property is set, it fails.

Solution

This issue can be resolved by upgrading to OpenAM 12.0.3 or later; you can download this version from BackStage.

Workaround

You can workaround this issue by creating a file that contains the required value for the iplanet-am-auth-windowsdesktopsso-keytab-file property and use the iplanet-am-auth-windowsdesktopsso-keytab-file-file property to reference this file instead.

For example, to update the property via ssoadm you would:

  1. Create a data file (called DATA_FILE to match the next command) that contains the required value for the iplanet-am-auth-windowsdesktopsso-keytab-file property (rather than the actual location of the keytab file itself), for example: 
    /etc/krb5.keytab
  2. Enter the following command to update the Windows Desktop SSO authentication module:
    $ ./ssoadm update-auth-instance -e [realmname] -m [moduleinstancename] -u [adminID] -f [passwordfile] -a iplanet-am-auth-windowsdesktopsso-keytab-file-file=DATA_FILE
    replacing [realmname], [moduleinstancename], [adminID] and [passwordfile] with appropriate values.

See Also

OpenAM Reference › OpenAM Command Line Tools › ssoadm

OpenAM Reference › OpenAM Command Line Tools › configurator.jar

OpenAM Administration Guide › Defining Authentication Services › Hints for the Windows Desktop SSO Authentication Module

Related Training

N/A

Related Issue Tracker IDs

OPENAM-5894 (Can't update WindowsDesktopSSO module with ssoadm)


Copyright and TrademarksCopyright © 2018 ForgeRock, all rights reserved.

This content has been optimized for printing.

Loading...