F5 Logo MyF5
Search
  1. MyF5 Home
  2. BIG-IP Access Policy Manager: Authentication Methods
  3. Kerberos Authentication with End-User Logons
Manual Chapter : Kerberos Authentication with End-User Logons

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 17.1.2, 17.1.1, 17.1.0
Manual Chapter

Kerberos Authentication with End-User Logons

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.
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 Access Policy Manager.
  • Eliminates the need for user password transmission with Kerberos method.
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 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.
SPNEGO/Kerberos
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.
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.
You can achieve multi-domain support for Kerberos authentication through multiple virtual servers. Each virtual server must have its own access policy and its own Kerberos configuration.
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.
How SPNEGO/Kerberos end-user logon works
How SPNEGO/Kerberos end-user logon 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 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

To use Kerberos authentication, you need to join and connect the client to a domain, and you also 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.com
     and the user name is
    john
    .
    setspn -U -A HTTP/testbed.lab.companynet.com 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.COM
     specifies the Kerberos authentication realm, which is case-sensitive and must be specified in uppercase. The user name, which is specified in UPN format (
    john@lab.companynet.com
    ), is not case-sensitive. (The user name can be specified in user name format, DN format, or UPN format).
    c:>ktpass -princ HTTP/testbed.lab.companynet.com@LAB.COMPANYNET.COM -mapuser john@lab.companynet.com -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 use it for a Kerberos authentication action in an access policy.
  1. On the Main tab, click
    Access
    Authentication
    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
    SPN Format
     area, select service principle name (SPN) format for the Kerberos AAA server.
    • Select
      Host-based service
       to display the authorization realm, service name, and keytab file options. All existing Kerberos AAA servers are host-based services by default.
    • Select
      Kerberos 5 NT Principal
       to display the service principal name and keytab file options. Use this format for VMware View clients.
  5. 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.
  6. In the
    Service Name
     field, type a service name; for example,
    HTTP
    .
  7. In the
    Keytab File
     area, locate and upload the keytab file.
    A keytab file contains Kerberos encryption keys (these are derived from the Kerberos password).
  8. Click
    Finished
    .
    The new server displays on the list.

Creating a Kerberos Auth configuration

Before you start, configure a Kerberos Auth configuration to specify the Kerberos authentication used to verify the identity of a client with the Key Distribution Center (KDC). When the client requests access to a resource, using the ticket-based authentication system, the KDC verifies the client identity with the given login credentials. After the client identity is verified, the KDC creates an encrypted ticket-granting ticket (TGT) or session key and sends it back to the client. The client stores the ticket and can use it to access the server resources for a specific time.
The Kerberos Auth Configuration objects created are specified in the access profile to use Kerberos Authentication as a part of Integrated Authentication.
  1. On the Main tab, click
    Access
    Authentication
    Kerberos
    Kerberos Auth Configuration
    .
    A new Kerberos Auth Configuration screen displays.
  2. In the
    Name
     field, type a name for the configuration.
  3. From the
    AAA Server
     list, select the applicable AAA server configuration for the Kerberos Auth configuration.
    You can assign the same AAA server to multiple Kerberos authentication configurations.
  4. From the
    Max Logon Attempt Allowed
    , select the number of user authentication logon attempts to allow from 1 to 5 in the list. Default number of logon attempts allowed are 3. A complete logon, password challenge, and response is considered as one attempt.
  5. From the
    Extract Group SIDs
    , select the required option whether to allow the APM Kerberos Authentication module to extract user group membership SIDs from the Kerberos Ticket Granting Ticket (TGT). A Security Identifier (SID) is a unique value of variable length used to identify a user or group. Default is Enabled.
    • Select
      Enabled
       to allow the Kerberos authentication module to extract the user group membership SIDs from the Kerberos TGT and save the SIDs in a session variable.
    • Select
      Disabled
       to deny extracting group SIDs.
  6. In the
    Session Variable for Group SIDs
     field, enter the custom variable name for the session variable used to store extracted Group SIDs. Default value is session.kerberos.last.groupsids.
  7. Click
    Finished
    . A Kerberos Auth Configuration object is created.

Create an access profile

