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 achieves this by using one of the authentication methods that do not provide the access policy with 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 web applications. In this scenario, the virtual server attaches a rewrite profile and web application resource.
Here is a typical scenario showing what occurs when Kerberos SSO is used if client certificate authentication is present:
  1. After a delegation account is created, 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 SSOExample 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/apm.example.com.
  2. Click Next.
  3. On the next screen, type in a password and click Finish.
  4. Edit the delegation account by running the dsietdit.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/apm.example.com. 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 Access Policy Manager to support Kerberos SSO

Once you have created a delegation account in Active Directory, you must configure Access Policy Manager to support Kerberos SSO.
  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. From Type, select SSO.
  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. Since Kerberos SSO does not use the user's password, the access policy does not need to have 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. 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.
  7. 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.
  8. In the Account Name field, type the name of the Active Directory account configured for delegation.
  9. 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 and associate the access profile to the 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. Type a unique name for the virtual server.
  4. In 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. Type a port number in the Service Port field, 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 general object attributes apply to 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 hard coded and cannot 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 USource 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 accepted. The variable name is constructed by appending .sso.state to the name specified in Username Source.

Tips for successfully deploying and testing Kerberos SSO

You may run into problems with Kerberos SSO in some instances. Follow these tips to try to resolve any issues you may encounter.

Debugging

Use Microsoft® IIS servers 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.

Testing Kerberos SSO

Use an access policy without a certificate request. It should have a login screen for entering user name only, and does not perform any type of authentication. In the rest of the access policy, use a resource assignment to assign a webtop to access web application(s) or use LTM load balancing pool of servers. Since servers do not allow anonymous access, you will need Kerberos SSO to access them without entering credentials. If the browser prompts for credentials, then you have confirmed that SSO was not configured correctly. At this point, check for errors in the APM log at /var/log/apm.

Using pool of servers

Use a virtual server with a simple round robin LB algorithm. After accessing your virtual server once, wait for ten seconds and refresh. You should see different contents due to different pool members being selected.

Configuring multiple realms scenario

Add a domain entry box to your login screen. This allows you to enter the user's realm on the login screen. The server realm is fixed in SSO configuration which is attached to access profile or web resource. To access servers in multiple realms, create a page on the server in one realm that has a link to a server in another realm, and click that link. SSO matches up with the server to an SSO configuration based on the web application item you have created for that server. Alternatively, you can enter a URL for a server in different realm in the Home Tab popup. Another method is to configure a full webtop with multiple web application resources published on it.

Testing with other access policies

Test further with an access policy that requests client certificates.

Using tcpdump or wireshark

Use these tools to observer Kerberos traffic and HTTP authentication negotiation.

Using tcpdump or wireshark

Use these tools to observer Kerberos traffic and HTTP authentication negotiation.

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 using the command system remote.

DNS and KDS

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. Kerberos SSO plug-in maintains 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 older 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.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)