Cisco Context Directory Agent (CDA) & Other Materials [Redhat Hacker]

Context Directory Agent Overview

Unlike traditional security mechanisms, Cisco’s security gateways such as ASA-CX, WSA, ASA and the Cloud-based CWS service, provide security to networks based on the context of the entity requiring access. While traditional network and content security gateways used to rely on the entity’s IP Address only to determine if it should pass the security gateway or not, today’s Cisco products allow to take into account much additional information, and make decisions based on the complete context of the network entity, such as the user currently using it, what operating system it uses, what location is it in, and so on. Security administrators write policies using reference to this context, and when network traffic hits the security gateway, it needs to check what is the context of the originating (and sometimes, also the destined) IP Address.

Cisco Context Directory Agent (CDA) is a mechanism that maps IP Addresses to usernames in order to allow security gateways to understand which user is using which IP Address in the network, so those security gateways can now make decisions based on those users (or the groups to which the users belong to).

CDA runs on a Cisco Linux machine; monitors in real time a collection of Active Directory domain controller (DC) machines for authentication-related events that generally indicate user logins; learns, analyzes, and caches mappings of IP Addresses and user identities in its database; and makes the latest mappings available to its consumer devices.

Starting with patch 2, CDA can now receive information from Cisco Identity Services Engine (ISE) and Cisco Secure Access Control Server (ACS) machines about 802.1x network logins, in order to map users that do not directly login into Active Directory. CDA acts as a syslog server, receiving syslog messages from ISE and ACS, and populates the mapping table using network login information derived from ISE and ACS.

Consumer devices, such as the Cisco Adaptive Security Appliance (ASA) and the Cisco IronPort Web Security Appliance (WSA), interact with the CDA using the RADIUS protocol in order to obtain the latest set of IP-to-user-identity mappings, in any one of the following ways:

On-Demand —CDA can respond to an on-demand query from the consumer device for a specific mapping.
Full Download —CDA can respond to a request from the consumer device for the entire set of mappings currently in its cache.

For both the on-demand and full-download methods, the request from the consumer device can be specially tagged to indicate that it also includes a registration regarding any subsequent updates.

For example, when a consumer device requests a basic on-demand query, CDA responds with the specific mapping that might have been found in its cache, and does not send any further updates about that mapping. On the other hand, if the on-demand query also includes a registration, the initial response from CDA is the same as before and if, at a later point in time, that specific mapping undergoes a change, then CDA proactively notifies the requesting consumer device (as well as any other consumer devices that have registered for notification) about the change in that specific mapping.

Similarly, when a consumer device requests a basic full download, CDA transfers a snapshot of the session data containing all of the mappings currently found in its cache, and does not send any further updates. On the other hand, if the request is to register for replication, then the initial response from CDA is the same as before. At a later point in time, if the set of mappings undergoes any sort of change (new mappings added or certain mappings changed and so on), then CDA proactively notifies the requesting consumer device (as well as any other consumer devices that have registered for replication) about these changes, relative to the snapshot that was previously sent.

The IP-to-user-identity mappings that are discovered, maintained, and provided by CDA can include not only IPv4 addresses, but also IPv6 addresses.

CDA can send logs to one or more syslog servers.

CDA continues to function if any of the Active Directory domain controllers or the consumer devices have failed. It obtains information from other domain controllers. However, there is no failover for CDA. CDA internally contains a “watchdog” functionality that continuously monitors the Linux processes internal to it, automatically restarting them if it detects that they have crashed. While there is no failover for CDA in itself, the solution as a whole does support failover, controlled by the consumer devices, using their capability to configure a primary and secondary CDA (similar to primary and secondary RADIUS server), and failover to the secondary server in case the primary is unresponsive. It should be noted that primary and secondary CDAs are completely unaware of each other, and do not exchange any state information.