Chapter 14. ACS 4.2 Advanced Configuration

This chapter looks at advanced configuration components involved in ACS 4.2. The chapter provides detail on the components involved in replication and the options available for backup and restoring an ACS database. The chapter also covers bulk import of network resources and users. Finally, the chapter also examines features such as NAP and NAR.

Network Access Restrictions

Network Access Restrictions (NARs) provides an authorization condition that must be met before a user is allowed to access the network resources. On ACS, these conditions are applied based on information sent in attributes by AAA clients. Throughout this section you will gain a better understanding of NAR.

NAR on ACS can be configured either one of the following ways:

• On user or group: This option is available under the Advanced Settings and Access Restrictions sections, respectively as Network Access Restrictions (NAR). If the NAR option is not available, it can be enabled from the Interface Configuration > Advanced Options section. To enable NAR, you need to check User-Level Network Access Restrictions for user-level configuration and Group-Level Network Access Restrictions for group-level configuration.

• Using Shared Profile Components (SPC): Because NAR can also be configured from SPC, to enable it you need to again navigate to Interface Configuration and enable the User-Level Shared Network Access Restrictions and/or the Group-Level Shared Network Access Restrictions option.

When you first look at NAR, you will find two sections, Define IP-based access restrictions and Define CLI/DNIS-based access restrictions, as shown in Figure 14-1.

Figure 14-1. Network Access Restrictions

As you can see, there are two types of NARs available:

IP-based

CLI/DNIS (Non-IP) -based

Under both NARs, you have a set of conditions: AAA client, Port, Address (for IP-based) and AAA client, Port, CLI, DNIS (for CLI/DNIS-based). These parameters/attributes are ANDed to evaluate the condition.

At first glance, it is very clear what the attribute fields are and how to set them, but that does not end the story. Using the drop-down option available for each condition, you also need to define what action should be taken after a condition is matched. So, you must also choose whether the filter/condition operates positively or negatively as outlined in Table 14-1.

Table 14-1. NAR Permit and Deny Conditions

Although you now know the basics of how NAR works, there are still few unanswered questions. When does ACS decide to choose IP-based NAR or CLI/DNIS-based NAR? Or how does ACS retrieve attributes to build the filter/condition?

ACS selects IP-based or CLI/DNIS-based NAR depending on a simple condition that is protocol-dependent (TACACS+ or RADIUS).

A TACACS+/RADIUS session can be matched against IP-based NAR or CLI/DNIS-based NAR. Depending on the user session information, Cisco Secure ACS selects the following:

IP-based NAR when the rem_addr field in the TACACS+ start packet body or the calling-station-id (RADIUS attribute 31) in the RADIUS Access-Request packet contains a valid IP address

CLI/DNIS-based NAR in all other cases.

This answers the first question as to how ACS selects IP-based NAR or CLI/DNIS-based NAR. To answer the second question (how does ACS retrieve attributes to build the filter/condition?), look at Table 14-2 and Table 14-3.

Table 14-2. Fields Used When Evaluating NAR for TACACS+ Session

Table 14-3. Fields Used When Evaluating NAR for RADIUS Session

You should now have everything sorted out, but do you need to dig into every packet while configuring NAR? No. ACS reports make it very simple to understand which information means what. If you navigate to the Reports and Activity section and check the passed or failed logs, you can check the required detailed as shown as Table 14-4 and Figure 14-2.

Table 14-4. NAR Fields and Reports

Figure 14-2. NAR Fields and Passed and Failed Authentication Reports

Based on the preceding information, let’s redefine the rule on selecting IP-based or CLI/DNIS-based NAR. A TACACS+/RADIUS session can be matched against IP-based NAR or CLI/DNIS-based NAR. Depending on the user session information, Cisco Secure ACS chooses:

IP-based NAR when the Caller-ID attribute in ACS reports contains a valid IP address

CLI/DNIS-based NAR in all other cases

To use the NAR feature based on the information so far, consider the following configuration scenario to restrict WLAN access based on the Cisco Wireless LAN Controller (WLC) Service Set Identifier (SSID). The knowledge that you are going to use to restrict access to SSID is as follows: During RADIUS authentication, when a client tries to connect to an SSID on a Cisco WLC, it sends RADIUS Access-request with RADIUS attribute 30 (Called-Station-Id) in a special format.

