Chapter 3: Posture Agents

Cisco Press

1 2 3 Page 2
Page 2 of 3

To enable logging, go to the Cisco Trust Agent configuration directory on the host where Cisco Trust Agent is installed. The Cisco Trust Agent log file is located by default at C:\Documents and Settings\All Users\Application Data\Cisco Systems\CiscoTrustAgent\.

Rename the ctalogd.tmp file to ctalogd.ini. The log file is then created in the Logs subdirectory as soon as the Cisco Trust Agent receives the next EAPoUDP/EAPoL request. If the log file is not created, either you didn't rename the file correctly or the Cisco Trust Agent is not receiving EAPoUDP/EAPoL requests, which can be caused by a personal firewall blocking the requests or Cisco Trust Agent port from the NAD. Logging can also be enabled and configured through the command-line program clogcli.exe.

At the time of this writing, the default maximum log size is 4 MB and can be changed by editing the ctalogd.ini file. When the maximum log size is reached, a new log file is created. Over time, an unlimited number of files are created.

For information about log files or how to customize them, refer to the "Cisco Trust Agent Event Logging" section of the Cisco Trust Agent Administrator Guide located at

Operating System Support

As of this writing, Cisco Trust Agent supports the Windows and Red Hat Linux (Enterprise, Advanced, and Workstation, versions 3.x and 4.x) operating systems. Additional platform support for Microsoft Windows Mobile 5 and Windows XP Tablet, Sun Solaris, and Apple Macintosh OS X is anticipated.

