Troubleshoot Single Sign-on and Kerberos Authentication

The following tools and procedures can help diagnose and resolve problems with Kerberos authentication when using the Apache HTTP Server for single sign-on (SSO).

Apache Log File

The location of the Apache error logs is specified in the Apache configuration file under the ErrorLog directive. The default value is, depending on your Apache version, one of the following:

  • /var/log/httpd/
  • /var/log/apache2/

Klist Utility

You can use the klist utility in /opt/pbis/bin/klist to check the Kerberos keytab file on a Linux or Unix computer. The command shows all the service principal tickets contained in the keytab file so you can verify that the correct service principal names appear.

Confirm that HTTP/rhel7@EXAMPLE.COM and HTTP/rhel7.example.com@EXAMPLE.COM appear in the list. It is normal to see multiple entries for the same name.

$ /opt/pbis/bin/klist -k /etc/httpd/httpd.ktb
Keytab name: WRFILE:/etc/httpd/httpd.ktb
KVNO Principal
---- --------------------------------------------------------------------------
5 HTTP/rhel7.example.com@EXAMPLE.COM

If your service principal names are incorrect, generate a new Kerberos keytab file.

Because you cannot store credentials for more than one principal in a Kerberos credentials cache at a time, you must maintain two or more credential caches by using the KRB5CCNAME environment variable and then switch to the cache that you want to use. To use an alternate Kerberos cache with AD Bridge, for example, you could execute the following sequence of commands as root:

[root@oracle1 ~]# KRB5CCNAME=/var/lib/pbis/krb5cc_lsass
[root@oracle1 ~]# export KRB5CCNAME
[root@oracle1 ~]# klist
Ticket cache: FILE:/var/lib/pbis/krb5cc_lsass

Confirm User Received an HTTP Ticket

Klist can be used on the current user to verify that they receive a service ticket for HTTP.

Run Klist on Linux and UNIX systems running AD Bridge or on Windows from the command prompt.

Linux klist:

apacheuser@rhel7:/home/apacheuser$ /opt/pbis/bin/klist
Ticket cache: FILE:/tmp/krb5cc_2066220575
Default principal: apacheuser@EXAMPLE.COM
Valid starting Expires Service principal
04/05/17 11:46:28 04/05/17 21:46:28
krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 04/05/17 23:46:28
04/05/17 11:46:28 04/05/17 21:46:28
host/rhel7.example.com@EXAMPLE.COM
renew until 04/05/17 23:46:28
04/05/17 11:46:28 04/05/17 21:46:28 ldap/dc1.example.com@EXAMPLE.COM
renew until 04/05/17 23:46:28
04/05/17 11:46:28 04/05/17 21:46:28 HTTP/rhel7.example.com@EXAMPLE.COM
renew until 04/05/17 23:46:28

Windows klist:

C:\>klist
Current LogonId is 0:0x816aded2
Cached Tickets: (5)
#0> Client: apacheuser @ EXAMPLE.COM
Server: krbtgt/EXAMPLE.COM @ EXAMPLE.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authent
Start Time: 4/5/2017 9:09:52 (local)
End Time: 4/5/2017 19:09:52 (local)
Renew Time: 4/12/2017 9:09:52 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x2 -> DELEGATION
Kdc Called: dc1.example.com
#1> Client: apacheuser @ EXAMPLE.COM
Server: krbtgt/EXAMPLE.COM @ EXAMPLE.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
Start Time: 4/5/2017 9:09:52 (local)
End Time: 4/5/2017 19:09:52 (local)
Renew Time: 4/12/2017 9:09:52 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: dc1.example.com
#2> Client: apacheuser @ EXAMPLE.COM
Server: HTTP/rhel7.example.com @ EXAMPLE.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
Start Time: 4/5/2017 9:15:36 (local)
End Time: 4/5/2017 19:09:52 (local)
Renew Time: 4/12/2017 9:09:52 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Cache Flags: 0
Kdc Called: dc1.example.com
#3> Client: apacheuser @ EXAMPLE.COM
Server: ldap/DC13.example.com/example.com @ EXAMPLE.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
Start Time: 4/5/2017 9:09:53 (local)
End Time: 4/5/2017 19:09:52 (local)
Renew Time: 4/12/2017 9:09:52 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: dc1.example.com
#4> Client: apacheuser @ EXAMPLE.COM
Server: cifs/DC11 @ EXAMPLE.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
Start Time: 4/5/2017 9:09:52 (local)
End Time: 4/5/2017 19:09:52 (local)
Renew Time: 4/12/2017 9:09:52 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: dc1.example.com

