Applies To:

Show Versions Show Versions

Manual Chapter: Kerberos Single Sign-On Method
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

About Kerberos SSO

Access Policy Manager® provides seamless authentication to application servers (web servers) using Kerberos SSO. It is the only SSO method that can be used when authentication methods used by the access policy do not provide the user's password in clear text. Examples of such methods include client certificate authentication, NTLM authentication, or any other challenge/response authentication method where the password is not transmitted in clear text. To use Kerberos SSO, you must have Kerberos implemented in your environment, such as using Active Directory domain with IIS servers configured for Integrated Windows authentication.

How does Kerberos SSO work in Access Policy Manager?

You can leverage Kerberos SSO in the following ways:

  • Using a virtual server with an access policy associated with it.
  • Handling the SSO event through the use of Portal Access Resource. In this scenario, the Portal Access resource is assigned to the Access Policy and the virtual server attaches a rewrite profile.

Here is a typical scenario showing what occurs when Kerberos SSO is used if client certificate authentication is present:

  1. When a user connects to the virtual server, Access Policy Manager validates the credentials and extracts the UPN from the certificate through the access policy.
  2. When the client accesses an application that requires a Kerberos ticket, the UPN and the configured Kerberos SSO object are used to retrieve the ticket from Active Directory. The ticket is then cached for the particular client and presented to the application for access.
Attention: Under other circumstances, the access policy may not ask for credentials within the certificate, because, for example, a logon page may be present. In such a case, the user name supplied by the client is used at the UPN. Other factors, such as the use of other types of authentication methods, must be present in order to ensure that the credentials are valid in order to retrieve the Kerberos ticket.
Example access policy for Kerberos SSO Example access policy for Kerberos SSO

Task summary for configuring Kerberos SSO

Access Policy Manager lets you configure for Kerberos SSO.

To set up this configuration, follow the procedures in the task list.

Task List

Setting up a delegation account to support Kerberos SSO

To use Kerberos SSO, you must create an account in Active Directory before you can configure Kerberos SSO. Note that for every server realm, you must create a delegation account in that realm.
  1. Open the Active Directory Users and Computers administrative tool and create a new user account. The account name must be in this format, host/name.domain, where host is a literal string, name is any arbitrary name, and domain is the DNS FQDN for that realm. Here is an example, host/
  2. Click Next.
  3. On the next screen, type in a password and click Finish.
  4. Edit the delegation account by running the adsietdit.msc administrative tool. To run this tool, type in the name of the tool at the Run command.
  5. Navigate to the domain user accounts, and locate the delegation account you created.
  6. Right-click the account and select Properties. The Active Directory properties for this account display.
  7. Locate servicePrincipalName and select it.
  8. Click Edit and type in the SPN value. This value should be identical to what you provided in the user account field. For example, host/ Click OK.
  9. Return to the Active Directory Users and Computers screen to open your account again. This time, there should be a Delegation tab present.
  10. Select Trust this user for delegation to specified services only.
  11. Select Use any authentication protocol, and add all your services to the list under Services to which this account can present delegated credentials. Every service should have Service Type HTTP (or http) and host name of the pool member or web application resource host that you will use in your configuration.
  12. Click OK. This creates the new delegation account.
You must now configure Access Policy Manager to support Kerberos SSO.

Configuring SSO with Kerberos authentication method

After you create a delegation account in Active Directory, you must configure Access Policy Manager to support Kerberos SSO.
  1. On the Main tab, click Access Policy > SSO Configurations The SSO Config List opens.
  2. Click the Createbutton. The New SSO Configuration screen opens.
  3. Enter the name of your Kerberos SSO configuration.
  4. For SSO Method, select Kerberos.
  5. For Username Source, set the source to a session variable containing the user name, for example session.logon.last.username. Because Kerberos SSO does not use the user's password, the access policy does not need to include the SSO Credentials Mapping agent. When using client certificate authentication, the user name must be extracted from the certificate and placed into a session variable, which can be done with a Variable Assign agent.
  6. For User Realm Source, set the source to a session variable containing the user's Kerberos realm, for example session.logon.last.domain. If this field is left empty or the variable does not exist or has no value, the user is assumed to be in the same Kerberos realm as the server.
  7. In the Kerberos Realm field, type the name of your realm, for example, POSE.LAB.FP.EXAMPLE.COM. This must be set to the realm of the application server(s). For example, pool members or web application resource hosts. The name of your realm must all be in upper-case letters.
  8. In the KDC field, type in either an IP address or the host name of the KDC for the server's realm. This is normally an Active Directory domain controller. If you leave this field empty, the KDC must be discoverable through DNS. If the domain name is different from the realm name, it must be specified in the /etc/krb5.conf file. Otherwise, adding realm configuration to that file is not required. Kerberos SSO processing expedites quicker when KDC is specified by its IP address, slower if by host name, and even slower if you leave it empty. If the user's realm is different from the server's realm, KDC must be left empty.
  9. In the Account Name field, type the name of the Active Directory account configured for delegation.
  10. In the Account Password field, type a password for the delegation account, and then confirm the password.
You must now create an access policy to support Kerberos SSO.

Editing an access policy to support Kerberos SSO

Once you create an access profile to support Kerberos SSO, you must edit the policy and add the appropriate agents.
  1. On the Main tab, click Access Policy > Access Profiles . The Access Profiles List screen opens.
  2. From the list, select an access profile to which you want to add Kerberos SSO support. The properties screen for that access profile opens.
  3. Click Edit Access Policy for Profile profile_name. The visual policy editor opens the access policy in a separate window or tab.
  4. On an access policy branch, click the plus symbol (+) to add an item to the access policy.
  5. For Predefined Actions, under Authentication select Client Cert Inspection, and click Add item.
  6. Under General Purpose, select Variable Assign and click Add item.
