Chapter 3: Posture Agents

Cisco Press

  • Posture agent overview

  • Cisco Trust Agent architecture

  • Posture plug-in functionality

  • Vendor application example: Cisco Security Agent

For Network Admission Control (NAC)–enabled hosts to be able to communicate their posture credentials to the posture server, a posture agent must exist on the host.

Cisco Trust Agent is the posture agent. It communicates with various NAC-enabled host applications by way of their posture plug-ins. NAC third-party vendors must build their own posture plug-ins to communicate their credentials to the policy decision points. Each vendor is identified by a unique vendor ID that identifies the vendor's application type (for example, antivirus) and attributes (for example, version).

Cisco Trust Agent aggregates host posture credentials from all the NAC-enabled application plug-ins and communicates them to the network.

This chapter examines the role of hosts in NAC and describes how Cisco Trust Agent and NAC-enabled applications interoperate.

This chapter describes the following items:

  • The two major functions of the NAC posture agent

  • The process for posture validation

  • The process for identity and posture validation

  • Posture plug-ins and the vendor namespace format

  • The posture plug-in contents of .dll and .inf files

  • The Cisco Trust Agent–supported host operating systems

  • Four benefits of using Cisco Security Agent (CSA) with NAC Framework implementations

Posture Agent Overview

As shown in Figure 3-1, three distinct roles exist within a NAC Framework solution:

  • Hosts connecting to the network

  • Network access devices (NADs) that serve as the policy enforcement point (PEP)

  • Policy servers that act as the policy decision point (PDP)

Figure 3-1

Figure 3-1

Network Admission Control Logical Roles

Posture is the term that describes the collection of credentials and attributes that define the state or health of a user's computer and the applications on that computer, which this book refers to as the host.

With NAC, a posture agent is required and resides on the host, or subject, and communicates information such as device operating system and application-level information, in the form of credentials.

The NAD forwards the host credentials for validation against the policy decision points (PDPs) of the NAC Framework solution. A policy decision is made and network enforcement instructions are sent by the Cisco Secure Access Control Server (ACS) to be enforced by the NAD.

The posture agent also performs a variety of functions, such as informing the user by a custom configurable message notification that is sent to the user describing the posture condition of his host. The following is a notification example for a noncompliant host: "Your computer is lacking the necessary updates and therefore is not granted access to the network. In order to resume normal network access, please update your computer now at the following location." In addition to the message notification, a notification string, such as a URL entry, can also be configured by administrators that automatically send a noncompliant host to a remediation server.

Additional actions exist and vary by vendor applications.

Cisco Trust Agent Architecture

The following sections describe these components of Cisco Trust Agent:

  • Posture agent plug-in file, which defines the host posture credential attributes

  • Cisco Trust Agent log file and the type of events captured, which are useful for troubleshooting host problems with NAC

These sections also identify the operating systems that are supported by Cisco Trust Agent.

First, we walk you through the architecture of posture agents, beginning with the mandatory component, Cisco Trust Agent, as shown in Figure 3-2.

Figure 3-2

Figure 3-2

Cisco Trust Agent Architecture

Cisco Trust Agent resides on the host and runs in the background as a service. Services exist and vary by Cisco Trust Agent version. These services should be automatically started and running; they include the following:

  • Cisco Trust Agent (prior to Cisco Trust Agent version 2.0)

  • Cisco Trust Agent Event Logging Service (prior to Cisco Trust Agent version 2.0)

  • Cisco Posture Server Daemon (Cisco Trust Agent version 2.0)

  • Cisco Systems, Inc. Cisco Trust Agent Posture State Daemon (Cisco Trust Agent version 2.0)

  • Cisco Trust Agent EoU Daemon (Cisco Trust Agent version 2.0)

  • Cisco Trust Agent Logger Daemon (Cisco Trust Agent version 2.0)

If 802.1X is included, the following additional services should be running:

  • Cisco Trust Agent 802.1X Wired Client (Cisco Trust Agent version 2.0)

  • Cisco Trust Agent 802.1X Wired Client Log (Cisco Trust Agent version 2.0)