WLC-MAC-Address:SSID

For example:

00-AA-BB-F8-C6-40:ABC-Wireless

where 00-AA-BB-F8-C6-40 is the MAC address of WLC and ABC-Wireless is the SSID.

When authenticating wireless clients with WLC, the Caller-ID is the MAC address of the client machine, which is not a valid IP address. Therefore ACS evaluates CLI/DNIS-based NAR.

So, if you want to restrict any particular group’s access to SSID ABC-Wireless, you will configure NAR as shown in Figure 14-3.

Figure 14-3. NAR: Restricting Access to SSID

In Figure 14-3, Denied Calling/Point of Access Locations has been selected from Table Defines, the AAA client defined as NDG:NOR-WLAN, which has WLC for a location, Port as any (*), CLI as any (*), and DNIS as *ABC-Wireless. If applied on a group, this configuration will restrict users in that group from being able to connect to SSID ABC-Wireless for the WLC configured under NDG:NOR-WLAN.

Backup and Restore

Another important aspect of maintaining your ACS configuration is to perform frequent database backups of the ACS database. This section covers the steps needed to perform manual backups, schedule backups, cancel scheduled backups, and recover ACS from a backup.

Under the umbrella of database backup, you have the following options:

• Perform a manual backup

• Schedule a backup to take place at periodic intervals, or at a given time

• Cancel a scheduled backup

• Recover from a backup file

Database backups are performed from the System Configuration subsection, ACS System Backup Setup. From this subsection, you can configure manual backups, which requires an administrator to force the backup process into effect or schedule a backup. If you decide to schedule a backup, you have a few options. You can back up based on an interval (the default is 60 minutes) or you can specify times to perform the database backup. To perform a backup, you must tell ACS where to store the backup file. The default location to store backup files in the directory is

C:Program FilesCiscoSecure ACS v4.2CSAuthSystem Backups

This backup file is stored as a .dmp file. The file is named by date. For example, the file 11-May-2010 02-48-00.dmp was created at 2:48 on May 11 2010. Consider managing this directory if you have ACS perform automatic backups. This directory might get full quickly. For this reason, you might want to keep files for a certain period of time using the available Manage Directory option or frequently back up this directory to external media.

Manual Backups

To perform a manual backup on ACS, go to System Configuration > ACS Backup. From here, you simply need to select the button Backup Now to perform a manual backup (see Figure 14-4 in the next section).

Figure 14-4. ACS Backup Option

Scheduled Backups

To schedule a backup, go to System Configuration > ACS Backup. Choose one of the following options:

• Every _X_ minutes

• At specific times

If you select to back up at a given time interval, enter an interval or accept the default of 60 minutes. If you choose to back up at specific times, use the time grid provided to select those times. Complete the configuration by selecting Submit.

You can manage the directory that backups are performed in by manipulating those options in the ACS interface. The default directory used for backup is

C:Program FilesCiscoSecure ACSv4.2CSAuthSystem Backups

The Management option is also in place for this directory so that it can be managed from becoming very large, very quickly.

It is fairly simple to cancel a scheduled backup. Simply access ACS backup from the System Configuration section and change from Every _X_ minutes, or At specific times, to Manual backup as shown in Figure 4-4.. This cancels any further scheduled backups.

Recovering ACS from a Backup file

If you want to recover ACS from a .dmp file, select the ACS Restore from System Configuration, choose the directory that your backup files are stored in, choose the file you want to restore from, opt for restoring user and group database and/or Cisco Secure ACS system configuration, and select the Restore Now button as shown in Figure 14-5.

Figure 14-5. ACS Restore Option

Database Replication

Database replication is a means of providing a more fault-tolerant network design. This section explains the process of database replication as well as the steps to configure database replication.

Understanding Database Replication

Database replication is a way for you to create a copy of the ACS database on one or more mirror systems. This process allows for the processing of authentication requests if the primary ACS goes down. You can schedule database replication or you can perform immediate database replications. Another benefit to database replication is that the database is actually compressed before it is sent, and the secondary server has the capability to decompress the information after it has been received.

The replication process in the text that follows is taken from the user guide for ACS and details the communication between the primary and secondary ACS.

