1-45
Cisco ASA Series CLI Configuration Guide
Chapter 1 Configuring Clientless SSL VPN
Understanding How KCD Works
Requirements
In order for the kcd-server command 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, using its unique format, 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.
Understanding 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 (also known as WebVPN) 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 or WebVPN remote access users to access Kerberos
authenticated applications in the private network.
The 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
Figure 1-7 depicts the packet and process flow a user will experience 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
To Next Page
Loading...
Need help?
General
