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.
Access Policy Manager lets you configure for Kerberos SSO.
To set up this configuration, follow the procedures in the task 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.|
If you run into problems with Kerberos SSO, follow these tips to try to resolve issues.
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.
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.