As you saw from the two plug-ins described earlier (ctapp.inf and CiscoHostPP.inf), Cisco Trust Agent can gather the following information on a Windows NT 4.0, Windows 2000, or Windows XP system:

  • Operating system name (for example, Windows XP Professional)

  • Operating system version (for example, Version 2002)

  • Operating system service pack (for example, Service Pack 2)

  • Operating system hot fixes (for example, KB123456, KB234567, and so on)

  • Machine name (for example, the host Fully Qualified Domain Name [FQDN])

  • Cisco Trust Agent information:

    • Posture agent name (for example, Cisco Trust Agent)

    • Posture agent version (for example,

    • Machine posture state (for example, booting versus logged in)

For Red Hat Linux, Cisco Trust Agent can collect the following information:

  • Selected Red Hat Package Manager (RPM) versions

  • Operating system type (for example, Red Hat Enterprise Linux ES)

  • Operating system (OS) release (includes OS kernel name, version, and hardware platform)

  • Kernel version (same as output of uname –r)

  • Cisco Trust Agent information:

    • Posture agent name (for example, Cisco Trust Agent)

    • Posture agent version (for example,

    • Machine posture state (for example, booting versus logged in)

The Linux host posture plug-in can retrieve the version number of certain packages, but these packages must be predefined in the ACS policy. Be aware that the Linux RPM version format is inconsistent when requested as a string or an octet. The following are examples of how the version number can appear. Cisco Trust Agent returns a package version number using a special format.

The first example is a posture validation rule configured in ACS that requests the version number of the OpenSSL package. When requested as a string, the version number is returned as a combination of numbers and letters, such as 0.9.7a.

The second example is when requested as a 4-octet number; the version number returned might be

Note - Cisco Trust Agent for Linux does not support the retrieval of the host's FQDN.

Cisco Trust Agent, in combination with posture plug-ins and, optionally, with various third-party host applications, can deliver a deep view into the security policy compliance of a business's fleet of hosts.

Posture Plug-in Functionality

Posture plug-ins gather data from various security applications or host operating systems in a format that is acceptable for transmission to the posture agent, Cisco Trust Agent.

A critically significant aspect of the NAC Framework approach is its ability to intelligently integrate into third-party applications. As part of the Cisco NAC Partner Program (more information is available at, vendors of host antivirus, endpoint security, compliance and audit, and remediation and patch management products use Cisco Trust Agent to deliver credentials specific to their solution for validation against a comprehensive access control policy. Third-party security and compliance solutions can now use the ubiquitous presence of the network as a powerful enforcement point, and thereby deliver a significant extension on the customer's existing capital and operational investment in that application.

Each NAC vendor's posture plug-in is assigned a vendor ID by way of Internet Assigned Numbers Authority (IANA). A list of IANA assignments can be found at

Within that identifier, the vendor can implement a per-application type, followed by the various attributes that the vendor would like evaluated for admission control policy validation. The NAC vendor must follow a specific format or namespace as follows:


Refer to Table 3-1 for a list of credentials available from the host at the time of this writing. The list can vary depending on the installed posture agents.

Table 3-1 Credential Attributes

ApplicationVendorApplication TypeAttributes

Cisco Trust Agent


Posture agent (PA)







Machine PostureState

Cisco Trust Agent



Service Packs





Host-based intrusion prevention system (HIPS)





TimeSinceLast Successful Poll



Antivirus, personal firewall (PFW), and so on









In Windows versions, every Cisco NAC vendor must create the following two files that interoperate with Cisco Trust Agent:

  • .dll—Links Cisco Trust Agent and the host application that in effect makes it a posture agent. The .dll file contains the application code for its specific plug-in actions that works with the application's notification string.

  • .inf—Describes the various attributes available from the vendors plug-in. These are typically located in one of the following host directories:

    • For Cisco Trust Agent v1: C:\Program Files\Cisco Systems

    • For Cisco Trust Agent v2 or greater: C:\Program Files\Common Files\PostureAgent\Plugins

When a NAC vendor's credential is sent from the host to ACS, ACS must be capable of understanding it. To accomplish this, ACS must contain the partner attribute definition files (ADFs) that are specific to that NAC vendor. These ADFs can be imported into the ACS dictionary by using the CS-Util tool. Refer to version 4.0 of the Cisco Secure ACS Configuration Guide, located at, Technical Documents for Cisco Security. An additional function of posture plug-ins is status change notification. When the associated security application completes a remediation process, such as receiving an updated signature file for an antivirus program, the posture plug-in can signal Cisco Trust Agent that a status change has occurred. When Cisco Trust Agent has been installed with a supplicant in NAC-L2-802.1X mode, Cisco Trust Agent can signal the supplicant to send an EAPoL start packet to the NAD. This triggers the initiation of a normal authentication sequence by the NAD. This feature is currently only available with a supplicant operating in NAC-L2-802.1X mode and is called asynchronous status query. When operating in NAC-L2-IP or NAC-L3-IP mode, the host must wait to receive a status query before triggering a revalidation.

Vendor Application Example: Cisco Security Agent

Many NAC-enabled vendor applications provide capabilities that can interoperate with NAC, thus extending the value of the existing application investment into a wider range of solutions. An example is Cisco Security Agent (CSA). CSA contains its own posture plug-in files, enabling it to send a credential to the NAC solution.

CSA provides the following four benefits to complement a NAC Framework solution:

  • Cisco Trust Agent protection

  • NAC state awareness

  • Trusted quality of service

  • Efficient mass deployment of Cisco Trust Agent

Cisco Trust Agent Protection

CSA is a behavioral-based host intrusion prevention product. It focuses on protecting the host asset and the intellectual property that resides on that asset, per its configured security policy.

In CSA versions 4.5.1 and 5.0, prebuilt rules exist that focus on two important functions: permitting Cisco Trust Agent to function as intended and protecting Cisco Trust Agent from outside interference. This interference could be caused by either a user mistake, such as uninstalling Cisco Trust Agent, or by intention, such as a worm attempting to spoof credentials. As shown in Figure 3-4, CSA has rules that permit Cisco Trust Agent to communicate with the network, open notification messages on the user's desktop, and open the default browser and pass a URL for remediation. CSA also has a rule that prevents modification of the Cisco Trust Agent files and the posture plug-in file folder.

Figure 3-4

Figure 3-4

CSA Management Center: Cisco Trust Agent Rule Module

NAC State Awareness

Because Cisco Trust Agent and CSA can be installed on a host together, in this case, CSA also serves as a posture agent. As part of the integration, CSA can also see the system posture token (SPT) that is passed to Cisco Trust Agent from ACS. This allows CSA to dynamically change its specific host security policy in accordance with the admission control assessment.

Integrating host security functionality and port-based access control gives IT operations the capability to implement a policy that locks down noncompliant hosts so that only specified applications are allowed to run, and to only contact specific resources on the network. For example, IT operations can implement a policy that only permits remediation processes to run and only permits the default web browser to go to a narrow list of internal web resources.

Trusted Quality of Service

Providing a policy enforcement agent on the endpoint allows businesses to intelligently shift the trust boundary of the network into the host. This trust boundary depends on the admission control result. This type of solution is called Cisco Trusted Quality of Service (QoS).

Cisco Trusted QoS is valuable for two reasons. Because CSA can identify and secure known applications, it can properly mark the traffic from those applications with the appropriate Differentiated Services Code Point (DSCP) values (in accordance with corporate IT policy). This can be significant because traffic egressing onto the wide-area network will not need to be inspected, lessening the resource burden on the edge devices. In addition, because this policy is dynamic, the QoS policy within the company in question can adapt extremely quickly to new demands.

The other reason that Cisco Trusted QoS is important is that by virtue of the fact that you are discovering and marking traffic based on CSA's identification of known applications, you can now discover and mark all the application traffic that does not conform to your policies. As shown in Figure 3-5, the Management Control Center for Cisco Security Agent allows administrators to configure Differentiated Service enforcements.

Figure 3-5

Figure 3-5

CSA Management Center: Trusted QoS

As shown here, the administrator marks certain traffic to be a Scavenger class (Differentiated Service Scavenger (8,CS1)) and selectively drops it if it exceeds a certain rate. Even more interestingly, questionable traffic can selectively be routed through upstream security devices by using other routing and switching functions, such as policy-based routing, virtual routing and forwarding (VRF), or Cisco Optimized Edge Routing (OER). This can greatly decrease the utilization on these security devices, because they would only be inspecting and enforcing questionable traffic versus all traffic.

For more information on Trusted QoS, refer to the Cisco Security Agent Management Center (CSA MC) documentation located at

Bundling Cisco Trust Agent for Deployment

A final CSA benefit is to use the CSA MC to import and install the Cisco Trust Agent along with CSA onto hosts automatically. This can be done by associating installation options such as a silent install with the supplicant and the required certificate into the CSA build kit process. This allows the operator to bundle and even update Cisco Trust Agent on any host that has CSA installed. An example of how to select this bundling option in CSA MC is shown in Figure 3-6.

Figure 3-6

Figure 3-6

CSA Management Center: Cisco Trust Agent Bundling

Bundling Cisco Trust Agent with CSA installation can represent a significant operational time savings, as well as decrease the interruption on the part of the user community.


Cisco Trust Agent is the NAC posture agent that is a fundamental component of NAC Framework providing the following two major functions:

  • Acts as a broker, communicating with the NAC-enabled host applications and gathering credentials

  • Communicates with NADs by way of EAPoUDP or EAPoL (802.1X)

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