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.
You can leverage Kerberos SSO in the following ways:
Here is a typical scenario showing what occurs when Kerberos SSO is used if client certificate authentication is present:
To set up this configuration, follow the procedures in the task list.
These settings are available when you configure a Kerberos SSO method.
|General Properties||Basic or Advanced. Defaults to Basic.||Additional settings are available when you select Advanced.|
|Name||Name of the SSO configuration.||The name must begin with a letter, or underscore, and contain only letters, numbers, underscores, dashes, and periods. Avoid using global reserved words in the name, such as all, delete, disable, enable, help, list, none, show, or None.|
|Headers||Header name-value pairs to send with the SSO method.||Displayed when you select Advanced in the General Properties list.|
|Username Source||Specifies the user name to cache for single sign-on. Defaults to a session variable.||Supported session variable: session.sso.token.last.username|
|User Realm Source||Displays the session variable, if configured, that specifies the realm for the user. If the variable is set, it must contain the Kerberos realm for the user.||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.
Supported session variable: session.logon.last.domain
|Kerberos Realm||Specifies the realm of application servers, such as pool members or portal access resource hosts.||If servers are located in multiple realms, you must create a separate SSO
configuration for each realm. Realm must be specified in uppercase letters or can be
specified using the session.logon.last.domain session variable.
Note: The KeepAlive setting on your backend webserver must be enabled for Kerberos authentication to work properly.
|KDC||Specifies the IP Address or the host name of the Kerberos Key Distribution Center (KDC) (normally an Active Directory domain controller) for the server realm.||
Note: KDC must be empty when the user realm is different from the server realm and in the case of multi-domain realms.If KDC is empty, the KDC must be discoverable through DNS. For example, the BIG-IP system must be able to fetch SRV records for the server realm's domain, where the domain name is the same as the realm name. If the domain name is different from the realm name, it must be specified in the /etc/krb5.conf file.
Kerberos SSO processing is fastest when KDC is specified by its IP address, slower when specified by host name, and, due to additional DNS queries, even slower when empty.
|Account Name||Specify the name of the Active Directory account configured for delegation.||This account must be configured in the Kerberos realm (AD Domain) of the server.
Note: If servers are from multiple realms, each realm (AD Domain) must have its own delegation account.
|Account Password||Specifies the password for the delegation account specified in the Account Name field.|
|Confirm Account Password||Verifies the password specified in the Account Password field.|
|SPN Pattern||An optional field for modifying how the Service Principal Name (SPN) for the servers is constructed.||Leave this field empty unless you need non-standard SPN format. For example, HTTP/%s@REALM, where %s is replaced by the server host name discovered through reverse DNS lookup using the server IP address. When entering a string, replace REALM with an actual realm name (as specified in Kerberos Realm setting).|
|Ticket Lifetime||Represents the maximum ticket lifetime in minutes. Defaults to 600. Minimum is 10.||Should not be set higher than the value configured for the Active Directory
delegation account (which defaults to 600).
Note: The actual lifetime can be less than the configured value by up to 1 hour because the user's ticket lifetime is the same as the Kerberos Ticket Granting Ticket (TGT) ticket lifetime.The TGT for the delegation account specified in this configuration is obtained. A new TGT is fetched every time the latest TGT is older than one hour, but only when an SSO request is processed.
|Send Authorization||Specifies when to submit the Kerberos ticket to application servers: Always or On 401 Status Code. Defaults to Always.||The Kerberos ticket is submitted in the HTTP Authorization header. The header
value starts with the word Negotiate, followed by one space and a base64 encoded GSSIAPI
token that contains the Kerberos ticket. If the request contains an Authorization header
from the client browser, it is deleted. The options are defined here.
|Username Conversion||Check box is cleared by default.||When the check box is selected, the PREWIN2k/UPN user name input format is converted to the format you want to use for SSO. For example, convert domain\username or username@domain to username.|
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.|
If you run into problems with Kerberos SSO, follow these tips to try to resolve issues.
Only Microsoft IIS servers are supported for 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:
Kerberos SSO relies on reverse DNS resolution for determining the SPN (Service Principal Name) for each server host, such as a load balanced pool member or a web application resource host. Access Policy Manager should be configured to use DNS servers 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.
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.
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.
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.