You have created an access policy to support Kerberos SSO.
The next step is to bind the SSO object to the access profile.

Binding a Kerberos SSO object to an access profile

Before beginning this task, configure an SSO object with Kerberos authentication or ensure that such an SSO object exists.
To bind a Kerberos SSO object to an access profile, add an SSO configuration (Kerberos SSO object ) to it.
  1. On the Main tab, click Access Policy > Access Profiles . The Access Profiles List screen opens.
  2. From the list, select an access profile to which you want to add Kerberos SSO support. The properties screen for that access profile opens.
  3. Click the SSO Auth/Domains tab.
  4. For SSO Configuration, select an SSO configuration with Kerberos authentication that you previously identified or configured.
  5. Click Update.
The next step is to associate the access profile with a virtual server.

Attaching an access profile to a virtual server for Kerberos SSO

  1. On the Main tab, click Local Traffic > Virtual Servers . The Virtual Server List screen displays a list of existing virtual servers.
  2. Click the Create button. The New Virtual Server screen opens.
  3. In the Name field, type a unique name for the virtual server.
  4. For the Destination setting, in the Address field, type the IP address you want to use for the virtual server. The IP address you type must be available and not in the loopback network.
  5. In the Service Port field, type a port number or select a service name from the Service Port list.
  6. Under In the Access Policy area, from the Access Profile list. select the access profile that you configured for Kerberos SSO.
  7. Click Finished.

Kerberos SSO session variable list

The following session variables are used by Kerberos SSO.

Session Variable name Description
session.logon.last.domain Contains the user's Kerberos realm. If unset, the user's realm is the same as the server's realm. The variable name is specified as User Realm Source in the SSO configuration and can be changed.
session.logon.last.username Contains the user's login name. This can be extracted from the client certificate or supplied by the user on the login screen. The variable name is specified as UsernameSource in the SSO configuration and can be changed.
session.logon.last.username.sso.state This is set to 1 internally when Kerberos SSO fails. When this variable is set, all subsequent requests are passed to the application server without applying SSO for the remainder of the user session. The variable name is constructed by appending .sso.state to the name specified in Username Source.

Tips for successfully deploying Kerberos SSO

If you run into problems with Kerberos SSO, follow these tips to try to resolve issues.

Microsoft® IIS servers

Only Microsoft® IIS servers are supported for your pool members or web application resources. First, make sure the server computers running IIS are members of your AD Domain. Then follow these steps to enable Kerberos in IIS Manager:

  1. From Active Directory administrative tool, right-click Web Sites and select Properties.
  2. Select the Directory Security tab and in the Authentication and Access Control area click Edit.
  3. Clear Enable Anonymous Access.
  4. Check Integrated Windows Authentication and click OK. You may need to restart IIS or reboot the server for this to take effect.

Reverse DNS resolution

Kerberos SSO relies on reverse DNS resolution for determining SPN (Service Principal Name) for each server host, such as load balanced pool member or web application resource host. Your Access Policy Manager should be configured to use DNS server(s) that have the appropriate forward and reverse DNS records for those servers. If DNS is lacking, those record host entries can be configured on the BIG-IP system.


Kerberos SSO relies on DNS for KDC discovery when KDC is not specified in an SSO configuration. The DNS server should have SRV records pointing to the KDC servers for the realm's domain. When DNS is not properly configured, or if the realm's DNS domain name is different from the realm's name, you can specify the KDC by adding a realm section to /etc/krb5.conf file on the BIG-IP system. For DNS discovery to work, the dns_lookup_kdc option in the [libdefaults] section of that file must be set to true.

Credential Caching

Kerberos uses credential caching to store Kerberos tickets. Access Policy Manager uses the websso process to maintain credential caches in memory, so restarting the websso process will discard all Kerberos tickets used for SSO.

Credential caching and high availability

The Ticket cache is not synchronized between units in high availability. Each user's Kerberos tickets are stored in a separate cache, where the name is constructed from the username, the user Kerberos realm, and the server Kerberos realm. Each cache contains a copy of the delegation account TGT for the server realm, a S4U2Self ticket for the user for the server realm, and multiple S4U2Proxy tickets for the servers. Once all tickets are fetched and stored in the cache, they remain there until they expire according to their lifetime. Processing of subsequent SSO requests should not require any more queries to the KDC. Since all tickets obtained from the same TGT have that TGT's lifetime, all tickets in the cache expire simultaneously. Each user's cache exists independently from the user's session. If the user has multiple concurrent or sequential sessions, the sessions all share the same cache, as long as it remains valid. The cache continues to exist even without any active sessions.

Maximum number of cache entries

The maximum number of cache entries is set to 20000. If the number is exceeded, it destroys older entries using the LRU algorithm. Delegation account TGT for each server realm is fetched when the first user request for that realm is processed. The TGT is cached and copied into every user's cache when the user accesses servers in that realm. If the TGT remaining lifetime becomes more than one hour shorter than the configured lifetime, the TGT is re-fetched. This is done to ensure that the new user's tickets are fetched with the initial lifetime closer to the configured value, and to avoid all tickets expiring at the same time, causing a performance impact.

Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?

NOTE: Please do not provide personal information.

Additional Comments (optional)