Cisco Trust Agent provides the following two major functions:

  • Cisco Trust Agent can collect information regarding the host operating system through internal posture plug-ins and acts as a broker by collecting credentials from third-party host application posture plug-ins.

  • Cisco Trust Agent communicates to the NAD upstream with one of following protocols: Extensible Authentication Protocol over User Datagram Protocol (EAP over UDP, EAPoUDP, or EoU) and EAP over LAN (EAPoL), otherwise known as 802.1X.


Note - For 802.1X implementations, Cisco Trust Agent does not communicate directly to the NAD. All EAP transactions occur from Cisco Trust Agent to the supplicant and to the NAD, and vice versa.


Cisco Trust Agent is available at no charge and can be downloaded by any registered user at http://cisco.com/cgi-bin/tablebuild.pl/cta. It can also come bundled with CSA as well as some third-party NAC vendor applications.

Cisco Trust Agent also has the following additional features:

  • Operating system posture assessment for the host

  • Client notification and default browser integration

  • Cisco Trust Agent Scripting Interface (CTASI)

Cisco Trust Agent includes two posture plug-ins of its own: one to report the status of the posture agent itself and one to report some basic information about the host that it's running on. Each of these posture plug-ins returns a credential as part of the validation process.

Cisco Trust Agent can also launch a web browser at the conclusion of the validation process. This is enabled by placing a URL in the notification string of the corresponding ACS configuration for posture validation. A pop-up message might also be displayed by Cisco Trust Agent or other applications that have this functionality by populating the PA Message section of the Posture Validation section in the Network Access Profiles setup on ACS.

When arbitrary information about a host is needed to make a complete posture assessment, the CTASI can be used. A user script can write a formatted file that CTASI can read into Cisco Trust Agent's internal database. This database is then sent as an additional credential for the posture decision-making process.

Cisco Trust Agent has two primary versions: one with an 802.1X supplicant and one without the supplicant.

Beginning with the core mandatory functionality, Cisco Trust Agent can operate solely for posture assessment using EoU with either version. By default, Cisco Trust Agent uses UDP port number 21862 for EoU communications. This port can be changed by editing the ctad.ini configuration file, which is described later in this section. Note that whichever UDP port is used, any host personal firewall must be modified to permit incoming traffic to this UDP port. Otherwise, Cisco Trust Agent will be unable to communicate NAC requests to the NAD, resulting in the host failing to authenticate and thereby receiving restricted access to the network.

Cisco Trust Agent can also gather identity and posture credentials simultaneously using the embedded, wired-only 802.1X supplicant.


