Manual Chapter : Kerberos Authentication for SWG Forward Proxy

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 12.0.0
Manual Chapter

Kerberos Authentication for SWG Forward Proxy

Overview: Authenticating SWG users with Kerberos

You can include authentication in the access policy in a Secure Web Gateway (SWG) explicit or transparent forward proxy configuration. When you do so if the first site that a user accesses uses HTTP instead of secure HTTP, passwords are passed as clear text. To prevent this from happening, F5® recommends using Kerberos or NTLM authentication.

Kerberos authentication relies on these access policy actions:

  • HTTP 407 response and Kerberos authentication for SWG explicit forward proxy
  • HTTP 401 response and Kerberos authentication for SWG transparent forward proxy

These access policy items require an AAA Kerberos server object configured in Access Policy Manager®.

Kerberos authentication also requires a domain-joined, Windows-based user account.

This implementation includes steps for configuring and troubleshooting Kerberos authentication, so that you have what you need in place and working before you configure SWG access policies.

Task summary

About basic authentication and Kerberos end-user logon

Access Policy Manager® (APM®) provides an alternative to the form-based login authentication method. Instead, an HTTP 401 (unauthorized) or HTTP 407 (proxy authentication required) response triggers a browser login screen to collect credentials.

This option is useful when a user is already logged in to the local domain and you want to avoid submitting an APM HTTP form for collecting user credentials. The browser automatically submits credentials to the server and bypasses the login box to collect the credentials again.

Note: Because SPNEGO/Kerberos is a request-based authentication feature, the authentication process is different from other authentication methods, which run at session creation time. SPNEGO/Kerberos authentication can occur at any time during the session.

The benefits of this feature include:

  • Provides flexible login mechanism instead of restricting you to use only the form-based login method.
  • Eliminates the need for domain users to explicitly type login information again to log in to APM.
  • Eliminates the need for user password transmission with Kerberos method.
Important: Administrators should not turn off the KeepAlive setting on the web server because turning that setting off might interfere with Kerberos authentication.

How does end-user logon work?

To retrieve user credentials for end-user logon, you can use the basic authentication method, or the SPNEGO/Kerberos method (which is recommended), or both.

Basic authentication
Use this method to retrieve user credentials (user name and password) from a browser. You can think of this method as a replacement for form-based authentication used by the standard login screen. If you use basic authentication, Access Policy Manager® (APM®) populates the user name and password session variables, which can then be used by any other authentication actions, such as Active Directory or RADIUS.
Note: When using basic authentication, passwords are passed as clear text.
SPNEGO/Kerberos
Use this method to retrieve user credentials through the SPNEGO/Kerberos authentication header. With the Kerberos method, the client system must first join a domain. A Kerberos action does not run immediately; it runs only when the server requests SPNEGO/Kerberos authentication. By default, Kerberos authentication runs not only on the first request, but also on subsequent requests where authentication is needed, such as for new connections. APM validates the request by confirming that a valid ticket is present.
Note: You can disable Kerberos per request-based authentication in the AAA Kerberos authentication access policy item configuration in APM. If you disable it, authentication occurs while the access policy runs and subsequent authentications do not occur.

Both methods require that either an HTTP 401 Response (unauthorized) or an HTTP 407 Response (proxy authentication required) action item be configured in the access policy, and that the authentication method (basic, negotiate, or basic + negotiate) be specified in the action item.

In cases where both methods (basic + negotiate) are selected, the browser determines which method to perform based on whether the system has joined a domain. The HTTP 401 Response and HTTP 407 Response actions each have two default branches to indicate whether basic authentication or Kerberos method is performed.

How SPNEGO/Kerberos end-user logon works

How SPNEGO/Kerberos end-user login works

The end-user logon works with events happening in this order:

  • The client becomes a member and connects to the domain.
  • The client connects to a virtual server on the BIG-IP® system.
  • The access policy runs and issues a 401 or 407 HTTP response.
  • If a Kerberos ticket is present or can be obtained, the browser forwards the Kerberos ticket along with the request when it receives the 401 or 407 response.
  • APM validates the Kerberos ticket after the request is received, and determines whether or not to permit the request.

About Kerberos authentication requirements

To configure Kerberos authentication, you must meet specific configuration requirements as described here.

Virtual server
The virtual server IP address and host name are necessary to configure DNS.
DNS configuration
Make sure you have the zone file and PTR record for the virtual server IP address. For example:
testbed.lab.companynet 10.10.4.100
Browser configuration
Configure the browser to use Kerberos. Typically, Internet Explorer is already configured for Kerberos; however, you might need to configure it for trusted sites. To use Firefox, you must configure it for negotiate authentication.

Joining a Kerberos user account to a domain

To use Kerberos authentication, you need the client joined and connected to a domain and you need a keytab file.
  1. Create a surrogate user in the domain.
    In this example, the hostname of the virtual server on the BIG-IP® system is testbed.lab.companynet and the user name is john.
    setspn -U -A HTTP/testbed.lab.companynet john
  2. Map the user account to the service account and generate a keytab file for the service.
    You can use the ktpass utility to do this. In this example, LAB.COMPANYNET specifies the Kerberos authentication realm.
    c:>ktpass -princ HTTP/testbed.lab.companynet.com@LAB.COMPANYNET -mapuser john@LAB.COMPANYNET -crypto rc4-hmac-nt -ptype KRB5_NT_SRV_HST -pass password -out c:\temp\john.keytab

Configuring an AAA server for Kerberos authentication

Configure a Kerberos AAA server so that you can add it to a Kerberos authentication action in an access policy.
  1. On the Main tab, click Access Policy > AAA Servers > Kerberos .
    The Kerberos Servers list screen opens.
  2. Click Create.
    The New Server properties screen opens.
  3. In the Name field, type a unique name for the authentication server.
  4. In the Auth Realm field, type a Kerberos authentication realm name (administrative name), such as LAB.COMANYNET.
    Type the realm name all uppercase; it is case-sensitive.
  5. In the Service Name field, type a service name; for example, HTTP.
  6. In the Keytab File area, click Choose File to locate and upload the keytab file.
    A keytab file contains Kerberos encryption keys (these are derived from the Kerberos password).
  7. Click Finished.
    The new server displays on the list.

Kerberos authentication troubleshooting tips

You might choose to verify Kerberos authentication configurations in some instances. Use these troubleshooting tips to help resolve any issues you might encounter.

Verify the keytab file

From the command line, use the klist command as shown in this example.

Important: The command must be typed on one line.
klist -ke WRFILE:/config/filestore/files_d/Common_d/kerberos_keytab_file_d/\:Common\:SUN-SPNEGO-APM106_key_file_2

The output for the example contains information like this.

                        
Keytab name:
FILE:/config/filestore/files_d/Common_d/kerberos_keytab_file_d/:Common:SUN-SPNEGO-APM106_key_file_2
KVNO Principal
3    HTTP/apm106.labt.companynet.com@labt.companynet.com(arcfour-hmac)
                     

Verify Kerberos delegation

From the command line, use the kinit command, as shown in this example.
kinit HTTP/apm106.labt.companynet.com@labt.companynet.com
You are prompted for a password and should receive a ticket (no output, no error).

Verify ticket

From the command line, type klist . Here is sample output: /etc/krb5.conf

Capture a TCP dump

Make sure the client sends the ticket to the BIG-IP® system; this verifies that the client setup is successful.

Implementation result

You should have a domain-joined user account for Kerberos and an AAA Kerberos server configured in Access Policy Manager®.