Troubleshoot SSO with Active Directory in a Java Web Application

In the case of authentication failure, there are some diagnostic tools that may help diagnose a problem.

Apache Tomcat Log File

The Apache Tomcat log file may contain helpful information as to the nature of the problem. Typically the Tomcat logs are located under ${CATALINA_HOME}/logs. It is possible to set the java.security.debug variable in the Tomcat environment to elevate the log level and to help check for security issues.

Authentication Groups

Use /opt/likewise/bin/lw-list-groups-for-user to list the groups the current user belongs to.

The Microsoft KLIST utility

The Microsoft KLIST utility will help determine whether Internet Explorer obtained a Kerberos ticket for your web server.

Integrated Windows Authentication requires that the client obtains a Kerberos ticket from Active Directory.

To check whether the web browser obtained a Kerberos ticket for your web server:

  1. Log on to a Windows computer that is joined to the domain. Log on as a domain user.
  2. Access the protected web site from Internet Explorer using the server name in the URL rather than the IP address. For example: https://myserver.
  3. From a command prompt run the KLIST command. This will show a dialog displaying all Kerberos tickets.
  4. Look for the name of your domain in the list of the tickets. Under your domain look for the service principal. It will like this example: HTTP/myserver.mydomain.com.

KLIST Linux or Unix Utility

The klist Linux or Unix utility, part of the krb5-client package, may be used to check the Kerberos keytab file on the Linux or Unix system. The output of this command will display all service principal tickets that are contained in the keytab file. This command may be unavailable on some systems. To use klist to examine the contents of a Kerberos keytab file:

Replace myserver with your own server name and mydomain.com with your domain name.

  1. Locate the Kerberos keytab file for the protected web site.

You may need to find the Krb5Keytab directive in the Apache configuration file.

  1. Execute the klist –k <keytab file name> command: klist -k krb5_myserver.keytab.
  2. Verify that the correct service principal names are displayed. The names to look for are HTTP/myserver@MYDOMAIN.COM and HTTP/myserver.mydomain.com@MYDOMAIN.COM. It is normal to see multiple entries for the same name.

Example output:

# klist -k krb5_myserver.keytab
Keytab name: FILE:krb5_myserver.keytab KVNO Principal
---- ------------------------------------------------------------
6 HTTP/myserver@MYDOMAIN.COM
6 HTTP/myserver@MYDOMAIN.COM
6 HTTP/myserver@MYDOMAIN.COM
6 HTTP/myserver.mydomain.com@MYDOMAIN.COM
6 HTTP/myserver.mydomain.com@MYDOMAIN.COM
6 HTTP/myserver.mydomain.com@MYDOMAIN.COM

If the service principal names are not correct, go back to the Generate Kerberos keytab file step above to generate a new Kerberos keytab file.

Common Issues

As authentication problems may be difficult to diagnose, start with double checking all the configuration parameters including the validity of the generated Kerberos keytab file.

If all the configuration parameters appear to be correct, then examine the list of common problems below.

Problem Explanation
System clock out of sync For Kerberos authentication to work, the system clocks on all involved systems must not be more than 5 minutes apart. Make sure that the time on the Active Directory server, Linux or Unix web server and the client are synchronized.
User accessing the web site is not in the configured group Check the user’s group membership using /opt/likewise/bin/lw-list- groups-for-user.
Internet Explorer web browser does not consider the URL as part of the Local Intranet zone This problem is common if the web site is accessed using a URL that includes the full domain name such as https://myserver.mydomain.com. Internet Explorer will only try to obtain Kerberos tickets for websites that are in the Local Intranet zone. Try accessing the web site using just the server name, for example https://myserver. Alternatively, you can add the URL to a list of Local Intranet sites using the Sites/Advanced buttons in the Internet Options dialog on the Security tab.
Service Principal Name of the web site is mapped to more than one object in the Active Directory

This is a rather rare problem, but very difficult to diagnose because of lack of a good error that is returned to the web server. This can happen if the ktpass Windows utility was used on the Domain Controller to generate a Kerberos keytab file.

To diagnose this problem, log on to the Active Directory Domain Controller and open the Event Viewer. Look for event of type=Error, source=KDC, and event ID=11. The text of the event will be similar to this message:

There are multiple accounts with name HTTP/myserver.mydomain.com of type DS_SERVICE_PRINCIPAL_NAME.

Resolving this problem will require locating the computer or user objects used to map the service principal name in the Active Directory. The Active Directory Users and Computers MMC snap-in allows running custom LDAP queries. Use an LDAP query similar to (servicePrincipalName=HTTP/myserver.mydomain.com) to locate the Active Directory objects. Once objects are located then the spurious User object may be deleted. If the object cannot be deleted then use the ADSI Edit MMC snap-in to manually remove the HTTP/myserver.mydomain.com string from the servicePrincipalName object property.