You create an access profile to provide the access policy configuration for a virtual server that establishes a secured session.
  1. On the Main tab, click
    Access
    Profiles / Policies
    Access Profiles (Per-Session Policies)
    .
    The Access Profiles (Per-Session Policies) screen displays.
  2. Click
    Create
    .
    The New Profile screen displays.
  3. In the
    Name
     field, type a unique name for the access profile.
  4. From the
    Profile Type
     list, select one these options:
    • ALL
      : Select to support LTM-APM and SSL-VPN access types.
    • LTM-APM
      : Select for a web access management configuration.
    • OAuth-Resource Server
      : For configuring APM to act as an OAuth resource server that provides an OAuth authorization layer into an API gateway.
    • RDG-RAP
      : Select to validate connections to hosts behind APM when APM acts as a gateway for RDP clients.
    • SSL-VPN
      : Select to configure network access, portal access, or application access. (Most access policy items are available for this type.)
    • SSO
      : Select to configure matching virtual servers for Single Sign-On (SSO).
      No access policy is associated with this type of access profile
    • SWG - Transparent
      : Select to configure access using Secure Web Gateway transparent forward proxy.
    • SWG - Explicit
      : Select to configure access using Secure Web Gateway explicit 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.
      You can edit Identity Service profile properties.
    Depending on licensing, you might not see all of these profile types.
    Additional settings display.
  5. From the
    Profile Scope
     list, select one these options to define user scope:
    • Profile
      : Access to resources behind the profile.
    • Virtual Server
      : Access to resources behind the virtual server.
    • Global
      : Access to resources behind any access profile with global scope.
    • Named
      : Access for SSL Orchestrator users to resources behind any access profile with global scope.
    • Public
      : Access to resources that are behind the same access profile when the Named scope has configured the session and is checked based on the value and string configured in the Named scope field.
  6. For the
    Customization Type
    , use the default value
    Modern
    .
  7. In the Language Settings area, add and remove accepted languages, and set the default language.
    If any browser language does not match with the accepted languages list, the browser uses the default language.
  8. Click
    Finished
    .
The access profile displays in the Access Profiles List. Default-log-setting is assigned to the access profile.

Verify log settings for the access profile

Confirm that the correct log settings are selected for the access profile to ensure that events are logged as you intend.
Log settings are configured in the
Access
Overview
Event Log
Settings
area of the product. They enable and disable logging for access system and URL request filtering events. Log settings also specify log publishers that send log messages to specified destinations.
  1. On the Main tab, click
    Access
    Profiles / Policies
    Access Profiles (Per-Session Policies)
    .
    The Access Profiles (Per-Session Policies) screen displays.
  2. Click the name of the access profile that you want to edit.
    The properties screen opens.
  3. On the menu bar, click
    Logs
    .
    The access profile log settings display.
  4. Move log settings between the
    Available
     and
    Selected
     lists.
    You can assign up to three log settings that enable access system logging to an access profile. You can assign additional log settings to an access profile provided that they enable logging for URl request logging only.
    Logging is disabled when the
    Selected
     list is empty.
  5. Click
    Update
    .
An access profile is in effect when it is assigned to a virtual server.

Configuring an access policy for end-user logon support

To use basic authentication in addition to Kerberos authentication, you need an AAA server configured for the authentication agent that you plan to use.
Configure an access policy like this one to handle basic and SPEGNO/Kerberos authentication challenges without submitting an Access Policy Manager HTTP form to collect user credentials.
  1. On the Main tab, click
    Access
    Profiles / Policies
    Access Profiles (Per-Session Policies)
    .
    The Access Profiles (Per-Session Policies) screen displays.
  2. In the Per-Session 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.
  3. Click the
    (+)
     icon anywhere in the access policy to add a new item.
    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.
  4. Under General Purpose, select
    HTTP 401 Response
    , and click
    Add item
    .
    A properties screen opens.
  5. 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.
  6. To perform basic authentication, add an authentication server agent on the
    Basic
     branch.
  7. To use the Kerberos authentication method:
    1. Add the
      Kerberos Auth
       agent on the
      Negotiate
       branch.
      After you add the Kerberos Auth item, a properties popup screen displays.
    2. On the properties screen for the
      AAA Server
       setting, select the Kerberos AAA server.
    3. Click
      Save
      .
      The properties screen closes and the policy displays.
  8. Complete the policy:
    1. Add any additional policy items you require.
    2. Change the ending from
      Deny
       to
      Allow
       on any access policy branch on which you want to grant access.
  9. Click
    Apply Access Policy
    .
To apply this access policy to network traffic, add the access profile to a virtual server.
To ensure that logging is configured to meet your requirements, verify the log settings for the access profile.

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.
For basic authentication, the user name and password validation occurs at the session creation time. After the access policy completes, the session cookie is used to validate the session.
By default, Kerberos runs not only at the access policy run time but also at any time in the session.
Example access policy for end-user login
401 Response followed by AD auth (basic) and Kerberos auth (negotiate)
Example properties for an HTTP 401 response action
Example of branch rule for HTTP 401 Response
Example properties for a Kerberos Auth action on the Negotiate branch
Example of branch rule for Kerberos
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information