The database replication process begins when the primary Cisco Secure ACS server compares the list of database components it is configured to replicate with the list of database components each secondary Cisco Secure ACS is configured to replicate. The primary Cisco Secure ACS replicates only those database components that it is configured to send and that the secondary Cisco Secure ACS is configured to receive. If the secondary Cisco Secure ACS is not configured to receive any of the components that the primary Cisco Secure ACS is configured to send, the database replication is aborted.

After the primary Cisco Secure ACS has determined which components to send to the secondary Cisco Secure ACS, the replication process continues on the primary Cisco Secure ACS as follows:

Step 1. The primary Cisco Secure ACS stops its authentication and creates a copy of the Cisco Secure database components that it is configured to replicate. During this step, if AAA clients are configured properly, those that normally use the primary Cisco Secure ACS failover to another Cisco Secure ACS.

Step 2. The primary Cisco Secure ACS resumes its authentication service. It also compresses and encrypts the copy of its database components for transmission to the secondary Cisco Secure ACS.

Step 3. The primary Cisco Secure ACS transmits the compressed, encrypted copy of its database components to the secondary Cisco Secure ACS. This transmission occurs over a TCP connection, using port 2000. The TCP session uses an encrypted, Cisco-proprietary protocol.

After the preceding events on the primary Cisco Secure ACS, the database replication process continues on the secondary Cisco Secure ACS as follows:

Step 1. The secondary Cisco Secure ACS receives the compressed, encrypted copy of the Cisco Secure database components on the primary Cisco Secure ACS. After transmission of the database components is complete, the secondary Cisco Secure ACS uncompresses the database components.

Step 2. The secondary Cisco Secure ACS stops its authentication service and replaces its database components with the database components it received from the primary Cisco Secure ACS. During this step, if AAA clients are configured properly, those that normally use the secondary Cisco Secure ACS failover to another Cisco Secure ACS.

Step 3. The secondary Cisco Secure ACS resumes its authentication service.

To clarify a few items for you, it is important to understand that only those components that the primary is configured to send and the secondary is configured to receive are replicated. The secondary can be configured to receive other components; however, if the primary isn’t configured to send them, it won’t do so. The primary can be configured to send other components; however, the secondary won’t receive them if it isn’t configured to do so. So, all that is actually replicated is what the primary is configured to send and what the secondary is configured to receive. This replication occurs as long as both the primary and secondary Cisco Secure ACS agree on at least one component. If they do not agree, the replication process is aborted. Additionally, if nothing has changed on the primary server since the last replication, no reason to replicate exists.

Replication Versus Backup

The major difference between database replication and database backup is that database backup creates a backup file on the local drive. This can be copied to other forms of media, or to network shares, and can be used to recover a system that has failed. What database backup does not do is copy the database or portions of the database to other ACSs, known as secondary servers. By using replication, you can provide a redundant server configuration. In database backup, you back up the complete ACS configuration. With database replication, the following items cannot be replicated:

• IP pool definitions

• ACS certificate and private key files

• Unknown user group mapping configuration

• Dynamically-mapped users

• Settings on the ACS Service Management page in the System Configuration section

• RDBMS synchronization settings

Configuring the Primary Server for Replication

Database replication is found in the System Configuration section of ACS. To configure the server for database replication, follow these steps:

Step 1. Under the Network Configuration section, configure secondary server as an AAA Server with a shared secret key that will be used in secondary server configuration.

Step 2. Select System Configuration.

Step 3. Select ACS Internal Database Replication.

Step 4. In the resulting screen, shown in Figure 14-6, select Send for any of or all the replication components:

• User and group database

• Network configuration device tables

• Distribution table

• Interface configuration

• Interface security settings

• Password validation settings

• Network Access Profiles

• Logging Configuration (Enable/Disable Settings)

Figure 14-6. ACS Internal Database Replication

Step 5. Next, for outbound replication, select the Scheduling of Outbound Replication options that you want to employ. Choose Manually, Automatically Triggered Cascade (meaning when the master receives information it is automatically copied to the others), Every _X_ minutes, or select a specific time using the grid provided.

Step 6. Choose the Partner server(s) from the list of AAA servers in the left column of the Partners section, and use the right arrow button to place them in the replication list to the right.

Step 7. Because this is the primary server, you should not need to configure the Inbound Replication settings; however, a server in a cascade can accept incoming replication, as well as perform outbound replication. If you choose a specific time, select the times from the grid provided.

