Applies To:Show Versions
- 11.6.5, 11.6.4, 11.6.3, 11.6.2, 11.6.1
About basic authentication and Kerberos end-user logon
Access Policy Manager (APM) provides an alternative to a form-based login authentication method. This alternative method uses a browser login box that is triggered by an HTTP 401 response to collect credentials. A SPNEGO/Kerberos or basic authentication challenge can generate a HTTP 401 response.
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:
- 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 Access Policy Manager.
- Eliminates the need for user password transmission with Kerberos method.
How does end-user logon work?
To retrieve user credentials for end-user logon, you can use basic authentication or SPEGNO/Kerberos methods 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, the system populates the user name and password session variables, which can then be used by any other authentication actions, such as Active Directory or RADIUS.
- Use this method to retrieve user credentials through SPNEGO/Kerberos authentication header.
With the Kerberos method, the client system must first join a domain and a Kerberos action must
follow. The Kerberos action does not run immediately; it runs only when clients request
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. Access Policy Manager ( APM) validates
the request by confirming that a valid ticket is present. Note: You can disable Kerberos per request-based authentication in the 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. In that case, end-user logon does not occur.
Both methods require that an HTTP 401 Response action item be configured in the access policy and that the authentication method be specified in the action item. In cases where both methods are selected, the browser determines which method to perform based on whether the system has joined a domain. The HTTP 401 Response action has two default branches to indicate whether basic authentication or Kerberos method is performed.
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 HTTP request action.
- If Kerberos is present, the browser forwards the Kerberos ticket along with the request when it receives the 401 HTTP request.
- Access Policy Manager 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.
Task summary for configuring end-user login support
To set up this configuration, perform the procedures in the task list.
Joining a Kerberos user account to a domain
- 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
- 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
- On the Main tab, click The Kerberos Servers list screen opens. .
- Click Create. The New Server properties screen opens.
- In the Name field, type a unique name for the authentication server.
- 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.
- In the Service Name field, type a service name; for example, HTTP.
- 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).
- Click Finished. The new server displays on the list.
Creating an access profile
- On the Main tab, click The Access Profiles List screen opens. .
- Click Create. The New Profile screen opens.
In the Name field, type a name for the access
Note: An access profile name must be unique among all access profile and any per-request policy names.
From the Profile Type list, select one:
Note: Depending on licensing, you might not see all of these profile types.Additional settings display.
- LTM-APM - Select for a web access management configuration.
- SSL-VPN - Select to configure network access, portal access, or application access. (Most access policy items are available for this type.)
- ALL - Select to support LTM-APM and SSL-VPN access types.
SSO - Select to configure matching virtual
servers for Single Sign-On (SSO). Note: No access policy is associated with this type of access profile
- RDG-RAP - Select to validate connections to hosts behind APM when APM acts as a gateway for RDP clients.
- SWG - Explicit - Select to configure access using Secure Web Gateway explicit forward proxy.
- SWG - Transparent - Select to configure access using Secure Web Gateway transparent forward proxy.
- System Authentication - Select to configure administrator access to the BIG-IP system (when using APM as a pluggable authentication module).
Identity Service Used internally to provide
identity service for a supported integration. Only APM creates this type of
profile. Note: You can edit Identity Service profile properties.
- In the Language Settings area, add and remove accepted languages, and set the default language. A browser uses the highest priority accepted language. If no browser language matches the accepted languages list, the browser uses the default language.
- Click Finished.
Configuring an access policy for end-user logon support
- On the Main tab, click The Access Profiles List screen opens. .
- In the Access Policy column, click the Edit link for the access profile you want to configure. The visual policy editor opens the access policy in a separate screen.
Click the (+) icon anywhere in the access policy to add
a new action item.
Note: Only an applicable subset of access policy items is available for selection in the visual policy editor for any access profile type.A popup screen opens, listing predefined actions on tabs such as General Purpose, Authentication, and so on.
- Under General Purpose, select HTTP 401 Response, and click Add item. A properties screen opens.
- In the 401 Response Setting area from the HTTP Auth Level list, select basic+negotiate, and click Save. The properties screen closes. The visual policy editor displays the HTTP 401 Response item with 3 branches: Basic, Negotiate, and fallback.
- To perform basic authentication, add an authentication server agent on the Basic branch.
To use the Kerberos authentication method:
- Add the Kerberos Auth agent on the Negotiate branch. After you add the Kerberos Auth item, a properties popup screen displays.
- On the properties screen for the AAA Server setting, select the Kerberos AAA server.
- Click Save. The properties screen closes and the visual policy editor is displayed.
Complete the access policy:
- Add any additional access policy items you require.
- Change the ending from Deny to Allow on any access policy branch on which you want to grant access.
- Click Apply Access Policy.
Access policy example for end-user login
This is an example of an access policy with all the associated elements needed to successfully support the end-user login feature. Notice that separate branches are created automatically to support using either basic authentication or Kerberos method to retrieve user credentials.
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.
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 HTTPfirstname.lastname@example.org(arcfour-hmac)
Verify Kerberos delegation
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.