Resolve Common Problems

Authentication problems can be difficult to diagnose. First, check all the configuration parameters, including the validity of the keytab file. Second, review the common problems in the following table.

Problem Solution

The system's clock is out of sync.

The Kerberos standard requires that system clocks be no more than 5 minutes apart. Make sure that the system clocks on the Active Directory domain controller, the Linux or Unix web server, and the client are synchronized.

The user accessing the website is not on the require list.

If the Kerberos ticket was obtained on the client or the user correctly entered his credentials during the Basic Authentication prompt, it might be because authentication worked but the authorization failed. If so, the Apache error_log will contain a line like this:


access to / failed, reason: user EXAMPLE\\user not allowed access

Add the user to the require user directive or add the user’s group to the require group directive.

The user accessing the website is logged on the wrong domain.

If the client user is logged on a domain different from the domain of the web server, one of two things will happen:

  1. If the KrbMethodK5Passwd directive is set to on, or was not specified and thus defaults to on, the user will be prompted for credentials.

  2. If KrbMethodK5Passwd is set to off, authentication will fail and the Authorization Required page will be displayed.

Internet Explorer does not consider the URL to be part of the Local Intranet zone or the Trusted sites.

This problem commonly occurs when the website is accessed by using a URL that includes the full domain name, such as https://myserver.example.com. Internet Explorer tries to obtain Kerberos tickets only for websites that are in the Local Intranet zone.

Try to access the website by using only the server name, for example https://myserver.

Or, you can add the URL to a list of Local Intranet sites or the trusted sites by changing your options in Internet Explorer.

The service principal name of the website is mapped to more than one object in the Active Directory.

Although this problem is rare, it is difficult to diagnose because the error messages are vague. The problem can occur after the ktpass utility was used repeatedly to generate a Kerberos keytab file for the web server.

To check for this problem, log on your Active Directory domain controller and open the Event Viewer. Look for an event of type=Error, source=KDC, and event ID=11. The text of the event will be similar to the message below:

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

To fix the problem, find the computer or user objects that were used to map the service principal name in Active Directory and then use the ADSI Edit to manually remove the HTTP/myserver.example.com string from the servicePrincipalName object property.

Below the table is a screen shot that provides an example of how to find an object named HTTP by using LDAP.

How to find an object named HTTP by using LDAP

 

Resolve Kerberos Library Mismatch

Because some operating systems, such as the 64-bit version of Red Hat Enterprise Linux 5, use an outdated version of /lib/libcom_err.so, the AD Bridge authentication agent cannot the locate the proper system library, leading to an error that looks like this:

httpd: Syntax error on line 202 of /etc/httpd/conf/httpd.conf:Cannot load /opt/pbis/apache/2.2/mod_auth_kerb.so into server:
/opt/pbis/lib/libcom_err.so.3: symbol krb5int_strlcpy, version
krb5support_0_MIT not defined in file libkrb5support.so.0 with link time reference

Solution: Force the httpd daemon to use the AD Bridge krb5 libraries by opening the startup script for the Apache HTTP Server: /etc/init.d/httpd Additionally, add the path to the AD Bridge Kerberos libraries on the line that starts Apache. The line that starts the daemon can vary by operating system. Example on a 64-bit system: LD_LIBRARY_PATH=/opt/pbis/lib64 LANG=$HTTPD_LANG daemon $httpd $OPTIONS

This modification changes the version of the Kerberos libraries that are used by the Apache HTTP Server. The change might result in compatibility issues with other modules of Apache that use Kerberos.