Step 8. Select the Submit button or, to perform immediate replication, select the Replicate Now button.

Configuring a Secondary Server

The secondary server must be configured to receive the exact configuration that the primary server is sending.

To configure the secondary server for database replication, follow these steps:

Step 1. Under Network Configuration, create an AAA Server entry for the primary ACS server with the same shared secret key that was used in the primary ACS server to create an AAA Server entry for the secondary ACS server.

Step 2. From the System Configuration menu, select the ACS Internal Database Replication option.

Step 3. Select the Receive check box for each item you want to receive (refer back to Figure 14-6). These include user and group database, AAA servers and AAA clients tables, distribution table, interface configuration, interface security settings, and password validation settings. These should match the options that the primary ACS is sending.

Step 4. Next, from the Inbound Replication section (see Figure 14-7), choose to receive replication from any known Cisco Secure ACS or use the drop-down list to select a trusted server.

Figure 14-7. ACS Internal Database Replication

Step 5. Select Submit.

RDBMS Synchronization

The RDBMS Synchronization feature supports creation, addition, modification, and deletion of ACS database objects. RDBMS synchronization can be done manually or configured to occur on a regular schedule.

The following lists outline the different kinds of configuration that can be done using RDBMS synchronization.

For users, you can configure the following attributes:

• Adding a user

• Deleting a user

• Setting passwords

• Setting user group membership

• Setting max sessions parameters

• Setting network usage quota parameters

• Configuring command authorization

• Configuring network access restrictions

• Configuring time-of-day/day-of-week access restrictions

• Assigning IP addresses

• Specifying outbound RADIUS attribute values

• Specifying outbound TACACS+ attribute values

For user groups, you can configure the following parameters:

• Setting max sessions parameters

• Setting network usage quota parameters

• Configuring command authorization

• Configuring network access restrictions

• Configuring time-of-day/day-of-week access restrictions

• Specifying outbound RADIUS attribute values

• Specifying outbound TACACS+ attribute values

For network configuration, you can configure the following:

• Adding an AAA client

• Deleting an AAA client

• Setting AAA client configuration details

• Adding an AAA server

• Deleting an AAA server

• Setting AAA server configuration details

• Adding and configuring proxy distribution table entries

For custom RADIUS vendors and vendor-specific attributes (VSAs), ACS enables you to create up to 10 IETF-compliant RADIUS vendors. All VSAs that you add for those servers must be subattributes of IETF RADIUS attribute number 26.

ACSs listen on TCP port 2000 for synchronization data. RDBMS synchronization communication between ACSs is encrypted using a 128-bit encrypted, proprietary algorithm.

Most of the configuration that can be done through the ACS web interface can be alternatively maintained through this feature, so in some cases this feature speeds up the process. For instance, if you are required to add, say, 100 users on ACS internal database, doing so through the ACS web interface will surely take some time. Using this feature, you can create a list of users with passwords and other information in a CSV file, or pick users from an already configured Open Database Connectivity (ODBC) database into ACS internal database in one go.

The feature of interacting with an ODBC database is available only on ACS for Windows, along with CSV. On ACS SE, you can use this feature only via a CSV file.

The CSV file and/or the ODBC input table is called accountActions. The accountActions that you create, be it a CSV file or some ODBC table, must adhere to a specification; otherwise, RDBMS synchronization might import incorrect information or fail.

accountActions Format

Table 14-5 lists the fields that compose accountActions. There are 14 fields/columns in accountActions, where each row reflects an action or input to be processed. The order is of importance as accountActions must have 14 fields/column in the same order as shown in Table 14-5.

Table 14-5. accountActions Fields

Out of 14 fields, the following fields are mandatory, cannot be empty, and must have a valid value:

• SequenceID

• Action

• Status

There are different action codes available for the addition, creation, deletion, modification of different ACS objects. For more information on different action codes, refer to the “RDBMS” section of the “User Guide for Cisco Secure Access Control Server”:

http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4.2.1/User_Guide/A_RDBMS.html#wp77962

As an example, Figure 14-8 looks at action code 100, which is used for user addition. Every action code has required field(s) that must not be left empty. As in case of adding a user, action code 100 has UN|GN and V1 as the mandatory fields (apart from SequenceID, Action, and Status). UN|GN means that while creating a user, it is optional to assign a user to a desired group. If a group is not defined, the user created will be assigned to the default group on ACS. Figure 14-8 shows a CSV file with action code 100 to add a user.

