You can include authentication in the access policy in a Secure Web Gateway (SWG) explicit or transparent forward proxy configuration. However, 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.
To use Kerberos authentication with SWG, if you do not already have Kerberos authentication configured and working with Access Policy Manager®, complete these tasks before you configure access policies for SWG.
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.
The benefits of this feature include:
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.
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 login works
The end-user logon works with events happening in this order:
To configure Kerberos authentication, you must meet specific configuration requirements as described here.
You might choose to verify Kerberos authentication configurations in some instances. Use these troubleshooting tips to help resolve any issues you might encounter.
From the command line, use the klist command as shown in this example.
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 HTTPemail@example.com(arcfour-hmac)
kinit HTTPfirstname.lastname@example.orgYou are prompted for a password and should receive a ticket (no output, no error).
From the command line, type klist . Here is sample output: /etc/krb5.conf
Make sure the client sends the ticket to the BIG-IP® system; this verifies that the client setup is successful.
You should have a domain-joined user account for Kerberos and an AAA Kerberos server configured in Access Policy Manager®.