Contents

Introduction

Terminology

Knowledge and Requirements

Kerberos Network Flow

Kerberos Authentication Flow in WSA

What is the Purpose of SPN?

Active Directory Server Configuration

Troubleshooting Kerberos with SPN Commands

Examples of SPN Commands and Output

Scenario 1: SPN Not Found

Scenario 2: SPN Found

Troubleshooting Kerberos on WSA

Additional Information and References

Introduction

This document describes Kerberos Protocol using tickets to securely verify identities in websites and Single Sign-On systems.

Terminology

WSA

Web Security Appliance

CLI

Command Line Interface

AD

Active Directory

SPN

Service Principal Name

KDC

Kerberos Key Distribution Center

TGT

Authentication Ticket

TGS

Ticket Granting Service

HA

High Availability

VRRP

Virtual Router Redundancy Protocol

CARP

Common Address Redundancy Protocol

Knowledge and Requirements

- Active Directory and Authentication.

- Authentication and realms on WSA

Kerberos Network Flow

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

1. The client requests a Ticket Granting Ticket (TGT) from the Key Distribution Center (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 Ticket Granting Service (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 Service Principal Name (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 WSA

1. The Client requests access to www.google.com through the WSA.

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

3. The Client requests a service ticket from the AD server for HTTP/wsa.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 (Service Principal Name) of WSA is found, it proceeds to the next step.

5. The Client sends this ticket to the WSA.

6. The WSA decrypts the ticket and checks authentication.

7. If authentication is successful, the WSA verifies policies.

8. The WSA sends an HTTP 200 OK response to the Client if transaction is allowed.

What is the Purpose of SPN?

A Service Principal Name (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 needing the account name. Each account in a Key Distribution Center (KDC) implementation, Such as AD or Open LDAP, 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 Service Principal Name (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

- Create a new user account or choose an existing user account to use

- Register the SPN to be used against the chosen user account

- Ensure no duplicate SPN’s are registered

Tip: How is Kerberos with WSA’s behind 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:LoadBalancer or Traffic Manager) with a user account on the AD.

Troubleshooting Kerberos with SPN Commands

Here is a list of useful `setspn` commands for managing Service Principal Names (SPNs) in a Kerberos environment These commands are typically run from a command-line interface with administrative privileges in a Windows environment.

List SPNs for a specific account:

setspn -L <User/ComputerAccountName>

Lists all SPNs registered for the specified account.

Add an SPN to an account:

setspn -A <SPN> <User/ComputerAccountName>

Adds the specified SPN to the given account.

Delete an SPN from an account:

setspn -D <SPN> <User/ComputerAccountName>

Removes the specified SPN from the given account.

Verify if an SPN is already registered:

setspn -Q <SPN>

Checks if the specified SPN is already registered in the domain.

List all SPNs in the domain

setspn -L <User/Computer account>

Lists all SPNs in the domain.

Set an SPN for a computer account:

setspn -S <SPN> <User/CoumputerAccountName>

Adds an SPN to a computer account, ensuring no duplicate entries.

Reset SPNs for a specific account:

setspn -R <User/CoumputerAccountName>

Resets the SPNs for the specified account, helping to resolve duplicate SPN issues.

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:

Syntax: 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/computer account:

Syntax: 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 use: setspn –x

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

Caution: If duplicates are found, please remove duplicates using setspn –d command

- List all SPNs associated with an account:

Syntax: setspn –l <User/Computer account>

For example : setspn –l vrrpserviceuser

Troubleshooting Kerberos on WSA

Information TAC needs to get when troubleshooting kerberos authentication problems

- Current configuration details

- Authentication logs (Preferably in debug or trace mode)

- Packet captures taken on (with appropriate filters):

(a) Client device

(b) WSA

- Access logs with %m custom format specifier enabled. This must show the authentication mechanism that was used for a specific transaction.

Tip: For detailed authentication details, add these custom fields to the access logs on working/non-working proxies to get more information

On WSA 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;

WSA access log snapshot for user authentication details

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

curl -vx proxyha.localdomain:3128 --proxy-negotiate -u: http://www.google.com/

* About to connect() to proxy proxyha.localdomain port 3128 (#0)

* Connected to proxyha.localdomain (10.8.96.30) port 3128 (#0)

< HTTP/1.1 407 Proxy Authentication Required

< Via: 1.1 pod1234-wsa02.localdomain:80 (Cisco-WSA/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 proxy address value proxyha.localdomain is not registered on Active Directory server. To resolve the problem, it would be necessary to confirm that SPN http/proxyha.localdomain is registered on AD DC and added to a proper service account.

- Best Practices for implementing kerberos is documented in this hyperlink:

Secure Web Appliance Best Practices

Additional Information and References