Figure 14-8. RDBMS Synchronization: Adding User

On ACS 4.2, you can use RDBMS synchronization in different ways. One of the easiest ones available (on ACS for Windows and ACS SE) is to import the CSV file with the data. On ACS SE, this file needs to be placed on a FTP server; on ACS for Windows, it can be placed on a local drive. The section that follows outlines how to import the CSV file in Figure 14-8 on ACS for Windows.

Performing RDBMS Synchronization

RDBMS synchronization is found under the System Configuration section. If it is not available, this feature can be made visible from Interface Configuration > Advanced Options and by checking the RDBMS Synchronization option to display the screen shown in Figure 14-9.

Figure 14-9. RDBMS Synchronization

Step 1. Create your accountActions table/file.

Step 2. Choose how you want to synchronize data into ACS—using ODBC databases or using local CSV file. If using an ODBC database, set up a system DSN as instructed in “User Guide for Cisco Secure Access Control Server” under the “System Configuration Advanced” section:

http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4.2.1/User_Guide/SCAdv.html#wp757441

Step 3. Choose the Synchronization Scheduling option if you want to schedule the synchronization; otherwise, leave it on the default for manual synchronization.

Step 4. Choose the AAA server(s) from the AAA Servers column and move it to the Synchronize column on which you want to do the RDBMS synchronization.

Step 5. Save the changes by choosing Submit. If required to do synchronization manually, choose the Synchronize Now button.

Step 6. Finally, check the RDBMS Synchronization reports from Reports & Activity to ensure that synchronization went properly.

Network Access Profiles

Before the Network Access Profile (NAP) feature was introduced in ACS, there was no clear classification on different security policies that could be applied to different use cases. For instance, suppose that you have a wired and wireless network and have secured them using 802.1 x frameworks. The security policy needs to be more limiting when access is through wireless as compared to wired. Suppose that you are required to assign users to VLAN 200 (which is a restricted VLAN) when they access the network through wireless, and assign users to VLAN 300 when they access the network through a wired connection. On ACS, you can configure attributes on either the user or group level. Only one configuration will take effect, but that will not satisfy the security need. Without NAP, you can either have VLAN 200 or VLAN 300, always.

Now, with NAP, you can classify access requests and depending upon conditions, you can apply different policies.

So, a NAP, also known as a profile, is a classification of network access request for applying a common policy.

There are two main components of profiles:

• Classification of network request

• Policies

The sections that follow describe these in more detail.

Classification of Network Request

The following are the classification methods available:

• NAFs:Network Access Filter (NAF) is configured under Shared Profile Components and is used for grouping AAA clients. If a NAF is created and selected in NAP, access requests from only those devices are examined by the NAPs that are under NAF.

• Protocol Types: This option is used to further classify access requests based on type of protocol.

• Advanced Filtering: This option enables you to further classify access requests based on RADIUS attributes and values included in access requests. You can create multiple conditions/rules in this section; the final result is derived by a Boolean AND of all the rules created in this section.

Finally, a profile is selected when all the selected conditions (NAFs, Protocol Types, and Advanced Filtering) match or are true.

Policies

Until now, you have only classified a network access request, but you have still not applied any security policy, as in what needs to be done when you have identified the section that needs to be taken care of according to the security policy. This action or application of security policy is handled by profile-based policies.

The following options are available for creating a profile-based policy (see Figure 14-10):

• Protocols: In this section, you create a rule that defines which password protocol and/or EAP configuration is allowed.

• Authentication: In this section, you have a configuration related to authentication. For example, from which database does the user need to be authenticated?

• Posture validation: In this section, you create rules on how a posture validation will be performed. This option is configured only if you plan to deploy NAC in your network.

• Authorization: In this section, you configure authorization rules and can define System Posture Token, RADIUS Authorization Components (RAC), and Downloadable ACL as the authorization result.

Figure 14-10. Network Access Profile

Using NAP and NAP policies, you can now classify an access request and apply the desired security policy. An access request that does not match any profile is also controlled from the Network Access Profiles section, as shown in Figure 14-10. By default, if no profile is matched, access is granted based on global configuration on ACS. If you want to configure a stricter security policy, you can choose the option Deny access when no profile matches to make it mandatory for any RADIUS access request to first match a NAP in order to gain network access.

