Microsoft Kerberos Constrained Delegation Solution
Microsoft’s Kerberos Constrained Delegation (KCD) provides access to Kerberos-protected Web applications in the private network.
In order for Kerberos Constrained Delegation to function, the ASA must establish a trust relationship between the source domain (the domain where the ASA resides) and the target or resource domain (the domain where the Web services reside). The ASA crosses the certification path from the source to the destination domain and acquires the necessary tickets on behalf of the remote access user to access the services.
This crossing of the certificate path is called cross-realm authentication. During each phase of cross-realm authentication, the ASA relies on the credentials at a particular domain and the trust relationship with the subsequent domain.
How KCD Works
Kerberos relies on a trusted third party to validate the digital identity of entities in a network. These entities (such as users, host machines, and services running on hosts) are called principals and must be present in the same domain. Instead of secret keys, Kerberos uses tickets to authenticate a client to a server. The ticket is derived from the secret key and consists of the client’s identity, an encrypted session key, and flags. Each ticket is issued by the key distribution center and has a set lifetime.
The Kerberos security system is a network authentication protocol used to authenticate entities (users, computers, or applications) and protect network transmissions by scrambling the data so that only the device that the information was intended for can decrypt it. You can configure KCD to provide Clientless SSL VPN users with SSO access to any Web services protected by Kerberos. Examples of such Web services or applications include Outlook Web Access (OWA), Sharepoint, and Internet Information Server (IIS).
Two extensions to the Kerberos protocol were implemented: protocol transition and constrained delegation. These extensions allow the Clientless SSL VPN remote access users to access Kerberos-authenticated applications in the private network.
Protocol transition provides you with increased flexibility and security by supporting different authentication mechanisms at the user authentication level and by switching to the Kerberos protocol for security features (such as mutual authentication and constrained delegation) in subsequent application layers. Constrained delegation provides a way for domain administrators to specify and enforce application trust boundaries by limiting where application services can act on a user’s behalf. This flexibility improves application security designs by reducing the chance of compromise by an untrusted service.
For more information on constrained delegation, see RFC 1510 via the IETF website (http://www.ietf.org).
Authentication Flow with KCD
The following figure depicts the packet and process flow a user experiences directly and indirectly when accessing resources trusted for delegation via the clientless portal. This process assumes that the following tasks have been completed:
-
Configured KCD on ASA.
-
Joined the Windows Active Directory and ensured services are trusted for delegation.
-
Delegated ASA as a member of the Windows Active Directory domain.
Note |
A clientless user session is authenticated by the ASA using the authentication mechanism configured for the user. (In the case of smartcard credentials, ASA performs LDAP authorization with the userPrincipalName from the digital certificate against the Windows Active Directory). |
-
After successful authentication, the user logs in to the ASA clientless portal page. The user accesses a Web service by entering a URL in the portal page or by clicking on the bookmark. If the Web service requires authentication, the server challenges ASA for credentials and sends a list of authentication methods supported by the server.
Note
KCD for Clientless SSL VPN is supported for all authentication methods (RADIUS, RSA/SDI, LDAP, digital certificates, and so on). Refer to the AAA Support table at http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/access_aaa.html#wp1069492.
-
Based on the HTTP headers in the challenge, the ASA determines whether the server requires Kerberos authentication. (This is part of the SPNEGO mechanism.) If connecting to a backend server requires Kerberos authentication, the ASA requests a service ticket for itself on behalf of the user from the key distribution center.
-
The key distribution center returns the requested tickets to the ASA. Even though these tickets are passed to the ASA, they contain the user’s authorization data. The ASA requests a service ticket from the KCD for the specific service that the user wants to access.
Note
Steps 1 to 3 comprise protocol transition. After these steps, any user who authenticates to the ASA using a non-Kerberos authentication protocol is transparently authenticated to the key distribution center using Kerberos.
-
The ASA requests a service ticket from the key distribution center for the specific service that the user wants to access.
-
The key distribution center returns a service ticket for the specific service to the ASA.
-
The ASA uses the service ticket to request access to the Web service.
-
The Web server authenticates the Kerberos service ticket and grants access to the service. The appropriate error message is displayed and requires acknowledgment if there is an authentication failure. If the Kerberos authentication fails, the expected behavior is to fall back to basic authentication.
Create a Kerberos Server Group for Constrained Delegation
To use Kerberos Constrained Delegation, you must first configure a Kerberos AAA server group. The server group must contain the Active Directory (AD) domain controller.
Procedure
Step 1 |
Create the Kerberos AAA server group and enter aaa-server-group configuration mode. aaa-server server_group_name protocol kerberos Example:
|
Step 2 |
(Optional.) Specify the maximum number of failed AAA transactions with a AAA server in the group before trying the next server. max-failed-attempts number Example:
The number argument can range from 1 and 5. The default is 3. |
Step 3 |
(Optional.) Specify the method (reactivation policy) by which failed servers in a group are reactivated. reactivation-mode {depletion [deadtime minutes] | timed} Example:
The depletion keyword reactivates failed servers only after all of the servers in the group are inactive. This is the default mode. The deadtime minutes keyword pair specifies the amount of time in minutes, between 0 and 1440, that elapses between the disabling of the last server in the group and the subsequent reenabling of all servers. The default is 10 minutes. The timed keyword reactivates failed servers after 30 seconds of down time. |
Step 4 |
Add the Kerberos server to the Kerberos server group. aaa-server server_group [(interface_name)] host server_ip Example:
If you do not specify an interface, then the ASA uses the inside interface by default. You can use an IPv4 or IPv6 address. |
Step 5 |
Specify the timeout value for connection attempts to the server. timeout seconds Specify the timeout interval (1-300 seconds) for the server; the default is 10 seconds. For each AAA transaction the ASA retries connection attempts (based on the interval defined on the retry-interval command) until the timeout is reached. If the number of consecutive failed transactions reaches the limit specified on the max-failed-attempts command in the AAA server group, the AAA server is deactivated and the ASA starts sending requests to another AAA server if it is configured. Example:
|
Step 6 |
Specify the retry interval, which is the time the system waits before retrying a connection request. retry-interval seconds You can specify 1-10 seconds. The default is 10. Example:
|
Step 7 |
Specify the server port if it is different from the default Kerberos port, which is TCP/88. The ASA contacts the Kerberos server on this port. server-port port_number Example:
|
Step 8 |
Configure the Kerberos realm. kerberos-realm name Kerberos realm names use numbers and upper case letters only, and can be up to 64 characters. The name should match the output of the Microsoft Windows set USERDNSDOMAIN command when it is run on the Active Directory server for the Kerberos realm. In the following example, EXAMPLE.COM is the Kerberos realm name:
Although the ASA accepts lower case letters in the name, it does not translate lower case letters to upper case letters. Be sure to use upper case letters only. Example:
|
Example
The following example creates a Kerberos server group named MSKCD, adds a server, and sets the realm to EXAMPLE.COM.
hostname(config)# aaa-server MSKCD protocol kerberos
hostname(config-aaa-server-group)# aaa-server MSKCD (inside) host 10.1.1.10
hostname(config-aaa-server-host)# kerberos-realm EXAMPLE.COM
Configure Kerberos Constrained Delegation (KCD)
The following procedure explains how to implement Kerberos Constrained Delegation (KCD).
Before you begin
-
Enable DNS lookup on the interface through which the domain controller is reached. When using KCD as the authentication delegation method, DNS is required to enable hostname resolution and communication between the ASA, Domain Controller (DC), and the services trusted for delegation. Clientless VPN deployments require DNS Lookups through the internal corporate network, typically the inside interface.
For example, to enable DNS lookup on the inside interface:
hostname(config)# dns domain-lookup inside
-
Configure DNS to use the Active Directory (AD) domain controller as the DNS server, with the domain realm as the DNS domain.
For example, to configure the DefaultDNS group to use domain controller at 10.1.1.10 off the inside interface with the realm EXAMPLE.COM:
hostname(config)# dns server-group DefaultDNS hostname(config-dns-server-group)# name-server 10.1.1.10 inside hostname(config-dns-server-group)# domain-name EXAMPLE.COM
Procedure
Step 1 |
Switch to Clientless SSL VPN configuration mode. webvpn |
Step 2 |
Enable KCD. kcd-server kerberos_server_group username user_id password password Where:
Example:
|
Monitoring Kerberos Constrained Delegation
You can use the following commands to monitor KCD.
-
show webvpn kcd
Shows the KCD configuration and join status.
ciscoasa# show webvpn kcd KCD state: Domain Join Complete Kerberos Realm: EXAMPLE.COM ADI version: 6.8.0_1252 Machine name: ciscoasa ADI instance: root 1181 1178 0 15:35 ? 00:00:01 /asa/bin/start-adi Keytab file: -rw------- 1 root root 79 Jun 16 16:06 /etc/krb5.keytab
-
show aaa kerberos [ username user_id]
Shows the Kerberos tickets cached on the system. You can view all tickets, or just those tickets for a given user.
ASA# show aaa kerberos Default Principal Valid Starting Expires Service Principal asa@example.COM 06/29/10 18:33:00 06/30/10 18:33:00 krbtgt/example.COM@example.COM kcduser@example.COM 06/29/10 17:33:00 06/30/10 17:33:00 asa$/example.COM@example.COM kcduser@example.COM 06/29/10 17:33:00 06/30/10 17:33:00 http/owa.example.com@example.COM
-
clear aaa kerberos tickets [ username user_id]
Clears the Kerberos tickets cached on the system. You can clear all tickets, or just those tickets for a given user.