Table Of Contents
Administering CAS Certificates, Time, and Support Logs
Status Tab
Clean Access Server Direct Access Web Console
Manage CAS SSL Certificates
SSL Certificate Overview
Web Console Pages for SSL Certificate Management
CA-Signed Certificates
Intermediary Certificates
Certificates for High Availability (HA) Pairs
Regenerating Certificates for DNS Name Instead of IP
Typical SSL Certificate Setup on the CAS
Phase 1: Establish SSL Communication Between the CAS and CAM
Phase 2: Set Up Your CAS and CAM For Production Deployment
Phase 3: Adding a New CAM or CAS to an Existing Production Deployment
Generate Temporary Certificate
Generate and Export a Certification Request
Manage Signed Certificate/Private Key
Import Signed Certificate/Private Key
Export Certificate and/or Private Key
Manage Trusted Certificate Authorities
Import/Export Trusted Certificate Authorities
View Current Private Key/Certificate and Certificate Authority Information
SSL Requirements for Mac OS X/CAS Communication
CAS Temporary Certificate Requirements for SSL Connection to Mac OS X Agent
Installing the Root Certificate for Mac OS 10.4.x
Installing the Root Certificate for Mac OS 10.5
Enable the Root User on Mac OS X
Obtaining the Root Certificate from the CAS
Troubleshooting Certificate Issues
CAS Cannot Establish Secure Connection to CAM
Private Key in Clean Access Server Does Not Match the CA-Signed Certificate
Certificate-Related Files
System Upgrade
Synchronize System Time
Support Logs and LogLevel Settings
Downloading CAS Support Logs
Administering CAS Certificates, Time, and Support Logs
This chapter describes Clean Access Server (CAS) administration. Topics include:
•
Status Tab
•Clean Access Server Direct Access Web Console
•Manage CAS SSL Certificates
•System Upgrade
•Synchronize System Time
•Support Logs and LogLevel Settings
Status Tab
The Status tab of the CAS management pages displays high-level status information on which modules are running in the Clean Access Server.
Figure 12-1 CAS Management Pages Status Tab
•IP Filter—An IP packet filter that analyzes packets to ensure that they come from valid, authenticated users.
•DHCP Server—The CAS's internal DHCP (Dynamic Host Configuration Protocol) server.
•DHCP Relay—The module that relays address requests and assignments between clients and an external DHCP server.
•IPSec Server—The module for establishing a secure, IP Security-based channel between the CAS and a client device. The module encrypts and decrypts data passed between the client and server.
•Active Directory SSO—The module that enables Active Directory Single Sign-On for authenticated Windows users.
•Windows NetBIOS SSO—The module that enables Windows NetBIOS login for authenticated Windows users.
Clean Access Server Direct Access Web Console
The CAS management pages of the CAM web admin console (Figure 12-1) are the primary configuration interface for the Clean Access Server(s). However, each Clean Access Server has its own web admin console that allows configuration of certain limited Administration and Monitoring settings directly on the CAS (Figure 12-4). The CAS direct access web console is primarily used to download CAS support logs or r configure pairs of Clean Access Servers for High Availability. See Chapter 13, "Configuring High Availability (HA)" for details. If the CAS management pages become unavailable, you can also use the direct console interface for other functions such as managing SSL certificates for the CAS or performing system upgrade.
To access the Clean Access Server's direct access web admin console:
Step 1 Open a web browser and type the IP address of the CAS's trusted (eth0) interface in the URL/address field: https://<CAS_eth0_IP_address>/admin (for example, https://172.16.1.2/admin).
If you have chosen to enable the customizable Pre-login Banner for the CAS during initial configuration, the CAS admin web console displays in introductory Pre-login Banner (Figure 12-2). Otherwise, the CAS administrator credential entry page (Figure 12-3) appears.
Figure 12-2 CAS Pre-Login Banner Example
The Pre-login Banner enables you to present a broad range of messages, including warnings, system/network status, access requirements, etc., to administrator users before they enter authentication credentials in the CAM/CAS. Administrators can specify the text of the Pre-login Banner by enabling this feature on the appliance, logging into the command-line console, and editing the /root/banner.pre file. The text of the Pre-login Banner appears in both the web console interface and the command-line interface when admin users are logging into the CAM/CAS.
You can enable or disable the Pre-login Banner during the initial CAM/CAS configuration CLI session and whenever you choose to alter your base CAM/CAS configuration with the service perfigo config CLI command.
Figure 12-3 CAS Direct Access Web Admin Console Login Page
Step 2 Accept the temporary certificate and log in as user admin with the associated password.
Figure 12-4 CAS Direct Access Web Admin Console—Cisco NAC-3300 Series
Note Because Cisco NAC network modules installed in Cisco Integrated Services Routers (ISRs) do not support high availability, the Failover tab is not available when you view the direct web admin console for a Cisco NAC network module.
Figure 12-5 CAS Direct Access Web Admin Console—Cisco NAC Network Module
Note•Make sure to precede the CAS IP address with "https://" and append it with "/admin"; otherwise you will see the redirect page for web login users.
•For security purposes, Cisco recommends changing the password for the CAS web console.
Note that almost all of the settings in the CAS web console can be configured via the CAS management pages in the CAM web admin console, with the exception of the Failover, SSL, Admin Password, and Support Logs. The CAS direct access web console provides the following Administration pages for the local CAS:
•Network Settings—IP, DNS, and Failover (Cisco NAC-3300 Series only)
•Software Update
•SSL (Generate Temporary Certificate, Import Certificate, Export CSR/Private Key/Certificate, and view and remove existing Trusted CAs)
•Time Server
•Admin Password
The Monitoring module of the CAS direct access console provides the following pages:
•Active VPN Clients
•Support Logs
Note For High Availability CAS pairs, any CAS network setting changes performed on an HA-Primary CAS through the CAS management pages or CAS direct access web console must also be repeated on the standby CAS unit through its direct access web console. These settings include updating the SSL certificate, system time, time zone, DNS, or Service IP. See IP Form, page 5-12 and Modifying High Availability Settings, page 13-27 for details.
Manage CAS SSL Certificates
This section describes the following:
•SSL Certificate Overview
•Typical SSL Certificate Setup on the CAS
•Generate Temporary Certificate
•Generate and Export a Certification Request
•Manage Signed Certificate/Private Key
•Manage Trusted Certificate Authorities
•View Current Private Key/Certificate and Certificate Authority Information
•SSL Requirements for Mac OS X/CAS Communication
•Troubleshooting Certificate Issues
SSL Certificate Overview
The elements of Cisco NAC Appliance communicate securely over Secure Socket Layer (SSL) connections. Cisco NAC Appliance uses SSL connections for a number of purposes, including the following:
•Secure communications between the CAM and the CAS
•Policy Import/Export operations between Policy Sync Master and Policy Sync Receiver CAMs
•CAM-to-LDAP authentication server communications where SSL has been enabled for the LDAP authentication provider using the Security Type option on the User Management > Auth Servers > New | Edit page
•Between the CAS and end-users connecting to the CAS
•Between the CAM/CAS and the browsers accessing the CAM/CAS web admin consoles
During installation, the configuration utility script for both the CAM and CAS requires you to generate a temporary SSL certificate for the appliance being installed (CAM or CAS). A corresponding Private Key is also generated with the temporary certificate.
For the Clean Access Manager and Clean Access Servers operating strictly in a lab environment, it is not necessary to use a CA-signed certificate and you can continue to use a temporary certificate, if desired. For security reasons in a production deployment, however, you must replace the temporary certificate for the CAM and CAS with a third-party CA-signed SSL certificate.
For details on managing SSL certificates for the CAM, see the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.6(1).
Note Cisco NAC Appliance only supports 1024- and 2048-bit RSA key lengths for SSL certificates.
This Overview section discusses the following topics:
•Web Console Pages for SSL Certificate Management
•CA-Signed Certificates
•Intermediary Certificates
•Certificates for High Availability (HA) Pairs
•Regenerating Certificates for DNS Name Instead of IP
Web Console Pages for SSL Certificate Management
CAM SSL certificate files are kept on the CAM machine, and CAS SSL certificate files are kept on the CAS machine. The CAS certificate can be managed from:
•Administration > SSL > X509 Certificate—Use this configuration window to import and export temporary or CA-signed certificates and Private Key, and to generate new temporary certificates
•Administration > SSL > Trusted Certificate Authorities—Use this configuration window to view, add, and remove Certificate Authorities on the CAS
•Administration > SSL > X509 Certification Request—Use this configuration window to generate a new CA-signed certificate request for the CAS
For additional web console access information, refer to Clean Access Server Direct Access Web Console.
Note For High Availability CAS pairs, any CAS network setting changes performed on an HA-Primary CAS through the CAS management pages or CAS direct access web console must also be repeated on the standby CAS through its direct access web console. These settings include updating the SSL certificate, system time/time zone, DNS, or Service IP. See Modifying High Availability Settings, page 13-27 for details.
CA-Signed Certificates
The CAS SSL certificate is used for communication between the CAS and the user's web browser and/or Agent, and for communication between the CAM and CAS. In a production deployment, you must replace the temporary certificate for the Clean Access Server with a third-party CA-signed SSL certificate. Cisco NAC Appliance provides a tool to generate and export a Certificate Signing Request (CSR) that you can send to your Certificate Authority on the Administration > SSL > X509 Certification Request page. The following reasons highlight the need to obtain and import a third-party CA-signed certificate on the CAS:
•The CAS certificate is visible to the end user. If the CAS has a temporary certificate, users have to explicitly accept the certificate from the CAS each time they login.
•The root certificate needs to be trusted by the client machine.
Note The CAM and CAS require encrypted communication. Therefore, the CAM must contain the Trusted Certificate Authorities from which the certificates on all of its managed CASs originate, and all CASs must contain the same Trusted Certificate Authority from which the CAM certificate originates before deploying Cisco NAC Appliance in a production environment.
•With public certification authorities (Thawte, Verisign, etc.), the root already exists on the client machine.
•For client machines running Windows Vista and/or Internet Explorer 7.0, Certificate Revocation List (CRL) checking is enabled by default. Cisco recommends obtaining a CA-signed certificate for the CAS if supporting Windows Vista/IE 7.0 client machines. For further details, see the Agent Error: "Network Error SSL Certificate Rev Failed 12057" section of the Release Notes for Cisco NAC Appliance, Version 4.6(1).
•For details on Mac OS X Agent certificates, refer to SSL Requirements for Mac OS X/CAS Communication.
•Temporary certificates are designed for lab environments only. When you deploy your CAS in a production environment, Cisco strongly recommends using a trusted certificate from a third-party Certificate Authority to help ensure network security.
Note If present on the CAS, you will see messages on the CAS web console (Figure 12-6) warning that the "EMAILADDRESS=info@perfigo.com, CN=www.perfigo.com, OU=Product, O="Perfigo, Inc.", L=San Francisco, ST=California, C=US" certificate authority can render your CAS and associated client machines vulnerable to security attacks. To locate and remove this certificate authority from the CAS database, use the instructions in Manage Trusted Certificate Authorities.
Figure 12-6 Administrator Web Console Messages Warning to Obtain Trusted Certificate Authority and Remove Existing "www.perfigo.com" Certificate
In a strictly lab environment, it is not necessary to use a CA-signed certificate and you can continue to use a temporary certificate for the CAM and CAS, if desired. If you deploy your CAM and CAS in a production environment, however, you must use a third-party Trusted CA. For details on managing SSL certificates for the CAM, see the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.6(1).
Note You cannot use a CA-signed certificate that you bought for the Clean Access Manager on the Clean Access Server. You must buy a separate certificate for each Clean Access Server.
Any certificate that is not provided by a public CA or that is not the self-signed certificate is considered a non-standard certificate by the CAS.
Certification Authorities
A Certification Authority (CA) can be public (e.g. Thawte, Verisign) or private.
With a Public CA:
•You submit your CSR to the public CA and request a Webserver type or SSL type of certificate.
•Your CA should provide you a certificate based on the CSR.
•You can also request the CA's root or public key.
•Note that the CAM/CAS already have the public keys (root) of the most common public CAs.
With a Private CA:
•You can submit your CSR to a private or local CA such as Microsoft CA server.
•The private CA server provides the Certificate and root (Public key).
•However, this root will need to be loaded to CAM/CAS.
Intermediary Certificates
When one or more Intermediary CAs are involved, you will have multiple root certificates or public keys. Each CA has its own root. The root/public key information of all certification authorities in the chain needs to be combined into one single file (for example, root.cer) before it can be uploaded into the CAS. To do this, open the root certificate of each CA and copy the information from each root cert into Wordpad or a similar text editor. Include the "Begin Certificate" and "End Certificate' lines for each CA cert, and put each certificate one right after the other in the text file. Save this compiled root.cer file, then import it into the CAS.
Certificates for High Availability (HA) Pairs
If you are running HA-CAS pairs, you must generate the CSR for the Service IP of the HA pair and import the CA-signed certificate into one of the HA pairs (e.g. CAS-1). After that, the certificate information, i.e. the Private Key, Certificate, and Root, will need to be exported from the HA-Primary CAS and imported into the HA-Secondary CAS. Refer to Chapter 13, "Configuring High Availability (HA)" for more information.
Regenerating Certificates for DNS Name Instead of IP
If planning to regenerate certificates based on the DNS name instead of the IP address of your servers:
•When you are generating a CSR for signing, always export and save the Private Key to a secure location (for safekeeping and to have the Private Key handy). Make sure the CA-signed certificate you are importing is the one with which you generated the CSR and that you have NOT subsequently generated another temporary certificate. Generating a new temporary certificate after you have exported the CSR will create a new private-public key combination, and the new Private Key will no longer match the CA-signed certificate.
•When importing certain CA-signed certificates, the system may warn you that you need to import the root certificate (the CA's root certificate) used to sign the CA-signed certificate, or the intermediate root certificate may need to be imported.
•Make sure there is a DNS entry in the DNS server.
•Make sure the DNS address in your Clean Access Server is correct (see Configure DNS Servers on the Network, page 5-25).
•For High-Availability (failover) configurations, use the DNS name for the Service IP (virtual DNS).
•When using a DNS-based certificate, if it is not CA-signed, the user is typically prompted to accept the certificate.
Typical SSL Certificate Setup on the CAS
The typical steps for managing CAS certificates are as follows:
Phase 1: Establish SSL Communication Between the CAS and CAM
Step 1 Synchronize time
After CAM and CAS installation, make sure the time on the CAM and CAS is synchronized (within 3-5 minutes) before regenerating the temporary certificate on which the Certificate Signing Request will be based. See the next section, Synchronize System Time, for details.
Step 2 Check DNS settings for the CAS
If planning to use the DNS name instead of the IP address of your servers for CA-signed certificates, you will need to verify the CAS settings and regenerate a temporary certificate. See Regenerating Certificates for DNS Name Instead of IP for details. For HA systems, you'll need to regenerate the certificates based on Service IP (see Generate Temporary Certificate).
Step 3 Generate Temporary Certificate
During initial CAS installation/configuration, a temporary certificate and Private Key are automatically generated. If changing time or DNS settings on the CAM, regenerate the temporary certificate and Private Key.
Phase 2: Set Up Your CAS and CAM For Production Deployment
Warning If your previous deployment uses a chain of SSL certificates that is incomplete, incorrect, or out of order, CAM/CAS communication may fail after upgrade to release 4.5 and later. You must correct your certificate chain to successfully upgrade to release 4.5 and later. For details on how to fix certificate errors on the CAM/CAS after upgrade to release 4.5 and later, refer to the How to Fix Certificate Errors on the CAM/CAS After Upgrade Troubleshooting Tech Note.
Step 4 Export (Backup) the certificate and Private Key to a local machine for safekeeping.
If you are altering your Cisco NAC Appliance SSL configuration, it is always a good idea to back up the certificate and Private Key corresponding to the current certificate to a local hard drive for safekeeping. See Generate and Export a Certification Request.
Step 5 Export (save) the Certificate Signing Request (CSR) to a local machine. (See Generate and Export a Certification Request.)
Step 6 Send the CSR file to a Certification Authority (CA) authorized to issue trusted certificates.
Step 7 After the CA signs and returns the certificate, import the CA-signed certificate to your server.
When the CA-signed certificate is received from the CA, upload it as PEM-encoded file to the CAS temporary store. See Manage Signed Certificate/Private Key.
Step 8 If present on the CAS, locate and remove the "EMAILADDRESS=info@perfigo.com, CN=www.perfigo.com, OU=Product, O="Perfigo, Inc.", L=San Francisco, ST=California, C=US" certificate authority from the CAS database using the instructions in Manage Trusted Certificate Authorities.
Note Cisco strongly recommends removing this certificate authority before deploying your CAS in a production environment. If you are not deploying your CAS in a production environment, you can choose whether or not to remove this certificate authority.
Note The CAM and CAS require encrypted communication. Therefore, the CAM must contain the Trusted Certificate Authorities from which the certificates on all of its managed CASs originate, and all CASs must contain the same Trusted Certificate Authority from which the CAM certificate originates before deploying Cisco NAC Appliance in a production environment.
Step 9 If necessary, upload any required intermediate CA certificate(s) as a single PEM-encoded file to the CAS temporary store (see Intermediary Certificates).
Step 10 Test as a client accessing the Clean Access Server.
Phase 3: Adding a New CAM or CAS to an Existing Production Deployment
In production deployments, CA-signed certificates are used exclusively and the "www.perfigo.com" Certificate Authority is completely removed. Because the temporary "www.perfigo.com" CA is needed for initial installation, use the following steps when introducing new appliances (CAM or CAS) to a production deployment. The new appliance should not be added to the deployment until you have requested and are able to import a new third-party CA-signed certificate.
Step 1 Install and initially configure the new appliance as described in Chapter 4, "Installing the Clean Access Server."
Step 2 Follow the steps in Phase 1: Establish SSL Communication Between the CAS and CAM
Step 3 Generate a CSR for the new appliance, as described in Generate and Export a Certification Request.
Step 4 Obtain and install the CA-signed certificate as described in Import Signed Certificate/Private Key.
Step 5 Remove the "www.perfigo.com" Certificate Authority from the new appliance as described in Manage Trusted Certificate Authorities.
Step 6 Add the appliance to your existing production environment.
Generate Temporary Certificate
The following procedure describes how to generate a new temporary certificate for the CAS. Any time you change basic configuration settings on the CAM (date, time, associated DNS server, etc.) you should generate a new temporary certificate. See Regenerating Certificates for DNS Name Instead of IP for additional details.
Note Before generating a certificate on the CAS, ensure you enter the CAS distinguished name (DN) in the CAM Device Management > CCA Servers > Authorization web console page.
Caution If you are using a CA-signed certificate, Cisco recommends backing up the current Private Key for the current certificate prior to generating any new certificate, as generating a new certificate also generates a new Private Key. See
Generate and Export a Certification Request for more information.
Step 1 Go to Administration > SSL > X509 Certificate.
Step 2 Click Generate Temporary Certificate to expose the fields required to construct a temporary certificate (Figure 12-7).
Figure 12-7 Administration > SSL > X509 Certificate—Generate Temporary Certificate
Step 3 Enter appropriate values for the form fields:
•Full Domain Name or IP - Either the fully qualified domain name (FQDN) or the IP address of the CAS for which the certificate applies, for example: caserver.<your_domain_name>.
–If using an IP-based certificate, generate the certificate based on the Trusted Interface IP address (eth0) of the CAS.
Note If the CAS is configured as an L3 Real-IP Gateway, generate the certificate based on the Untrusted Interface (eth1) IP address of the CAS.
–If using a domain name, make sure that your DNS server can resolve the "Full Domain Name" entered.
Note To support the Mac OS X Agent, the CAS/CAM must use the FQDN as the "subject" DN on the certificate (this is the "Full Domain Name or IP" on the CAS/CAM console). An IP address is not allowed. Refer to SSL Requirements for Mac OS X/CAS Communication for details.
•Organization Unit Name - The name of the unit within the organization, if applicable.
•Organization Name - The legal name of the organization.
•City Name - The city in which the organization is legally located.
•State Name - The full name of the state in which the organization is legally located.
•2-letter Country Code - The two-character, ISO-format country code, such as GB for Great Britain or US for the United States.
Step 4 Specify whether you want the new temporary certificate to use a 1024- or 2048-bit RSA Key Size.
Step 5 When finished, click Generate. This generates a new temporary certificate and new Private Key.
Note The CCA Server Certificate entry at the top of the certificate display table specifies the full distinguished name of the current CAS SSL certificate. You are required to enter the full distinguished name of the CAS in the CAM web console if you are setting up Authorization between your CAM and CASs. For more information, see Configure Clean Access Server-to-Clean Access Manager Authorization, page 5-7.
Generate and Export a Certification Request
Generating a CSR creates a PEM-encoded PKCS#10-formatted Certificate Signing Request (CSR) suitable for submission to a certificate authority. Before you send the CSR, make sure to export the existing certificate and Private Key to a local machine to back it up for safekeeping.
To export he CSR/Private Key and create a certificate request from the CAS web console:
Step 1 Go to Administration > SSL > X509 Certification Request (Figure 12-8).
Figure 12-8 Administration > SSL > X509 Certification Request
Step 2 Click Generate Certification Request to expose the fields required to construct a certificate request.
Step 3 Type appropriate values for the following fields:
•Full Domain Name or IP—The fully qualified domain name or IP address of the Clean Access Manager for which the certificate is to apply. For example: camanager.<your_domain_name>
Note If requesting a CA-signed certificate for a CAS HA-pair, the CA-signed certificate must either be based on the Service IP or a host name/domain name resolvable to the Service IP through DNS.
•Organization Unit Name—The name of the unit within the organization, if applicable.
•Organization Name—The legal name of the organization.
•City Name—The city in which the organization is legally located.
•State Name—The full name of the state in which the organization is legally located.
•2-letter Country Code—The two-character, ISO-format country code, such as GB for Great Britain or US for the United States.
Step 4 Specify whether you want the new temporary certificate to use a 1024- or 2048-bit RSA Key Size.
Note Cisco NAC Appliance only supports 1024- and 2048-bit RSA key lengths for SSL certificates.
Step 5 Click Generate to generate a certificate request and Private Key pair. Make sure these are the ones for which you want to submit the CSR to the certificate authority.
Step 6 Before you submit the new CSR to the Certificate Authority, save the new certification request and Private Key used to generate the request to your local machine by enabling the checkboxes for the Certification Request and/or Private Key and clicking Export. You are prompted to save or open the file (see Default File Names for Exported Files). Save it to a secure location. Use the CSR file to request a certificate from a certificate authority. When you order a certificate, you may be asked to copy and paste the contents of the CSR file into a CSR field of the order form.
Alternatively, you can immediately Open the CSR in Wordpad or a similar text editor if you are ready to fill out the certificate request form, but Cisco strongly recommends you also save a local copy of the CSR and Private Key to ensure you have them should the request process suffer some sort of mishap or your CAM basic configuration change between submitting the CSR and receiving your CA-signed certificate.
When you receive the CA-signed certificate back from the certification authority, you can import it into the Clean Access Server as described in Manage Signed Certificate/Private Key. After the CA-signed cert is imported, the "currently installed certificate" is the CA-signed certificate. You can always optionally Export the currently installed certificate if you need to access a backup of this certificate later.
Default File Names for Exported Files
The default file names for SSL Certificate files that can be exported from the CAS are as follows. When you actually save the file to your local machine, you can specify a different name for the file. For example, to keep from overwriting your chain.pem file containing your certificate chain information, you can specify your Private Key filename to be a more appropriate name like priv_key.pem or something similar.
|
|
Description
|
cert_request.pem
|
CAS Certificate Signing Request (CSR)
|
chain.pem2
|
CAS Currently Installed Private Key and/or Certificate
|
Manage Signed Certificate/Private Key
Import Signed Certificate/Private Key
You can import CA-signed PEM-encoded X.509 Certificates and Private Keys using the CAS web console. (Typically, you only need to re-import the Private Key if the current Private Key does not match the one used to create the original CSR on which the CA-Signed certificate is based.) There are two methods administrators can use to import CA-signed certificates, Private Keys, and associated Certificate Authority information into Cisco NAC Appliance:
1. Import the Certificate Authorities and the End Entity Certificates/Private Keys separately:
a. Import the Certificate Authorities into the trust store using the procedures in Manage Trusted Certificate Authorities
b. Import the CAS's end entity certificate and/or Private Key using the instructions below
2. Construct a PEM-encoded X.509 certificate chain (including the Private Key and End Entity, Root CA, and Intermediate CA certificates) and import the entire chain at once using the instructions below
If you have received a CA-signed PEM-encoded X.509 certificate for the Clean Access Server, you can also import it into the Clean Access Server as described here.
Before starting, make sure that the root and CA-signed certificate files are in an accessible file directory location and that you have obtained third-party certificates for both your CAM and CASs. If using a Certificate Authority for which intermediate CA certificates are necessary, make sure these files are also present and accessible if not already present on the CAS.
Note If obtaining a CA-signed certificate for a CAS HA-Pair, the CA-signed certificate must either be based on the Service IP or a host name/domain name resolvable to the Service IP through DNS.
Note Any certificate that is not provided by a public CA or that is not the self-signed certificate is considered a non-standard certificate by the CAM/CAS. When importing certificates to the CAS, make sure to obtain CA-signed certificates for authentication servers.
To import a certificate and/or Private Key for the CAS:
Step 1 Go to Administration > SSL > X509 Certificate (see Figure 12-9).
Figure 12-9 Administration > SSL > X509 Certificate—Import Certificate
Step 2 Click Browse and locate the certificate file and/or Private Key on your local machine.
Note Make sure there are no spaces in the filename when importing files (you can use underscores).
Step 3 Click Import.
Note Neither the CAM nor CAS will install an unverifiable certificate chain. You must have delimiters (BEGIN/END CERTIFICATE) for multiple certificates in one file, but you do not need to upload certificate files in any particular sequence because they are verified in the temporary store first before being installed.
If you already have other members of the certificate chain in the CAS trust store, you do not need to re-import them. The CAS can build the certificate chain from a combination of newly-imported and existing parts.
If you try to upload a root/intermediate CA certificate for the CAM that is already in the list, you may see an error message reading "This intermediate CA is not necessary." In this case, you must delete the uploaded Root/Intermediate CA in order to remove any duplicate files.
Export Certificate and/or Private Key
To backup your certificate and/or Private Key in case of system failure or other loss, you can export your certificate and/or Private Key information and save a copy on your local machine. This practice also helps you manage certificate/Private Key information for a CAS HA-Pair. By simply exporting the certificate information from the HA-Primary CAS and importing it on the HA-Secondary CAS, you are able to push an exact duplicate of the certificate info required for CAM/CAS communication to the standby CAS.
Step 1 Go to Administration > SSL > X509 Certificate (Figure 12-9).
Step 2 To export existing certificate/Private Key information:
a. Select one or more certificates and/or the Private Key displayed in the certificates list by clicking on their respective left hand checkboxes.
b. Click Export and specify a location on your local machine where you want to save the resulting file.
Manage Trusted Certificate Authorities
You can locate and remove Trusted CAs from the CAS database using the Administration > SSL > Trusted Certificate Authorities CAS web console page. To keep your collection of trusted certificate authority Cisco recommends keeping only trusted certificate authority information critical to Cisco NAC Appliance operations in the CAM trust store.
Caution If present on the CAS, the "EMAILADDRESS=info@perfigo.com, CN=www.perfigo.com, OU=Product, O="Perfigo, Inc.", L=San Francisco, ST=California, C=US" certificate authority can render your CAS and associated client machines vulnerable to security attacks. Before deploying your CAS in a production environment, you
must remove this certificate authority from the CAS database. Cisco recommends searching for the string "www.perfigo.com" using the
Filter options described below to quickly locate and remove this certificate authority from your CAS.
To view and/or remove Trusted CAs from the CAS:
Step 1 Go to Administration > SSL > Trusted Certificate Authorities (Figure 12-10).
Figure 12-10 Administration > SSL > Trusted Certificate Authorities
Viewing Trusted CAs
Step 2 If you want to refine the list of Trusted CAs displayed in the CAS web console:
a. Choose an option from the Filter dropdown menu:
–Distinguished Name—Use this option to refine the list of Trusted CAs according to whether the Trusted CA name contains or does not contain a specific text string.
–Time—Use this option to refine the display according to which Trusted CAs are currently valid or invalid.
You can also combine these two options to refine the Trusted CAs display.
b. Click the Filter button after selecting and defining parameters for the search options to display a refined list of all Trusted CAs that match the criteria.
You can click Reset to negate any of the optional search criteria from the filter dropdown menu and return the Trusted CA display to default settings.
c. You can also increase or decrease the number of viewable items in the Trusted CAs list by choosing one of the options in the dropdown menu at the top-left of the list. The options are 10, 25, or 100 items.
d. If you want to view details about an existing Trusted CA, click the View button (far-right magnifying glass icon) to see information on the specific certificate authority, as shown in Figure 12-11.
Figure 12-11 Trusted Certificate Authority Information
Removing Trusted CAs
Step 3 Select one or more Trusted CAs to remove by clicking on the checkbox for the respective Trusted CA in the list. (Clicking on the empty checkbox at the top of the Trusted CAs display automatically selects or unselects all Trusted CAs in the current list.)
Step 4 Click Delete Selected.
Once the CAS removes the selected Trusted CAs from the database, the CAS automatically restarts services to complete the update.
Import/Export Trusted Certificate Authorities
You can also use the Trusted Certificate Authorities web console page to import and export certificate information for the CAS.
Note For standard certificate import and export guidelines, refer to Generate and Export a Certification Request and Manage Signed Certificate/Private Key.
Step 1 Go to Administration > SSL > Trusted Certificate Authorities.
Step 2 To import a Trusted Certificate Authority:
a. Ensure you have the appropriate certificate file accessible to the CAS in the network and click Browse.
b. Locate and select the certificate file on your directory system and click Open.
c. Click Import to upload the Trusted Certificate Authority information to your CAS.
Step 3 To export existing Trusted Certificate Authority information:
a. Select one or more Trusted CAs displayed in the Trusted Certificate Authorities list by clicking on their respective left hand checkboxes.
b. Click Export and specify a location on your local machine where you want to save the resulting "caCerts" file.
View Current Private Key/Certificate and Certificate Authority Information
You can verify the following files by viewing them under Administration > SSL > X509 Certificate (see Figure 12-8):
•Currently Installed Private Key
•Currently Installed End Entity, Root, and Intermediate CA Certificate
•Certificate Authority Information
Note You must be currently logged into your web console session to view any Private Key and/or certificate files.
View Currently Installed Private Key
You can view the CAM Private Key by exporting and opening the exported Private Key file in Wordpad or a similar text editor tool to bring up a dialog like the one in Figure 12-12 (BEGIN PRIVATE KEY/END PRIVATE KEY).
Figure 12-12 View Currently Installed Private Key
You can also use this method to view uploaded Private Keys before importing them into your CAM.
View Currently Certificate or Certificate Chain
You can view CAS Private Key and End Entity, Root CA, and Intermediate CA certificates by exporting and opening the saved file in Wordpad or a similar text editor tool to bring up a dialog like the one in Figure 12-13 (BEGIN CERTIFICATE/END CERTIFICATE).
Figure 12-13 View Currently Installed Certificate
You can also use this method to view uploaded certificates before importing them into your CAM.
View Certificate Authority Information
You can view Certificate Authority information for CAM End Entity, Root, and Intermediate CA Certificates by clicking on the respective View icon (magnifying glass) in the right hand column to bring up a dialog like the one in Figure 12-14.
Figure 12-14 View Certificate Authority Information
SSL Requirements for Mac OS X/CAS Communication
For the Mac OS X Agent to communicate with the Clean Access Server, the SSL communication between the Agent and CAS must meet certain requirements. The CAS must have one of the following:
•A valid name-based CA-signed certificate (from a trusted Certificate Authority)
•A name-based temporary certificate that meets the requirements described below
Note Ensure DNS can also resolve all name-based certificates.
CAS Temporary Certificate Requirements for SSL Connection to Mac OS X Agent
If using a temporary certificate for the CAS, make sure the following are in place:
Step 1 The CAS/CAM must use a fully qualified domain name (FQDN) as the "subject" DN on the certificate (this is the "Full Domain Name or IP" on the CAS/CAM console). An IP address is not allowed. This may require regenerating the certificate on your CAS. (See Generate Temporary Certificatefor details.)
Step 2 On the Mac OS X machine, the root certificate which is used to sign the temporary certificate must be installed in the X509 Anchors in Keychain Access application. To do this, use one of the following set of steps for the Mac OS X version running on the machine:
•Installing the Root Certificate for Mac OS 10.4.x
•Installing the Root Certificate for Mac OS 10.5
Step 3 The Mac OS X machine must be able to correctly resolve the FQDN name via DNS. There are two approaches to this:
a. Add an entry into the DNS server which the Mac machine is using, or
b. For a test machine:
1. Enable your root account as described in Enable the Root User on Mac OS X
2. Edit the /etc/hosts file on the Macintosh client machine by running sudo vi /etc/hosts to add a new domain lookup entry.
Caution Because the CAS/CAM use the full domain name, you cannot use an IP address in the certificate. You must use the domain name instead.
Caution Make sure your machine's date and time are valid for the certificate. If the current date and time fall out of the range of the certificate, the Agent will not work.
Installing the Root Certificate for Mac OS 10.4.x
Note You must have administrative permissions on your computer in order to run these steps.
Step 1 Download the root certificate to your client machine (or desktop). See Obtaining the Root Certificate from the CAS for details.
Step 2 Click the Finder icon in the Dock.
Step 3 From the Go menu, choose Applications.
Step 4 Open the Utilities folder.
Step 5 Launch the Keychain Access application.
Step 6 Drag the root certificate to the Keychain Access application.
Step 7 In the Add Certificates dialog box, click X509 Anchors and click OK.
Step 8 The root certificate is added (Figure 12-15).
Figure 12-15 Root Certificate Added on Mac OS 10.4.x
Installing the Root Certificate for Mac OS 10.5
Note You must have administrative permissions on your computer in order to run these steps.
Step 1 Download the root certificate to your client machine (or desktop). See Obtaining the Root Certificate from the CAS for details.
Step 2 Click the Finder icon in the Dock.
Step 3 From the Go menu, choose Applications.
Step 4 Open the Utilities folder.
Step 5 Launch the Keychain Access application.
Figure 12-16 Launch Keychain Access Application on Mac OS 10.5
Step 6 Drag the root certificate to the Keychain Access application.
Figure 12-17 Drag and Drop the Certificate Into the Keychain Access Application on Mac OS 10.5
Step 7 Click Always Trust in the Certificate dialog.
Figure 12-18 Certificate Dialog on Mac OS 10.5
Step 8 The root certificate is added (Figure 12-19).
Figure 12-19 Display the New Root Certificate on Mac OS 10.5
Enable the Root User on Mac OS X
Note Ensure you are an administrator on the machine. You must have access to an account that has administrator privileges to perform the rest of these steps.
Step 1 Click the Finder icon in the Dock.
Step 2 From the Go menu, choose Applications.
Step 3 Open the Utilities folder.
Step 4 Open the NetInfo Manager utility.
Step 5 Click the lock in the NetInfo Manager window (or go to Security > Authenticate).
Step 6 Type your administrator account username and password and click OK.
Step 7 For Mac OS 10.4.x, choose Enable Root User from the Security menu (Figure 12-20).
Figure 12-20 Enable Root User (Mac OS 10.4.x)
For Mac OS 10.5, launch Applications > Utilities > Directory Utility.app (Figure 12-21) and choose Enable Root User from the Edit menu (Figure 12-22).
Figure 12-21 Enable Root User > (Mac OS 10.5)
Figure 12-22 Enable Root User > Edit (Mac OS 10.5)
Step 8 Type a password for root to enable the root account. If you have not previously set a root password, an alert box may appear that says "NetInfo Error," indicating that the password is blank. Click OK.
Step 9 Type the root password you wish to use and click Set.
Step 10 Retype the password for verification and click Verify.
Step 11 The root user is now enabled.
Step 12 Click the lock again to prevent changes.
Note For additional reference, see http://docs.info.apple.com/article.html?artnum=106290#one.
For more information on the Mac OS X Agent, see the "Mac OS X Agent Dialogs" section of the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.6(1).
Obtaining the Root Certificate from the CAS
Because Internet Explorer allows exporting of the CAS certificate, this section describes how to obtain the root certificate on a Windows system. Administrators can then transfer the certificate to their Mac via email as an attachment, FTP, or USB storage device.
There are three ways to retrieve the root certificate:
•Get the Root Certificate From the Mac OS X Agent Bundle
•Transfer the Root Certificate from Windows Using Internet Explorer
•Use Web Login to Get the Root Certificate
Get the Root Certificate From the Mac OS X Agent Bundle
Step 1 In the Finder, go to /Applications/CCAAgent.app.
Step 2 Ctrl-click on the CCAAgent.app to display the context menu.
Step 3 Choose Show Package Contents and search for the "perfigoca.crt" certificate in the /Contents/Resources/ folder.
Step 4 Drag and drop the "perfigoca.crt" certificate to the keychain.
For more information, see SSL Requirements for Mac OS X/CAS Communication.
Transfer the Root Certificate from Windows Using Internet Explorer
If the temporary certificate has not yet been installed on the Windows system:
Figure 12-23 illustrates the steps to initially download the temporary certificate.
1. Open an IE browser and enter any address. The browser will redirect to the authentication page for web login.
2. Since the certificate has not been installed, the Security Alert dialog pops up from the browser. Click the View Certificate button in the Security Alert dialog.
3. Click the Details tab in the Certificate window that pops up.
4. Click the Copy to File button in the Details tab
5. Leave format option as DER encoded binary x.509 (.CER) on the Certificate Export Wizard and click Next to save the certificate on the Windows system.
6. Transfer the certificate to your Mac machine.
Figure 12-23 Download Certificate Option 1
If the browser already has the temporary certificate installed:
Figure 12-24 illustrates the steps to download the certificate if already installed on the system.
1. Open the IE browser.
2. Go to Tools > Internet Options. Click the Content tab then the Certificates button.
3. Click the Intermediate Root Certificate Authorities tab in the Certificates window.
4. Highlight the certificate issued by www.perfigo.com and click the Export button.
5. Choose a location on your Windows machine to save the certificate.
6. Transfer the certificate to your Mac machine.
Figure 12-24 Download Certificate Option 2
Use Web Login to Get the Root Certificate
Step 1 Change the CAM settings to enable the Root CA Label option (in the Administration > User Pages > Login Page > Edit > Content CAM web console configuration page). This shows the link to download the root certificate from the user login page in the browser.
Step 2 When users open a browser and go to the login page, they will see a link for downloading the root certificate. Instruct users to click on the link and save the "perfigoca.crt" certificate on their local client machine.
Step 3 Obtain the certificate from the user and drag and drop the "perfigoca.crt" certificate to the keychain.
For more information, see the guidelines "Administering the CAM" chapter in the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.6(1).
Troubleshooting Certificate Issues
There can be issues with Cisco NAC Appliance certificate management if there are mismatched SSL certificates somewhere along the certificate chain. Common problems on SSL certificates can be time-oriented (if the clocks are not synchronized on the CAM and CAS, authentication fails), IP-oriented (certificates are created for the wrong interface) or information-oriented (wrong or mistyped certificate information is imported). This section describes the following troubleshooting topics:
•CAS Cannot Establish Secure Connection to CAM
•Private Key in Clean Access Server Does Not Match the CA-Signed Certificate
•Certificate-Related Files
Warning If your previous deployment uses a chain of SSL certificates that is incomplete, incorrect, or out of order, CAM/CAS communication may fail after upgrade to release 4.5 and later. You must correct your certificate chain to successfully upgrade to release 4.5 and later. For details on how to fix certificate errors on the CAM/CAS after upgrade to release 4.5 and later, refer to the How to Fix Certificate Errors on the CAM/CAS After Upgrade Troubleshooting Tech Note.
CAS Cannot Establish Secure Connection to CAM
If clients attempting login get the following error message, "Clean Access Server could not establish a secure connection to the Clean Access Manager at <IPaddress or domain> (see Figure 12-25), this commonly indicates one of the following issues:
•The time difference between the CAM and CAS is greater than 5 minutes.
•Invalid IP address
•Invalid domain name
•CAM is unreachable
The time set on the CAM and the CAS must be 5 minutes apart or less. To resolve this issue:
1. Set the time on the CAM and CAS correctly first (see Synchronize System Time)
2. Regenerate the certificate on the CAS using the correct IP address or domain.
3. Reboot the CAS.
4. Regenerate the certificate on the CAM using the correct IP address or domain.
5. Reboot the CAM.
Figure 12-25 Troubleshooting: "CAS Cannot Establish Secure Connection to CAM"
Note If you check nslookup and date from the CAS, and both the DNS and TIME settings on the CAS are correct, this can indicate that the caCerts file on the CAS is corrupted. In this case, Cisco recommends backing up the existing caCerts file from /usr/java/j2sdk1.4/lib/security/caCerts, overriding it with the file from /perfigo/common/conf/caCerts, then performing "service perfigo restart" on the CAS.
Private Key in Clean Access Server Does Not Match the CA-Signed Certificate
This issue can arise if a new temporary certificate is generated but a CA-signed certificate is returned for the CSR (certificate signing request) generated from a previous temporary certificate and Private Key pair.
For example, an administrator generates a CSR, backs up the Private Key, and then sends the CSR to a CA authority, such as VeriSign.
Subsequently, another administrator regenerates a temporary certificate after the CSR has been sent. When the CA-signed certificate is returned from the CA authority, the Private Key on which the CA-certificate is based no longer matches the one in the Clean Access Server.
To resolve this issue, re-import the old Private Key and then install the CA-signed certificate.
Certificate-Related Files
For troubleshooting purposes, Table 12-1 lists certificate-related files on the Clean Access Server. For example, if the admin console becomes unreachable due to a mismatch of the CA-certificate/Private Key combination, these files may need to be modified directly in the file system of the Clean Access Server.
Table 12-1 Clean Access Server Certificate-Related Files
File
|
Description
|
/root/.tomcat.key
|
Private key
|
/root/.tomcat.crt
|
Certificate
|
/root/.tomcat.req
|
Certificate Signing Request
|
/root/.chain.crt
|
Intermediate certificate
|
/root/.perfigo/caCerts
|
The root CA bundle
|
System Upgrade
You can use the CAS web console to upload software upgrade images before extracting and installing the upgrade files via console/SSH. You must upgrade your Clean Access Manager and all your Clean Access Servers (including NAC Network Modules) concurrently. The Cisco NAC Appliance architecture is not designed for heterogeneous support (i.e., some Clean Access Servers running 4.6(1) software and some running release 4.5, 4.1(x), or 4.0(x) software).
Once a release is installed on the CAM and CAS, minor release upgrades to a more recent release can be performed on the CAS when patch upgrade images become available.
For complete upgrade details, including instructions for upgrading HA CASs and upgrades via SSH, refer to the "Upgrading to a New Software Release" section of the Release Notes for Cisco NAC Appliance, Version 4.6(1).
Step 1 Access the CAS software update web console page:
•Use the CAS web console Administration > Software Upload page (Figure 12-26).
Figure 12-26 CAS Web Console Software Upload
Step 2 Click Browse to locate the cca_upgrade-4.6.1-NO-WEB.tar.gz file you have downloaded from Cisco Secure Software. The upgrade mechanism automatically determines whether the machine is a Clean Access Server or a Lite/Standard/Super Clean Access Manager, and executes accordingly.
Step 3 Click Upload to upload the .tar.gz upgrade file to the CAS. Once you upload the upgrade image to the CAS, you must upgrade the appliance using the console/SSH upgrade instructions in the Release Notes for Cisco NAC Appliance, Version 4.6(1) to complete the upgrade process.
Step 4 Click the notes link if you want to view important upgrade information and display a summary of the new features, enhancements, and resolved caveats for the release (see Figure 12-27).
Figure 12-27 CAS Web Console Software Update—Notes
Step 5 Click on the link under List of Upgrade Logs to display a brief summary of the upgrade process including the date and time it was performed.
Step 6 Click on the link under List of Upgrade Details to display the details of the upgrade process, in the following format:
•state before upgrade
•upgrade process details
•state after upgrade
It is normal for the "state before upgrade" to contain several warning/error messages (e.g. "INCORRECT"). The "state after upgrade" should be free of any warning or error messages.
You can also use the CAM web console Device Management > CCA Servers > Manage [CAS_IP] > Misc > Upgrade Logs page (Figure 12-28) to view the CAS software upgrade notes:
•Click on the link under List of Upgrade Logs to display a brief summary of the upgrade process including the date and time it was performed.
•Click on the link under List of Upgrade Details to display the details of the upgrade process, in the following format:
Figure 12-28 CAS Upgrade Logs from CAM Web Console
Synchronize System Time
For logging purposes and other time-sensitive tasks (such as SSL certificate generation), the time on the Clean Access Manager and Clean Access Servers needs to be correctly synchronized. The Time form lets you set the time on the Clean Access Server and modify the time zone setting for the CAS operating system.
After CAM and CAS installation, you should synchronize the time on the CAM and CAS before regenerating a temporary certificate on which a Certificate Signing Request (CSR) will be based. The easiest way to ensure this is to automatically synchronize time with the time server (Sync Current Time button).
Note The time set on the CAS must fall within the creation date/expiry date range set on the CAM SSL certificate. The time set on the user machine must fall within the creation date /expiry date range set on the CAS SSL certificate.
Note For High Availability CAS pairs, any CAS network setting changes performed on an HA-Primary CAS through the CAS management pages or CAS direct access web console must also be repeated on the standby CAS unit through its direct access web console. These settings include updating the SSL certificate, system time/time zone, DNS, or Service IP. See Clean Access Server Direct Access Web Console and Modifying High Availability Settings, page 13-27 for details.
The time can be modified on the CAM under Administration > CCA Manager > System Time. See the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.6(1) for details.
To view the current time:
Step 1 Go to Device Management > CCA Servers > Manage [CAS_IP] > Misc > Time.
Step 2 The system time for the Clean Access Server appears in the Current Time field.
Figure 12-29 Time Form
There are two ways to adjust the system time—manually, by typing in the new time, or automatically, by synchronizing from an external time server.
To manually modify the system time:
Go to the Time form of the Misc tab and perform one of the following steps:
•Type the time in the Date & Time field and click Update Current Time. The time should be in the form: mm/dd/yy hh:ss PM/AM.
•Click the Sync Current Time button to have the time updated by the time servers listed in the Time Servers field.
To automatically synchronize with the time server:
The default time server is the server managed by the National Institute of Standards and Technology (NIST), at time.nist.gov. To specify another time server:
1. In the Time form of the Misc tab type the URL of the server in the Time Servers field. The server should provide the time in NIST-standard format. Use a space to separate multiple servers.
2. Click Update Current Time.
If more than one time server is listed, the CAS tries to contact the first server in the list when synchronizing. If available, the time is updated from that server. If it is not available, the CAS tries the next one, and so on, until a server is reached.
The CAS then automatically synchronizes the time with the configured NTP server at periodic intervals.
To change the time zone of the server system time:
1. In the Time form of the Misc tab, choose the new time zone from the Time Zone dropdown menu.
2. Click Update Time Zone.
Support Logs and LogLevel Settings
The Support Logs page on the Clean Access Server is intended to facilitate TAC support of customer issues. The Support Logs page allows administrators to combine a variety of system logs (such as information on open files, open handles, and packages) into one tarball that can be sent to TAC to be included in the support case. Administrators should download these support logs when sending their customer support request.
The Support Logs pages on the CAM web console and CAS direct access web console (Figure 12-30) allow you to configure the level of log detail recorded for troubleshooting purposes in /perfigo/access/tomcat/logs/nac_server.log. These web controls are intended as alternatives to using the CLI loglevel command to gather system information when troubleshooting.
For normal operation, the log level should always remain at the default setting (INFO). The log level is only changed temporarily for a specific troubleshooting time period—typically at the request of the customer support/TAC engineer. In most cases, the setting is switched from INFO to DEBUG for a specific interval, then reset to INFO after data is collected. Note that once you reboot the CAM/CAS, or perform the service perfigo restart command, the log level will return to the default setting (INFO).
Note Cisco recommends using the DEBUG and TRACE options only temporarily for very specific issues. Although the CAM records logging information and stores them in a series of nine 20MB files before discarding any old logs, the large amount of logging information can cause the CAM to run out of available log storage space in a relatively short amount of time.
Note To optimize memory usage, CAS support logs page are only available from the CAS direct access console under "Monitoring." (They are not available from the CAS management pages.)
Downloading CAS Support Logs
Step 1 Open the CAS direct access console from a browser using https://<CAS_eth0_IP_address>/admin as the URL/Address.
Step 2 Go to Monitoring > Support Logs (Figure 12-30).
Figure 12-30 CAS Support Logs
Step 3 Specify the number of days of debug messages to include in the file you will download for your Cisco customer support request.
Step 4 Click the Download button to download the cas_logs.<CAS_IP_address>.tar.gz file to your local computer.
Step 5 Send this .tar.gz file with your customer support request.
Note To retrieve the compressed support logs file for the Clean Access Manager, go to Administration > CCA Manager > Support Logs. See the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.6(1) for details.
If requested to do so by the TAC engineer, you can temporarily change the loglevel to obtain more troubleshooting details prior to downloading the support logs.
To changing the LogLevel for CAS logs:
Step 1 Open the CAS direct access console (https://<CAS_eth0_IP_address>/admin).
Step 2 Go to Monitoring > Support Logs.
Step 3 Choose the CAS log category to change:
•CCA Server General Logging: This category contains general logging events for this CAS not contained in the other three categories listed below. For example a user that logs in (needs to post request to the CAM) will be logged here.
•CAS/CAM Communication Logging: This category contains the majority of relevant logs: CAM/CAS configuration or communication errors specific to this CAS. For example, if the CAM's attempt to publish information to this CAS fails, the event will be logged here.
•Active Directory Communication Logging: This category contains logging information involving Active Directory events to support user Single Sign-On and credential look-up.
•SWISS Communication Logging: This category contains log events related to SWISS (proprietary communication protocol) packets sent between this CAS and the Agent.
Note To discover the CAS, the Agent sends SWISS (proprietary CAS-Agent communication protocol) packets on UDP port 8905 for L2 users and port 8906 for L3 users. The CAS always listens on UDP port 8905 and 8906 and accepts traffic on port 8905 by default. The CAS will drop traffic on UDP port 8906 unless L3 support is enabled. The Agent performs SWISS discovery every 5 seconds by default.
•Radius Accounting Proxy Server Logging: This category contains RADIUS accounting log events related to Single Sign-On (SSO) for this CAS when integrated with a Cisco VPN Server.
Step 4 Click the LogLevel setting for the category of log:
•OFF: No log events are recorded for this category.
•ERROR: A log event is written to /perfigo/access/tomcat/logs for the CAS, and /perfigo/control/tomcat/logs for the CAM only if the system encounters a severe error, such as:
–CAS cannot connect to CAM
–CAS and CAM cannot communicate
–CAS cannot communicate with database
•WARN: Records only error and warning level messages for the given category.
•INFO: Provides more details than the ERROR and WARN log levels. For example, if a user logs in successfully an Info message is logged. This is the default level of logging for the system.
•DEBUG: Records all debug-level logs for the CAS.
•TRACE: This is the maximum amount of log information available to help troubleshoot issues with the CAM/CAS.
Note Cisco recommends using the DEBUG and TRACE options only temporarily for very specific issues. Although the CAM records logging information and stores them in a series of nine 20MB files before discarding any old logs, the large amount of logging information can cause the CAM to run out of available log storage space in a relatively short amount of time.