Now suppose that in your network you have a LAN and a WLAN, and the requirement is that if a user successfully authenticated on the LAN he or she should be assigned VLAN 50. Furthermore, if a user successfully authenticates on the WLAN, he or she should be assigned VLAN 60. Without the NAP feature, this would not be possible.

To achieve your objective, you would be required to create two NAP profiles. A NAP profile for the LAN will have a classification of request based on a NAF. You will create a NAF from the shared profile components that will contain all the LAN switches.

After you have selected a NAF in the LAN NAP profile, you need to choose the appropriate protocol that needs to be allowed. Because VLAN assignment will involve EAP protocols, you can choose the EAP protocol of your choice that needs to be allowed.

After deciding which protocol to allow, you need to choose the database where the user identity is held. This is done from the Authentication section of the NAP. In this section, you can choose which database to check directly for user account verification.

If posture validation is required in your network, you can configure it from the Posture Validation section in NAP according to your security policy.

The final requirement for this example is to define the authorization components for the requests matching the criteria defined in NAP through the Authorization section in NAP. Before you configure this section, all the required authorization components must first be configured under Shared Profile Components’ RADIUS Authorization Component and/or Downloadable IP ACLs. These are the two authorization components returned if all the conditions are met successfully.

For this example, you need to create a RAC as follows:

• [64] Tunnel-Type = VLAN

• [65] Tunnel-Medium-Type = 802

• [81] Tunnel-Private-Group-ID = 50

Under the LAN NAP, you can then select this RAC for any/specific user with any/specific system posture.

Similarly, a WLAN NAP needs to be created to assign VLAN 60.

Local Password Management

The Local Password Management section is available under the System Configuration section as Local Password Management. As shown in Figure 14-11, under this section, you can configure validation parameters/complexity for user passwords. In this section, you can also configure whether a Telnet password change is allowed. If the change is allowed, you can further configure whether ACS sends updated password information to replication partners.

Figure 14-11. Local Password Management

Remote Logging

By default, ACS audit logs are stored locally, be it ACS for Windows or ACS SE. In the case of ACS for Windows, audit logs are stored at a default location:

• C:Program FilesCiscoSecure ACS v4.2LogsFailed Attempts

• C:Program FilesCiscoSecure ACS v4.2LogsPassed Authentications

• C:Program FilesCiscoSecure ACS v4.2LogsRADIUS Accounting

• C:Program FilesCiscoSecure ACS v4.2LogsTACACS+ Accounting

• C:Program FilesCiscoSecure ACS v4.2LogsTACACS+ Administration

• C:Program FilesCiscoSecure ACS v4.2LogsVoIP Accounting

• C:Program FilesCiscoSecure ACS v4.2LogsBackup and Restore

• C:Program FilesCiscoSecure ACS v4.2LogsDBReplicate

• C:Program FilesCiscoSecure ACS v4.2LogsAdminAudit

• C:Program FilesCiscoSecure ACS v4.2CSAuthPasswordLogs

• C:Program FilesCiscoSecure ACS v4.2LogsServiceMonitoring

• C:Program FilesCiscoSecure ACS v4.2LogsDbSync

For ACS SE, logs are by default stored on a local drive with a retention policy. For each CSV log, ACS SE writes a separate log file. When a log file size reaches 10 MB, ACS SE starts a new log file. ACS SE retains the seven most recent log files for each CSV log.

On ACS for Windows, you have the flexibility to change the default audit log location, which you will see in next section. On ACS SE, you do not have that flexibility. For auditing purposes, if you want to send logs from ACS for Windows and/or ACS SE to a remote location, that can be done. There are two ways to achieve this:

• Remote Agent

• Syslog

Remote Agent is software that needs to be installed on the Windows server, which will act as a log collector. On ACS for Windows, you need to create an AAA server entry for Remote Agent; on ACS SE, you have to create it as Remote Agent under the Network Configuration section. You can have multiple remote agents added on the ACS server. Specifying which remote agent gets the log and how is configured from the following:

• System Configuration > Logging > Remote Logging Servers Configuration (see Figure 14-12)

Figure 14-12. Remote Logging Servers Configuration

