Troubleshoot Kerberos Authentication on SWA

Introduction

This document describes the basics of Kerberos Authentication and steps to troubleshoot Kerberos Authentication in Secure Web Appliance (SWA).

Terminology

• SWA: Secure Web Appliance
• CLI: Command Line Interface
• AD: Active Directory
• DC: Domain Controller
• SPN: Service Principal Name
• KDC: Kerberos Key Distribution Center
• TGT: Ticket Granting Ticket (Authentication Ticket)
• TGS: Ticket Granting Service
• HA: High Availability
• VRRP: Virtual Router Redundancy Protocol
• CARP: Common Address Redundancy Protocol
• SPN: Service Principal Name
• LDAP: Lightweight Directory Access Protocol

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Authentication and Realms on SWA
• Active Directory and Kerberos Authentication

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Kerberos Network Flow

Image: Sample Kerberos Network Flow

These are the basic steps for authentication in a Kerberized environment:

1. The client requests a TGT from the KDC.

2. The KDC verifies the client machine user credentials and sends back an encrypted TGT and session key.

3. The TGT is encrypted with the TGS secret key.

4. The client stores the TGT and automatically requests a new one when it expires.

For accessing a service or resource:

1. The client sends the TGT to the TGS along with the SPN of the desired resource.
2. The KDC verifies the TGT and checks the user client machine access rights.

3. The TGS sends a service-specific session key to the client.
4. The client provides the session key to the service to prove access, and the service grants access.

Kerberos Authentication Flow in SWA

1. The Client requests access to www.google.com through SWA.

2. SWA responds with an HTTP 407 status, asking for authentication.

3. The Client requests a service ticket from the AD server for HTTP/SWA.domain.com service using the TGT that it gets during domain joining.

4. The AD server validates the Client and issues a service ticket, if successful and the SPN of SWA is found, it proceeds to the next step.

5. The Client sends this ticket to SWA.

6. The SWA decrypts the ticket and checks authentication.

7. If authentication is successful, SWA verifies policies.

8. SWA sends an HTTP 200 OK response to the client if the transaction is allowed.

What is the Purpose of SPN?

An SPN uniquely identifies a service instance in Kerberos authentication. It links a service instance to a service account, allowing clients to request authentication for the service without the account name. Each account in a KDC implementation, such as AD or OpenLDAP, has an SPN. While the SPN strictly identifies a service, it is sometimes mistakenly used to refer to the client name (UPN) in scenarios where the service also acts as a client.

In Kerberos, a SPN uniquely identifies a service instance within a network. It allows clients to request authentication for a specific service. The SPN links the service instance to its account, enabling Kerberos to properly authenticate and authorize access requests to that service.

Active Directory Server Configuration

1. Create a new user account or choose an existing user account to use.

2. Register the SPN to be used against the chosen user account.

3. Ensure no duplicate SPNs are registered.

Tip: How is Kerberos with SWA behind the load balancer or a Traffic Manager/Traffic Shaper different?

• Instead of associating the SPN for HA Virtual hostname with a user account, associate the SPN for the HTTP traffic redirection device (for example, Load Balancer or Traffic Manager) with a user account on the AD.

Best Practices for implementing Kerberos can be found:

• Secure Web Appliance Best Practices 
• Configure Firewall Ports for SWA Connections 

Troubleshooting

Troubleshooting Kerberos with SPN Commands

This is a list of useful setspn commands for managing SPNs in a Kerberos environment. These commands are typically run from a command-line interface with administrative privileges in a Windows environment.

setspn -L <User/ComputerAccountName>

setspn -A <SPN> <User/ComputerAccountName>

setspn -D <SPN> <User/ComputerAccountName>

setspn -Q <SPN>

setspn -L <User/Computer account>

setspn -S <SPN> <User/Coumputer_AccountName>

setspn -R <User/Coumputer_AccountName>

Examples of SPN Commands and Output

Examples provided demonstrate the use:

• User/Computer Account: vrrpserviceuser
• SPN: http/WsaHostname.com or  http/proxyha.localdomain

Check if SPN is already associated with a user account:

setspn -q <SPN>

setspn -q http/proxyha.localdomain

Scenario 1: SPN Not Found.

Scenario 2: SPN Found.

• Associate an SPN with a valid user/computer account:

setspn -s <SPN> <User/computer account>

For example: 

setspn -s http/proxyha.localdomain vrrpserviceuser 

• Delete/Remove an SPN that is already associated with a user or computer account:

setspn -d <SPN> <User/computer account>

For example: 

setspn -d http/proxyha.localdomain pod1234-wsa0

Ensure that there are no duplicate SPNs for the HA virtual hostname, as failures can occur later.

• Command to run:

setspn –x

As a result, the Kerberos Service ticket is not provided to the client, and Kerberos authentication fails.

Caution: If duplicates are found, remove duplicates running the setspn –d command.

• List all SPNs associated with an account:

 setspn –l <User/Computer account>

For example:

setspn –l vrrpserviceuser

Troubleshooting Kerberos on SWA

Information Cisco Support requires when troubleshooting Kerberos authentication problems:

• Current configuration details
• Authentication logs (preferably in debug or trace mode)
• Packet captures taken on (with appropriate filters):
  • Client device
  • SWA
•  Access logs with %m custom format specifier enabled. This must show the authentication mechanism that was used for a specific transaction.
• For detailed authentication details, add these custom fields to the access logs on working/non-working proxies to retrieve additional information or refer to Adding Parameters in Access Logs.
• In the SWA GUI, navigate to System Administration > Log Subscription > Access Logs > Custom Fields > Add this string for authentication issues:

server IP address = %k, Client IP address= %a, Auth-Mech = %m, Auth_Type= %m, Auth_group= %g, Authenticated_Username= %A, Date= %L, Transaction_ID= %I Auth response = %:<a, Auth total = %:>a;

• SWA access log for user authentication details.
• Cisco SWA records authenticated usernames in the format Domain\username@authentication_realm:

• Run Test Authentication Realm Settings from the GUI. Navigate to Network > Authentication, then click on the name of your realm in the Test Current Settings section.
• Click Start Test.

Server Not Found in Kerberos Database

One common error case is web requests failing with “Server not found in Kerberos database”:

curl -vx proxyha.local:3128 --proxy-negotiate -u: http://www.cisco.com/
* About to connect() to proxy proxyha.localdomain port 3128 (#0)
* Connected to proxyha.local (10.8.96.30) port 3128 (#0)
< HTTP/1.1 407 Proxy Authentication Required
< Via: 1.1 pod1234-wsa02.local:80 (Cisco-SWA/10.1.2-003)
< Content-Type: text/html
gss_init_sec_context() failed: : Server not found in Kerberos database
< Proxy-Authenticate: Negotiate
< Connection: close
* HTTP/1.1 proxy connection set close!

In this case, the error indicates that the Service Principal Name corresponding to the proxy address value proxyha.local is not registered on the Active Directory server. To resolve this problem, it is necessary to confirm the SPN http/proxyha.local is registered on AD DC and added to a proper service account.

Related Content

• Configure Secure Web Appliance to Allow Guest Access 
• Configure Active Directory Authentication in SWA 
• Configure Kerberos Single-Sign-On Authentication in SWA 
• Bypass Traffic in Secure Web Appliance