Note - Cisco Trust Agent includes an 802.1X supplicant for wired interfaces only. For wired and wireless support, a third-party supplicant vendor can be engaged (such as Meetinghouse Data Communications, http://www.mtghouse.com).


With the NAC-L2-IP (EoU) method, the NAD detects a new host by way of DHCP or Address Resolution Protocol (ARP), where it queries the host, and if installed, Cisco Trust Agent responds to this query. At this point, the NAD signals the Cisco Secure ACS that it has a new host to be admitted to the network.

ACS and Cisco Trust Agent build a secure tunnel using Protected EAP (PEAP). PEAP requires the use of digital certificates. The PEAP tunnel is secured by way of a certificate presented by ACS during the establishment of the session. Because Cisco Trust Agent is installed with a root or intermediate root certificate, it trusts ACS and therefore builds a secure tunnel.


Note - For more information on the PEAP process, refer to the "NAC-L3-IP and NAC-L2-IP Posture Validation and Enforcement Process" section in Chapter 2, "Understanding NAC Framework."



Note - When Cisco Trust Agent is installed, it must have either the ACS server's certificate or a certificate in the chain of authority, either the root or an intermediate root certificate. For more information on installing and using digital certificates with Cisco Trust Agent, refer to the Cisco Trust Agent Administrator Guide located at http://www.cisco.com.


In cases where you want to evaluate user and/or device identity and posture credentials, you should use 802.1X.

The 802.1X technology can be used either with the embedded wired-only supplicant or a third-party supplicant. In this scenario, the Extensible Authentication Protocol–Flexible Authentication via Secure Tunneling (EAP-FAST) method must be used as the outer authentication method (at the time of this writing). The ability to handle multiple authentication types, for example, both user and machine identity and posture validation, in one authentication request is called credential chaining. EAP-FAST is currently the only EAP tunneling method that allows credential chaining. EAP-FAST is similar to PEAP in that it's also a tunneled protocol that supports a variety of authentication methods. What's different is that EAP-FAST does not require digital certificates like PEAP; it's designed to run on nearly every host device and preferred by some customers who don't want to use digital certificates.

Inner EAP types that can be used for identity authentication include the following:

  • EAP–Microsoft Challenge Handshake Authentication Protocol (MSCHAP) v2: Used for Microsoft Active Directory based on username and password credentials.

  • EAP–Transport Layer Security (TLS): Used with machine and/or user certificates.

  • EAP–Generic Token Card (GTC): Used with Lightweight Directory Access Protocol (LDAP) or one-time passwords like Rivest, Shamir, and Adelman (RSA) SecurID tokens for identity information and include the relevant posture information as type-length values (TLVs) in the exchange with the ACSs.

For more on EAP-FAST, refer to http://www.ietf.org/internet-drafts/draft-cam-winget-eap-fast-06.txt.

In addition, user notifications are expressed by way of Cisco Trust Agent notification pop-ups, as shown in Figure 3-3, as well as by opening the host's default browser to a URL.

Figure 3-3

Figure 3-3

User Notification Example of a Quarantine Condition

All of this information is expressed in the admission control policy, as configured in ACS.

In summary, the Cisco Trust Agent performs the following two mandatory functions:

  • Communication with the NAD by either EAPoUDP or EAPoL (802.1X)

  • Communication with NAC-capable applications on the host

Posture Agent Plug-in Files

Cisco Trust Agent includes two posture assessment capabilities: gathering its own posture information and gathering posture details from the host, such as operating system information through internal posture plug-ins.

The following is an example of an .inf file from Cisco Trust Agent's posture plug-in, or ctapp.inf, file:

 [main]
PluginName=ctapp.dll
VendorID=9
VendorIDName=Cisco Systems
AppList=pa

[pa]
AppType=1
AppTypeName=CtaEoU
AttributeList=attr1,attr2,attr3,attr4,attr5,attr6,attr7,attr8
attr1=1,notify,AppPostureResult
attr2=2,notify,SysPostureResult
attr3=3,string,AppName
attr4=4,version,AppVersion
attr5=5,string,OSName
attr6=6,version,OSVersion
attr7=11,Unsigned32,CTAState
attr8=7,notify,UserNotify

The following is an example of Cisco Trust Agent's host posture plug-in, or CiscoHostPP.inf, file:

[main]
PluginName=CiscoHostPP.dll
VendorID=9
VendorIDName=Cisco Systems
AppList=CiscoHost

[CiscoHost]
AppType=2
AppTypeName=Host Posture Plugin
AttributeList=attr6,attr7,attr8
attr6=6,string,ServicePack
attr7=7,string,HotFixes
attr8=8,string,SystemName

You can see the attributes or credentials that these Cisco Trust Agent plug-ins gather for evaluation. Other NAC posture plug-ins are similar in how they are organized. However, the specific attributes differ by application.

A posture plug-in can also act on messages received from ACS at the conclusion of the posture validation process. These messages take two forms. One is a pop-up message that is displayed on the host's screen, informing the user of the posture validation results and optionally including an active URL. The second is a notification string that can be sent as a result of the validation process. This notification string can launch the default web browser on the host or can trigger the posture plug-in to begin a remediation process such as the update of an antivirus signature file. The actions triggered by the notification string vary according to the specific security application that the posture plug-in is associated with.

Cisco Trust Agent Logging

Cisco Trust Agent has logging capabilities that are extremely useful for troubleshooting NAC events. However, they are disabled by default (at the time of this writing).

Related:
1 2 3 Page 1
Page 1 of 3
SD-WAN buyers guide: Key questions to ask vendors (and yourself)