• System Configuration > Logging > Remote Agent Reports Configuration

Syslog is another option available to send logs on a remote server. This configuration option is very easy to configure; you need only have a syslog server configured, and on ACS you need to configure Syslog server settings on ACS from System Configuration > Logging.

Every individual log has a section for Syslog logging that can be configured.

Log File Management

The Log File Management feature (see Figure 14-13) is available for audit and service logs on ACS for Windows and for Remote Agent Reports on ACS SE. This feature enables you to manage logs that get generated on the ACS server or on the Remote Agent directory. This feature provides you with options on how log files needs to be generated, including

• Every day

• Every week

• Every month

• When size is greater than _X_ KB

Figure 14-13. Log File Management: Passed Authentication Logs

In this section you can also change the default log location to a different log location on the disk drive, under the Directory option.

The Manage Directory section has two options on how the directory needs to be maintained. To use this feature you need to enable Manage Directory by checking the check box. The two rules by which a directory can be maintained are

• Keep only the last _X_ files

• Delete files older than _X_ days

These options are configurable from System Configuration > Logging. Each audit log can be configured as per need under CSV column. This option is available under System Configuration > Service Control for service logs. For Remote Agent, it is available on ACS SE under System Configuration > Logging > Remote Agent Reports Configuration.

Figure 14-14. Log File Management: Service Control

CSUtil Database Utility

CSUtil is a command-line utility/tool for ACS for Windows only. This utility/tool can be used to add, edit, and delete users and AAA client configuration from a colon-delimited text file, along with many other functions. This can be seen as a utility with functions similar to RDBMS synchronization.

The CSUtil.exe is located under the bin subdirectory of the ACS installation directory. For ACS 4.2, if installed on the C: drive, bin will be under:

C:Program FilesCiscoSecure ACS v4.2in

The files that are generated or are accessed by CSUtil.exe are located under the bin directory.

The CSUtil command syntax is as follows:

Table 14-6 describes the CSUtil options in greater detail.

Table 14-6. CSUtil Options

Although it’s clear from Table 14-6 what the CSUtil utility can do, here is a list of CSutil functions:

• Backup ACS database

• Restore ACS database

• Initialize ACS database

• Clean ACS internal database

• Add, update, delete User and AAA client

• Export user list

• Export group information

• Decode error numbers

• Add, delete, list, export user-defined RADIUS VSA

• PAC file generation

• Import, export, delete posture-validation attributes

• Adding external audit device type attributes

As an example, Example 14-1 shows the CSutil option to backup the ACS database.

Example 14-1. CSUtil Backup

The text that follows demonstrates another instance of importing a RADIUS vendor-specific attribute. This example takes an imaginary vendor (NewVendor) whose RADIUS attributes for a device need to be added in ACS. Example 14-2 shows the VSA file to be used.

Example 14-2. VSA File Content

To import the new VSA into ACS, you first need to check the free slots that can be used on ACS to fit the new VSA as done in Example 14-3.

Example 14-3. Listing Unassigned Slots Using csutil.exe

As you can see, there are 10 slots available and you can choose any free slot. In this example, slot 0 was chosen. The next step is to import the VSA file as shown in Example 14-2.

Example 14-4. RADIUS VSA Import Using csutil.exe

In Example 14-4, the newvendor.ini file has the contents shown previously in Example 14-2.

Now go to Network Configuration on ACS and add an entry for the NewVendor device using RADIUS (NewVendor). Then select Submit+Apply.

Then go to Interface Configuration > RADIUS (NewVendor) and check the attributes that you need to be available for configuration on user/group configuration.

Summary

This chapter went through a few of the advanced features available in ACS 4.2. The key concepts covered in the chapter are as follows:

• The Network Access Restriction (NAR) feature as a means for providing authorization based on user access request.

• The features and options available for backing up and restoring an ACS database.

• Replication as a means for creating redundant ACS database, along with differences in ACS backup and ACS replication.

• RDBMS synchronization as a tool (more of an API) to achieve bulk operation in a single go.

• Network Access Profiles (NAPs) as a means for classifying access request and applying common security policy on a network.

• Options available for local password policy.

• Remote logging options with Remote Agent and syslog server.

• Managing and customizing log files on ACS using the Log File Management option.

• The CSUtil database utility for performing various operations from the command line (DOS) on ACS for Windows.