Manual Chapter :
Kerberos Authentication with End-User Logons
Applies To:
Show VersionsBIG-IP APM
- 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
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.
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.
- Create a surrogate user in the domain.In this example, the hostname of the virtual server on the BIG-IP system istestbed.lab.companynet.comand the user name isjohn.setspn -U -A HTTP/testbed.lab.companynet.com 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.COMspecifies 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.
- On the Main tab, click.The Kerberos Servers list screen opens.
- ClickCreate.The New Server properties screen opens.
- In theNamefield, type a unique name for the authentication server.
- In theSPN Formatarea, select service principle name (SPN) format for the Kerberos AAA server.
- SelectHost-based serviceto display the authorization realm, service name, and keytab file options. All existing Kerberos AAA servers are host-based services by default.
- SelectKerberos 5 NT Principalto display the service principal name and keytab file options. Use this format for VMware View clients.
- In theAuth Realmfield, type a Kerberos authentication realm name (administrative name), such asLAB.COMANYNET.Type the realm name all uppercase; it is case-sensitive.
- In theService Namefield, type a service name; for example,HTTP.
- In theKeytab Filearea, locate and upload the keytab file.A keytab file contains Kerberos encryption keys (these are derived from the Kerberos password).
- ClickFinished.The new server displays on the list.
Create an access profile
You create an access profile to provide the access policy configuration for a
virtual server that establishes a secured session.
- On the Main tab, click.The Access Profiles (Per-Session Policies) screen opens.
- ClickCreate.The New Profile screen opens.
- In theNamefield, type a unique name for the access profile.
- From theProfile Typelist, 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. - From theProfile Scopelist, 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.
- For theCustomization Type, use the default valueModern.
- In the Language Settings area, add and remove accepted languages, and set the default language.If no browser language matches one in the accepted languages list, the browser uses the default language.
- ClickFinished.
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
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. - On the Main tab, click.The Access Profiles (Per-Session Policies) screen opens.
- Click the name of the access profile that you want to edit.The properties screen opens.
- On the menu bar, clickLogs.The access profile log settings display.
- Move log settings between theAvailableandSelectedlists.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 theSelectedlist is empty.
- ClickUpdate.
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.
- On the Main tab, click.The Access Profiles (Per-Session Policies) screen opens.
- In the Per-Session Policy column, click theEditlink 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 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.
- Under General Purpose, selectHTTP 401 Response, and clickAdd item.A properties screen opens.
- In the 401 Response Setting area from theHTTP Auth Levellist, selectbasic+negotiate, and clickSave.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 theBasicbranch.
- To use the Kerberos authentication method:
- Add theKerberos Authagent on theNegotiatebranch.After you add the Kerberos Auth item, a properties popup screen displays.
- On the properties screen for theAAA Serversetting, select the Kerberos AAA server.
- ClickSave.The properties screen closes and the policy displays.
- Complete the policy:
- Add any additional policy items you require.
- Change the ending fromDenytoAllowon any access policy branch on which you want to grant access.
- ClickApply 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.