Cisco IOS XR Virtual Firewall Configuration Guide, Release 3.7 - Configuring Authentication and Accounting Services on the Virtual Firewall [Cisco IOS XR Software]

Table Of Contents

Configuring Authentication and Accounting Services on the Virtual Firewall

Contents

Information About AAA

Local Database and Remote Server Support

Local Database

TACACS+ Server

RADIUS Server

LDAP Directory Server

Authentication Overview

Accounting Overview

Creating User Accounts

How to Configure the VFW Application as a Client of a RADIUS, TACACS+, or LDAP Server

Configuring RADIUS on the VFW Application

Prerequisites

Troubleshooting Tip

Configuring TACACS+ on the VFW Application

Prerequisites

Troubleshooting Tip

Configuring LDAP on the VFW Application

Prerequisites

Troubleshooting Tip

How to View AAA Status and Statistics

Displaying AAA Groups

Displaying RADIUS Server Configuration Information

Displaying TACACS+ Server Configuration Information

Displaying LDAP Server Configuration Information

How to Configure the AAA Server

Configuring a TACACS+ Server

Configuring Authentication Settings on the TACACS+ Server

Configuring Accounting Settings on the TACACS+ Server

Defining Private Attributes for Virtualization Support in a TACACS+ Server

Configuring a RADIUS Server

Configuring Authentication Settings on the RADIUS Server

Configuring Accounting Settings on the RADIUS Server

Defining Private Attributes for Virtualization Support in a RADIUS Server

Configuring an LDAP Server

Defining Private Attributes for Virtualization Support in an LDAP Server

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance

Configuring Authentication and Accounting Services on the Virtual Firewall

This module describes how user authentication and accounting services are applied to the VFW application. The authentication and accounting services allow you to use multiple authentication, authorization, and accounting (AAA) servers to control who can access the VFW application and to track the actions of each user who accesses the VFW application. Based on the username and password combination provided, the VFW application performs local user authentication using the local database or performs remote user authentication and accounting using external AAA servers.

Feature History for Configuring Authentication and Accounting Services on the VFW Application

Release

Modification

Release 3.5.0

This feature was introduced on the multiservice blade (MSB) for the Cisco XR 12000 Series Router.

Release 3.6.0

No modification.

Release 3.7.0

No modification.

Contents

•Information About AAA

•How to Configure the VFW Application as a Client of a RADIUS, TACACS+, or LDAP Server

•How to View AAA Status and Statistics

•How to Configure the AAA Server

•Additional References

Information About AAA

AAA provides management security for user access to the VFW application through a combination of authentication and accounting services. AAA informs the VFW application about who the user is and what the user did. You can use authentication alone or in combination with accounting. The VFW application provides security for the management access methods to the VFW application, including the command-line interface (CLI) or Simple Network Management Protocol (SNMP).

Access to the VFW application CLI can be gained through the console port or by a Telnet or SSH session. When you log in to the VFW application using either a Telnet or SSH connection, and if the VFW application is configured for AAA server-based authentication, a temporary SNMP user entry is automatically created. The SNMPv3 protocol data units (PDUs) with the associated Telnet or SSH login name as the SNMPv3 user are authenticated by the VFW application.

As part of the authentication process, the VFW application associates each user with a user role and a domain privilege pair under a specific virtual context. Each virtual context behaves like an independent device with its own configuration, security policies, interfaces, and domains. A user context can be independently managed along with other user contexts. A domain provides a namespace in which a user operates, and each user is associated with at least one domain. The role assigned to a user determines the operations that a user can perform on the objects in a domain and the command set available to that user. Each context has a virtual AAA instance running to provide authentication for the users logging in and accounting services to log user activity.

Each virtual context on the VFW application can have its own IP address. Access to each virtual context in the VFW application is performed through console port or Telnet or SSH session by specifying this IP address. Users can also send SNMP requests to the VFW application by using this IP address.

Note Only the Admin context is accessible through the console port; all other contexts can be reached through Telnet or SSH.

The administrator of each virtual context is able to perform, independent from other contexts, the following actions:

•Configure different AAA servers and their parameters.

•Create the same username across contexts, and associate the username with a unique role in a context and multiple domains.

•Share AAA servers. Each user, however, must be authenticated for each virtual context and must use the same password.

•Log user accounting activities, which are distinguished by the context in which a user has signed in.

•Display the users currently authenticated on the virtual context.

Each user who accesses the VFW application from a specific IP address needs only to authenticate a single time. The user authentication sequence remains in effect until the authentication session expires on the VFW application.

The VFW application runs the AAA client, which sits between the users and the AAA server. On one side, the VFW application prompts each user for the user's credentials (username and password). On the other side, the VFW application queries the identified AAA servers to determine if the user being authenticated has supplied the correct credentials and is authorized access to the VFW application.

The VFW application performs authentication using either the local user database that resides on the VFW application or a remote AAA server. The VFW application can use a Remote Access Dial-In User Service (RADIUS), Terminal Access Controller Access Control System Plus (TACACS+), or Lightweight Directory Access Protocol (v3) (LDAP) protocols for remote authentication and designation of access rights.

This section includes the following topics:

•Local Database and Remote Server Support

•Authentication Overview

•Accounting Overview

Local Database and Remote Server Support

The VFW application supports local authentication using a local database on the VFW application or remote authentication using one or more AAA servers. AAA remote servers are grouped into independent groups of TACACS+, RADIUS, or LDAP servers. For a group of servers, the VFW application bases the selection of the server to use on the first active server in the group. "First" refers to the order in which servers have been configured. When a user logs in to a VFW application, the servers are accessed one at a time, starting with the first server specified in the configuration, until a server responds to the VFW application.

When you configure server groups using the server group authentication method, the VFW application sends an authentication request to the first AAA server in the group.

•If the remote AAA server fails to respond, then the VFW application attempts to contact the next server in the group until a remote AAA server responds to the authentication request.

•If all AAA servers in the server group fail to respond, then the VFW application tries the AAA servers in the next configured server group.

•If all remote AAA servers fail to respond, by default the VFW application attempts to authenticate you against the local database.

If the username and password are successfully authenticated, either locally or remotely, the VFW application allows the user to log in, and the user is assigned a unique role (as specified through the role command, which determines the commands and resources available to each user).

Each server within a group can assume an active or an inactive state due to a network connection failure. The policy used to select the AAA server takes the server state into account. The VFW application monitors AAA server operation by sending authentication requests to a timed-out server. If the VFW application does not receive confirmation from the server within a user-specified number of retries, the VFW application declares the server to be unresponsive and initiates the sequence to contact the next available server specified in the server group.

When a dead-time interval is specified for a AAA server, if the connection to server A fails, server A is temporarily marked as being "out of service." During the dead-time interval the nonresponsive server A is skipped by the VFW application. The VFW application sends probe access-request packets to verify that the AAA server is available and can receive authentication requests.When the server responds to a probe access-request packet, the connection resumes to server A.

This section includes the following topics:

•Local Database

•TACACS+ Server

•RADIUS Server

•LDAP Directory Server

Local Database

You can configure user account access to the local database on the VFW application for CLI access authentication. When a user attempts to access the VFW application CLI by using the console port or a Telnet or SSH session, the VFW application consults the local user database for the username and password. By default, each user assumes the Network-Monitor role and is allowed to operate on all domains.

If you specify local authentication as the fallback method and the specified AAA servers in a server group are unavailable for authentication, the VFW application then attempts to access the local database to perform user authentication and accounting.

TACACS+ Server

TACACS+ controls user access to the VFW application by exchanging Network Access Server (NAS) information between the VFW application and a centralized database to determine the identity of a user. TACACS+ is an enhanced version of TACACS, a User Datagram Protocol (UDP)-based access-control protocol that is specified by RFC 1492. TACACS+ uses TCP to ensure reliable delivery and encrypt all traffic between the TACACS+ server and the TACACS+ daemon on the VFW application.

A TACACS+ server can provide user authentication and accounting functions. These services, while all part of TACACS+, are independent of one another, so a given TACACS+ configuration can use any or all of the services.

The TACACS+ protocol encrypts the user password information using the MD5 encryption algorithm and adds a TACACS+ packet header. This header information identifies the packet type being sent (for example, an authentication packet), the packet sequence number, the encryption type being used, and the total packet length. The TACACS+ protocol forwards the packet to the TACACS+ server.

To maintain security between the VFW application and the TACACS+ server, you can specify an encryption key (shared secret) for all communication between the VFW application and the TACACS+ server. For correct operation, you must specify the identical encryption key on both the VFW application and the TACACS+ server.

RADIUS Server

RADIUS is a client-server access protocol that is used by the NAS to authenticate users attempting to connect to the VFW application. The NAS functions as a client, passing user information to one or more RADIUS servers. The NAS permits or denies network access to a user based on the response it receives from a RADIUS server. RADIUS uses UDP for connectionless transport between the RADIUS client and server. For more information about how the RADIUS protocol operates, refer to RFC 2138.

To maintain security between the VFW application and the RADIUS server, you can specify an encryption key (shared secret) for all communication between the VFW application and the RADIUS server. For correct operation, you must specify the identical encryption key on both the VFW application and the RADIUS server.

LDAP Directory Server

LDAP is an open-standard client-server authentication protocol for accessing X.500 Directory Access Protocol (DAP) directory services. LDAP runs over TCP/IP or other connection-oriented transfer services. The VFW application supports only LDAP version 3 for simple authentication and search operations. For more information about how the LDAP protocol operates, refer to RFC 2251.

The LDAP information model is based on entries. An entry is a collection of attributes that has a globally unique Distinguished Name (DN). The DN is used in the LDAP database to refer unambiguously to an entry. Each entry contains one or more attributes that describe the entry, and each attribute has a type and one or more values. The types are typically mnemonic strings, such as "cn" for common name, or "mail" for e-mail address.

The LDAP client (the VFW application) requests user authentication with the LDAP server and retrieves the user profile by requesting a search through the directory database maintained by the server. The LDAP server maintains a directory of entries, which are arranged into a hierarchical tree-like structure called Directory Information Tree (DIT).

The LDAP client performs operations on directory data. LDAP supports searching the directory for data meeting arbitrary user-specified criteria. A user can specify what part of the directory to search and what information to return. A search filter that uses Boolean conditions specifies what directory data matches the search.

Note The VFW application does not support update, compare, or cancel operations with the LDAP server. In addition, the VFW application does not support unsolicited notification from the LDAP server. Supported messages include bindRequest, bindResponse, unbindRequest, searchRequest, searchResEntry, and searchResDone.

Authentication Overview

Authentication allows you to control user access to the VFW application CLI by requiring specification of a valid username and password. You can access the VFW application CLI through the console port or by a Telnet or SSH session. For each management access path to the VFW application, you can configure one or more of the following security control options: local database, remote (RADIUS, TACACS+, or LDAP), or no password verification.

The host is prompted by the VFW application to provide a valid username and password. After the designated RADIUS, TACACS+, or LDAP server authenticates the username and password, the VFW application provides access rights to the user.

Accounting Overview

Accounting tracks and maintains a log of useful information during each user management session with the VFW application. You can use this information to generate reports for troubleshooting and auditing purposes. Accounting logs can be stored locally on the VFW application or sent to remote AAA servers. If the VFW application is also configured to authenticate the user, the AAA server maintains accounting information by username. Accounting information includes user commands entered on the VFW application, the duration of each session, and when sessions start and stop.

When VFW application user commands are being logged on a TACACS+ or RADIUS server, the server prefaces each command with either a "<0:>" or a "<1:>" to indicate the success or failure of the command as issued by a user on the VFW application CLI. For example, when a user attempts to enter a command on the VFW application and that user does not have the correct role privileges, a "<1:>" appears to indicate a failure.

Creating User Accounts

Every user associated with a virtual context has account information stored on the VFW application. The authentication information, username, user password, password expiration date, and user role membership are all stored as part of each user's profile.

As the VFW application global administrator, you can assign one user in each context as the context administrator. The context administrator can then log in to the context or contexts on the VFW application for which he or she is responsible and create additional users.

If you do not assign a user role to a new user, the default user role is Network-Monitor. By default, the user is allowed to operate on all domains. For users that you create in the Admin context, the default scope of access is the entire device. For users that you create in other contexts, the default scope of access is the entire context. If you need to restrict a user's access, you must assign a role-domain pair.

Note the following when assigning a user for a context in the VFW application:

•The same username can be created across contexts and can be associated with a unique role in a context and multiple domains. A user can have up to ten domains associated with a unique role in a context.

•Virtual contexts can share RADIUS, TACACS+, and LDAP servers; however, the user must be explicitly authenticated for each context and must use the same password.

•All logged user accounting activities are distinguished in the VFW application by the context in which a user has signed in.

For detailed information on creating contexts and user accounts to provide access to the local database on the VFW application for CLI access authentication, refer to the "Configuring Virtualization on the Virtual Firewall" module.

How to Configure the VFW Application as a Client of a RADIUS, TACACS+, or LDAP Server

You can specify one or more AAA server groups to identify the server and the remote authentication protocol, RADIUS, TACACS+, or LDAP. You can configure multiple AAA servers (of the same server type) for each server group.

For each AAA server, you can specify:

•The server IP address and port.

•Encryption key (shared secret) to authenticate communication between the VFW application and AAA server (RADIUS and TACACS+ servers only).

•The number of times the VFW application retransmits an authentication request to a timed-out server before declaring the AAA server to be unresponsive and contacting the next AAA server in the group (RADIUS and TACACS+ servers only).

•The time interval that the VFW application waits for a server to reply to an authentication request before retransmitting another request to the server.

•The time interval in which the VFW application sends probes to a AAA server to verify whether the server is available and can receive authentication requests. The dead-time interval starts when the server does not respond to the number of authentication request transmissions.

•Independent server groups of TACACS+, RADIUS, or LDAP servers.

This section includes the following tasks:

•Configuring RADIUS on the VFW Application

•Configuring TACACS+ on the VFW Application

•Configuring LDAP on the VFW Application

Configuring RADIUS on the VFW Application

The VFW application supports the RADIUS protocol to communicate with a remote RADIUS server for authentication and accounting services. This task defines the configuration of the VFW application to operate as a client of a RADIUS server.

Prerequisites

•The RADIUS server must be configured. Refer to "Configuring a RADIUS Server" section for more information.

•You must attach from the route processor to the VFW application before you can perform this task. See the "Attaching to the VFW Application" section on page VFC-14.

SUMMARY STEPS

1. changeto context-name

2. configure

3. radius-server host ip_address [key [0 | 7] shared_secret] [auth-port port_number] [acct-port port_number] [authentication] [accounting] [timeout seconds] [retransmit count]

4. aaa group server radius group_name

5. server ip_address

6. deadtime minutes

7. exit

8. aaa authentication login {console | default} group group_name [local] [none]

9. aaa accounting default group group_name [local] [none]

10. copy running-config startup-config

DETAILED STEPS
Command or Action

Purpose

Step 1

changeto context-name
Example:

firewall/Admin# changeto C1
firewall/C1#

Logs in to the correct context. If you are operating in multiple contexts, observe the CLI prompt to verify that you are operating in the desired context.

Note The rest of the examples in this task use the Admin context. For details on creating contexts, see Configuring Virtualization on the Virtual Firewall.

Step 2

configure
Example:

firewall/Admin# configure
Enter configuration commands, one per line. End with CNTL/Z.
firewall/Admin(config)#

Enters global configuration mode. You are now within configuration mode of the VFW application.
Step 3
radius-server host ip_address [key [0 | 7] shared_secret] [auth-port port_number] [acct-port port_number] [authentication] [accounting] [timeout seconds] [retransmit count]
Example:
firewall/Admin(config)# radius-server host
192.168.2.3 key HostKey
firewall/Admin(config)# radius-server host 
192.168.2.3 key 7 secret_1256
firewall/Admin(config)# radius-server host 
192.168.2.3 auth-port 1645
firewall/Admin(config)# radius-server host 
192.168.2.3 acct-port 1646
firewall/Admin(config)# radius-server host 
192.168.2.3 authentication
firewall/Admin(config)# radius-server host 
192.168.2.3 accounting
firewall/Admin(config)# radius-server host 
192.168.2.3 timeout 25
firewall/Admin(config)# radius-server host 
192.168.2.3 retransmit 3
Configures the individual RADIUS server parameters.

•ip_address—IP address for the RADIUS server.

•key—Enables an authentication key for communication between the VFW application and the RADIUS daemon running on the RADIUS server. This key overrides the global setting of the radius-server key command.

•shared_secret—Identifies the key used to authenticate communication between the RADIUS client and server. The shared secret must match the one configured on the RADIUS server. Enter the shared secret as a case-sensitive string with no spaces, with a maximum of 63 characters.

•0—Configures a key specified in clear text.

•7—Configures a key specified in encrypted text.

•auth-port port_number—Specifies the UDP destination port for communicating authentication requests to the RADIUS server. By default, the RADIUS authentication port is 1812. Valid values are from 1 to 65535.

•acct-port port_number—Specifies the UDP destination port for communicating accounting requests to the RADIUS server. By default, the RADIUS accounting port is 1813. Valid values are from 1 to 65535.

•authentication—Specifies that the RADIUS server is used only for authentication.

•accounting—Specifies that the RADIUS server is used only for accounting.
•timeout seconds—Amount of time the VFW application waits for the RADIUS server to reply to an authentication request before retransmitting an authentication request to the server. Valid entries are 1 to 60 seconds. The default is 1 second. This command overrides the global setting assigned using the radius-server timeout command.

•retransmit count—The number of times the VFW application retransmits an authentication request to a timed-out RADIUS server before declaring the server to be unresponsive and contacting the next server in the group. Valid entries are 1 to 5 attempts. The default is 1 attempt. This command overrides the global setting assigned using the radius-server retransmit command.
Step 4
aaa group server radius group_name
Example:
firewall/Admin(config)# aaa group server 
radius RAD_Server_Group1
Configures a RADIUS server group. The group_name argument identifies the group of servers. It can be a maximum of 64 alphanumeric characters.
Step 5
server ip_address
Example:
firewall/Admin(config-radius)# server 
192.168.252.1
firewall/Admin(config-radius)# server 
192.168.252.2
firewall/Admin(config-radius)# server 
192.168.252.3
Adds a server to a RADIUS server group. The ip_address argument specifies the IP address for an existing RADIUS server that you want to add to the server group.
Step 6
deadtime minutes
Example:
firewall/Admin(config-radius)# deadtime 15
Configures a dead-time interval for the server group. The minutes argument specifies the length of time that the VFW application skips a nonresponsive RADIUS server for transaction requests. Valid entries are 0 to 1440 minutes (24 hours). The default is 0.
Step 7

exit
Example:

firewall/Admin(config-radius)# exit
firewall/Admin#

Exits global configuration mode.
Step 8
aaa authentication login {console | default} group group_name [local] [none]
Example:
firewall/Admin(config)# aaa authentication 
login console group RAD_Server_Group1 local 
none 
Configures the authentication method used for login to the VFW application CLI. The arguments, keywords, and options are:

•console—Specifies the console port login authentication method, identified by the specified server group.

•default—Specifies the default login authentication method (Telnet or SSH login), identified by the specified server group.

•group group_name—Associates the login authentication process with a RADIUS server defined through the aaa group server command. The server group name is a maximum of 64 characters.

•local—Specifies to use the local database on the VFW application as the login authentication method. If the server does not respond, then the local database is used as the fallback authentication method.

•none—Specifies that the VFW application does not perform password verification. If you configure this option, users can log in to the VFW application without providing a valid password. Only a user with an Admin role is allowed to specify the none option.

Caution Use this option with care. If you specify none, any user can then access the VFW application at any time.
Step 9
aaa accounting default group group_name [local] [none]
Example:
firewall/Admin(config)# aaa accounting default 
group RAD_Server_Group1 local
Configures the default accounting method. The arguments, keywords, and options are:

•group group_name—Associates the accounting method with a RADIUS server defined previously through the aaa group server command. The server group name is a maximum of 64 characters.

•local—Specifies to use the local database on the VFW application as the accounting method.

•none—Specifies that the VFW application does not perform password verification, which disables password verification. If you configure this option, users can login without providing a valid password.

Caution Use this option with care. If configured, any user can then access the VFW application at any time.
Step 10

copy running-config startup-config
Example:

firewall/Admin# copy running-config startup-config

(Optional) Saves your configuration changes to flash memory.
Troubleshooting Tip

This task configures the RADIUS parameters for a specific RADIUS server. To configure the RADIUS parameters for all servers, use the following commands:

•radius-server key

•radius-server deadtime

•radius-server retransmit

•radius-server timeout

Some servers use the NAS-IP-Address RADIUS attribute to identify the RADIUS clients, which could expose your VFW application internal private network interface IP addresses. By default, the NAS-IP-Address is not configured. Use the radius-server attribute nas-ipaddr command to specify an RADIUS NAS-IP-Address attribute.

Setting the Global RADIUS Server Preshared Key

To globally configure an authentication key for communication between the VFW application and the RADIUS daemon running on each RADIUS server, use the radius-server key command. The key is a text string that must match the encryption key used on the RADIUS server. RADIUS keys are always stored in encrypted form in persistent storage on the VFW application. This global key is applied to those RADIUS servers in a named server group for which a shared secret is not individually configured by the radius-server host command.

For example, to globally configure an authentication key to be sent in encrypted text (indicated by 7) to the RADIUS server, enter:
firewall/Admin(config)# radius-server key 7 abe4DFeeweo00o 
Configuring the Global RADIUS Server Dead-Time

During the dead-time interval, the VFW application sends probe access-request packets to verify that the RADIUS server is available and can receive authentication requests. The dead-time interval starts when the server does not respond to the number of authentication request transmissions configured through either the radius-server retransmit command or the radius-server host retransmit command. When the server responds to a probe access-request packet, the VFW application transmits the authentication request to the server.

Use the radius-server deadtime command to globally set the time interval in which the VFW application verifies whether a nonresponsive server is operational.

Use of this command causes the VFW application to mark as "dead" any RADIUS servers that fail to respond to authentication requests. This action avoids the wait for the request to time out before trying the next configured server. The VFW application skips a RADIUS server that is marked as "dead" by additional requests for the duration of the specified minutes argument.

For example, to globally configure a fifteen-minute dead-time for RADIUS servers that fail to respond to authentication requests, enter:
firewall/Admin(config)# radius-server deadtime 15
Setting the Global RADIUS Server Number of Retransmissions

By default, the VFW application sends one authentication request to a RADIUS server before declaring the server to be unresponsive and contacting the next server in the group. Use the radius-server retransmit command to globally change the number of times the VFW application sends an authentication request to a RADIUS server. If all servers in the group are unavailable for authentication and accounting, the VFW application tries the local database, if it is configured as a local fallback method in the aaa authentication login or the aaa accounting default commands. If you do not have a fallback method, the VFW application continues to contact one of the AAA servers listed in the server group.

The VFW application applies this global retransmission value to those RADIUS servers for which a value is not individually configured by the radius-server host command.

For example, to globally configure the number of retransmissions to 3, enter:
firewall/Admin(config)# radius-server retransmit 3
Setting the Global RADIUS Server Timeout Value

By default, the VFW application waits one second for the RADIUS server to send a reply to an authentication request to an unresponsive server before retransmitting an authentication request to the server. Use the radius-server timeout command to globally change the time interval that the VFW application waits for the RADIUS server to reply before retransmitting an authentication request to the RADIUS server. The VFW application applies this global timeout value to those RADIUS servers for which a timeout value is not individually configured by the radius-server host command.

For example, to globally configure the timeout value to 30 seconds, enter:
firewall/Admin(config)# radius-server timeout 30 
Configuring TACACS+ on the VFW Application

The VFW application supports the TACACS+ protocol to communicate with a TACACS+ server for authentication and accounting services. This task defines the configuration of the VFW application to operate as a client of a TACACS+ server.

Prerequisites

•The TACACS+ server must be configured. Refer to "Configuring a TACACS+ Server" section for more information.

•You must attach from the route processor to the VFW application before you can perform this task. See the "Attaching to the VFW Application" section on page VFC-14.

SUMMARY STEPS

1. changeto context-name

2. configure

3. tacacs-server host ip_address [key [0 | 7] shared_secret] [port port_number] [timeout seconds]

4. aaa group server tacacs+ group_name

5. server ip_address

6. deadtime minutes

7. exit

8. aaa authentication login {console | default} group group_name [local] [none]

9. aaa accounting default group group_name [local] [none]

10. copy running-config startup-config

DETAILED STEPS
Command or Action

Purpose

Step 1

changeto context-name
Example:

firewall/Admin# changeto C1
firewall/C1#

Logs into the correct context. If you are operating in multiple contexts, observe the CLI prompt to verify that you are operating in the desired context.

Note The rest of the examples in this task use the Admin context. For details on creating contexts, see Configuring Virtualization on the Virtual Firewall.

Step 2

configure
Example:

firewall/Admin# configure
Enter configuration commands, one per line. End with CNTL/Z.
firewall/Admin(config)#

Enters global configuration mode. You are now within configuration mode of the VFW application.
Step 3
tacacs-server host ip_address [key [0 | 7] shared_secret] [port port_number] [timeout seconds]
Example:
firewall/Admin(config)# tacacs-server host 
192.168.3.2 key HostKey
firewall/Admin(config)# tacacs-server host 
192.168.3.2 tacacs3 key 7 1234 
firewall/Admin(config)# tacacs-server host 
192.168.3.2 port 1645 
firewall/Admin(config)# tacacs-server host 
192.168.3.2 timeout 5
Configure the individual TACACS+ server parameters.

•ip_address—IP address for the TACACS+ server.

•key—Enables an authentication key for communication between the VFW application and the TACACS+ daemon running on the TACACS+ server. This key overrides the global setting of the tacacs-server key command.

•shared_secret—Identifies the key used to authenticate communication between the TACACS+ client and server. The shared secret must match the one configured on the TACACS+ server. Enter the shared secret as a case-sensitive string with no spaces with a maximum of 63 characters.

•0—Configures a key specified in clear text.

•7—Configures a key specified in encrypted text.

•port port_number—Specifies the TCP destination port for communicating authentication requests to the TACACS+ server. By default, the TACACS+ authentication port is 49. Valid values are from 1 to 65535.

•timeout seconds—Amount of time the VFW application waits for the TACACS+ server to reply to an authentication request before retransmitting an authentication request to the server. Valid entries are 1 to 60 seconds. The default is 1 second. This command overrides the global setting assigned using the tacacs-server timeout command.
Step 4
aaa group server tacacs+ group_name
Example:
firewall/Admin(config)# aaa group server 
tacacs+ TAC_Server_Group1
Configures a TACACS+ server group. The group_name argument identifies the group of servers. It can be a maximum of 64 alphanumeric characters.
Step 5
server ip_address
Example:
firewall/Admin(config-tacacs)# server 
192.168.252.1
firewall/Admin(config-tacacs)# server 
192.168.252.2
firewall/Admin(config-tacacs)# server 
192.168.252.3
Adds a server to a TACACS+ server group. The ip_address argument specifies the IP address for an existing TACACS+, server that you want to add to the server group.
Step 6
deadtime minutes
Example:
firewall/Admin(config-tacacs)# deadtime 15
Configures a dead-time interval for the server group. The minutes argument specifies the length of time that the VFW application skips a nonresponsive TACACS+ server for transaction requests. Valid entries are 0 to 1440 minutes (24 hours). The default is 0.
Step 7

exit
Example:

firewall/Admin(config-tacacs)# exit
firewall/Admin#

Exits global configuration mode.
Step 8
aaa authentication login {console | default} group group_name [local] [none]
Example:
firewall/Admin(config)# aaa authentication 
login console group TAC_Server_Group1 local 
none 
Configures the authentication method used for login to the VFW application CLI. The arguments, keywords, and options are:

•console—Specifies the console port login authentication method, identified by the specified server group.

•default—Specifies the default login authentication method (Telnet or SSH login), identified by the specified server group.

•group group_name—Associates the login authentication process with a TACACS+ server defined through the aaa group server command. The server group name is a maximum of 64 characters.

•local—Specifies to use the local database on the VFW application as the login authentication method. If the server does not respond, then the local database is used as the fallback authentication method.

•none—Specifies that the VFW application does not perform password verification. If you configure this option, users can log in to the VFW application without providing a valid password. Only a user with an Admin role is allowed to specify the none option.

Caution Use this option with care. If you specify none, any user can then access the VFW application at any time.
Step 9
aaa accounting default group group_name [local] [none]
Example:
firewall/Admin(config)# aaa accounting default 
group TAC_Server_Group1 local
Configures the default accounting method. The arguments, keywords, and options are:

•group group_name—Associates the accounting method with a TACACS+ server defined previously through the aaa group server command. The server group name is a maximum of 64 characters.

•local—Specifies to use the local database on the VFW application as the accounting method.

•none—Specifies that the VFW application does not perform password verification, which disables password verification. If you configure this option, users can log in without providing a valid password.

Caution Use this option with care. If configured, any user can then access the VFW application at any time.
Step 10

copy running-config startup-config
Example:

firewall/Admin# copy running-config startup-config

(Optional) Saves your configuration changes to flash memory.
Troubleshooting Tip

This task configures the TACACS+ parameters for a specific TACACS+ server. To configure the TACACS+ parameters for all servers, use the following commands:

•tacacs-server key

•tacacs-server deadtime

•tacacs-server timeout

Setting the Global Preshared Key

To globally configure an authentication key for communication between the VFW application and the TACACS+ daemon running on each TACACS+ server, use the tacacs-server key command. The key is a text string that must match the encryption key used on the TACACS+ server. TACACS+ keys are always stored in encrypted form in persistent storage on the VFW application. This global key is applied to those TACACS+ servers in a named server group for which a shared secret is not individually configured by the tacacs-server host command.

For example, to globally configure an authentication key in encrypted text (indicated by 7) to authenticate communication between the TACACS+ client and server, enter:
firewall/Admin(config)# tacacs-server key 7 abe4DFeeweo00o 
Setting the Global TACACS+ Server Dead-Time

During the dead-time interval, the VFW application sends probe access-request packets to verify that the TACACS+ server is available and can receive authentication requests. The dead-time interval starts when the server does not respond to an authentication request transmission. When the server responds to a probe access-request packet, the VFW application retransmits the authentication request to the server.

Use the tacacs-server deadtime command to globally set the time interval in which the VFW application verifies whether a nonresponsive server is operational.

Use of this command causes the VFW application to mark as "dead" any TACACS+ servers that fail to respond to authentication requests. This action avoids the wait for the request to time out before trying the next configured server. The VFW application skips a TACACS+ server that is marked as "dead" by additional requests for the duration of the minutes argument.

For example, to globally configure a fifteen-minute dead-time for TACACS+ servers that fail to respond to authentication requests, enter:
firewall/Admin(config)# tacacs-server deadtime 15
Setting the Global TACACS+ Server Timeout Value

By default, the VFW application waits one second to receive a response from a TACACS+ server before it declares a timeout failure and attempts to contact the next server in the group. Use the tacacs-server timeout command to globally change the time interval that the VFW application waits for the TACACS+ server to reply before retransmitting an authentication request to the TACACS+ server. The VFW application applies this global timeout value to those TACACS+ servers for which a timeout value is not individually configured by the tacacs-server host command.

For example, to globally configure the timeout value to 30 seconds, enter:
firewall/Admin(config)# tacacs-server timeout 30 
Configuring LDAP on the VFW Application

The VFW application supports the LDAP protocol to communicate with a remote LDAP directory server for authentication services. This task defines the configuration of the VFW application to operate as a client of an LDAP server.

Prerequisites

•The LDAP server must be configured. Refer to "Configuring an LDAP Server" section for more information.

•You must attach from the route processor to the VFW application before you can perform this task. See the "Attaching to the VFW Application" section on page VFC-14.

SUMMARY STEPS

1. changeto context-name

2. configure

3. ldap-server host ip_address [port port_number] [timeout seconds] [rootDN DN_string] [password bind_password]

4. aaa group server ldap group_name

5. server ip_address

6. attribute user-profile text

7. base-DN text

8. filter search-user text

9. exit

10. aaa authentication login {console | default} group group_name [local] [none]

11. exit

12. copy running-config startup-config

DETAILED STEPS
Command or Action

Purpose

Step 1

changeto context-name
Example:

firewall/Admin# changeto C1
firewall/C1#

Logs in to the correct context. If you are operating in multiple contexts, observe the CLI prompt to verify that you are operating in the desired context.

Note The rest of the examples in this task use the Admin context. For details on creating contexts, see Configuring Virtualization on the Virtual Firewall.

Step 2

configure
Example:

firewall/Admin# configure
Enter configuration commands, one per line. End with CNTL/Z.
firewall/Admin(config)#

Enters global configuration mode. You are now within configuration mode of the VFW application.
Step 3
ldap-server host ip_address [port port_number] [timeout seconds] [rootDN DN_string] [password bind_password]
Example:
firewall/Admin(config)# ldap-server host 
192.168.2.3 port 2003 
firewall/Admin(config)# ldap-server host 
192.168.2.3 timeout 60 
firewall/Admin(config)# ldap-server host 
192.168.2.3 rootDN 
"cn=manager,dc=cisco,dc=com" password lab
Configures the individual LDAP server parameters. The arguments, keywords, and options are:

•ip_address —Specifies the IP address for the LDAP server.

•port port_number—(Optional) Specifies the TCP destination port for communicating authentication requests to the LDAP directory server. By default, the LDAP server port is 389. Valid values are from 1 to 65535. For the specified server, this command overrides the global setting assigned using the ldap-server port command.

•timeout seconds—(Optional) Specifies the time in seconds to wait for a response from the LDAP server before the VFW application can declare a timeout failure with the LDAP server. Valid entries are 1 to 60 seconds. The default is 5 seconds. For the specified server, this command overrides the global setting assigned using the ldap-server timeout command.

•rootDN DN_string—(Optional) Defines the Distinguished Name (DN) for a user who is unrestricted by access controls or administrative limit parameters to perform operations on the LDAP server directory. Enter a quoted string to a maximum of 63 characters. The default is an empty string.

•password bind_password—(Optional) Defines the bind password (rootpw) applied to the rootDN of the LDAP server directory. Enter an unquoted string to a maximum of 63 characters. The default is an empty string.
Step 4
aaa group server ldap group_name
Example:
firewall/Admin(config)# aaa group server ldap 
LDAP_Server_Group1
Configures an LDAP server group. The group_name argument identifies the group of servers. It can be a maximum of 64 alphanumeric characters.
Step 5
server ip_address
Example:
firewall/Admin(config-ldap)# server 
192.168.252.1
firewall/Admin(config-ldap)# server 
192.168.252.2
firewall/Admin(config-ldap)# server 
192.168.252.3
Adds a server to an LDAP server group. The ip_address argument specifies the IP address for an existing LDAP, server that you want to add to the server group.
Step 6
attribute user-profile text
Example:
firewall/Admin(config-ldap)# attribute 
user-profile usrprof
Configures the LDAP user profile attribute. The text argument is an unquoted text string of a maximum of 63 characters without spaces.
Step 7
base-DN text
Example:
firewall/Admin(config-ldap)# base-DN 
"dc=sns,dc=cisco,dc=com"
Configures the base DN that you want to use to perform search operations in the LDAP directory tree. The text argument identifies the distinguished name of the search base. The base DN name is a quoted text string of a maximum of 63 characters without spaces.
Step 8
filter search-user text
Example:
firewall/Admin(config-ldap)# filter 
search-user "(&(objectclass=person) 
(&(cn=$userid)(cid=$contextid)))" 
Configures the LDAP search filter. The text argument specifies the search request. The search filter is a quoted text string of a maximum of 63 characters without spaces.
Step 9

exit
Example:

firewall/Admin(config-ldap)# exit
firewall/Admin#

Exits LDAP configuration mode.
Step 10
aaa authentication login {console | default} group group_name [local] [none]
Example:
firewall/Admin(config)# aaa authentication 
login console group LDAP_Server_Group1 local 
none 
Configures the authentication method used for login to the VFW application CLI. The arguments, keywords, and options are:

•console—Specifies the console port login authentication method, identified by the specified server group.

•default—Specifies the default login authentication method (Telnet or SSH login), identified by the specified server group.

•group group_name—Associates the login authentication process with an LDAP server defined through the aaa group server command. The server group name is a maximum of 64 characters.

•local—Specifies to use the local database on the VFW application as the login authentication method. If the server does not respond, then the local database is used as the fallback authentication method.

•none—Specifies that the VFW application does not perform password verification. If you configure this option, users can log in to the VFW application without providing a valid password. Only a user with an Admin role is allowed to specify the none option.

Caution Use this option with care. If you specify none, any user can then access the VFW application at any time.
Step 11

exit
Example:

firewall/Admin(config)# exit
firewall/Admin#

Exits global configuration mode.

Step 12

copy running-config startup-config
Example:

firewall/Admin# copy running-config startup-config

(Optional) Saves your configuration changes to flash memory.
Troubleshooting Tip

This task configures the LDAP parameters for a specific LDAP server. To configure the LDAP parameters globally for all servers, use the following commands:

•ldap-server port

•ldap-server timeout

Setting the Global LDAP Server Port Setting

By default, the TCP destination port for communicating authentication requests to the LDAP directory server is 389. If your LDAP server uses a port other than port 389, use the ldap-server port command to globally configure the VFW application for the appropriate port prior to starting the LDAP service. This global port setting is applied to those LDAP servers for which a TCP port value is not individually configured by the ldap-server host command.

For example, to globally configure the TCP port, enter:
firewall/Admin(config)# ldap-server port 2003 
Setting the Global LDAP Server Timeout Value

By default, the VFW application waits five seconds to receive a response from an LDAP server before it declares a timeout failure and attempts to contact the next server in the group. Use the ldap-server timeout command to globally change the time interval that the VFW application waits for the LDAP server to reply to a response before it declares a timeout failure. The VFW application applies this global timeout value to those LDAP servers for which a timeout value is not individually configured by the ldap-server host command.

For example, to globally configure the timeout value to 30 seconds, enter:
firewall/Admin(config)# ldap-server timeout 30 
How to View AAA Status and Statistics

This section contains the following procedures:

•Displaying AAA Groups

•Displaying RADIUS Server Configuration Information

•Displaying TACACS+ Server Configuration Information

Displaying AAA Groups

This task displays the configured AAA server groups.

SUMMARY STEPS

1. show aaa groups

DETAILED STEPS
Command or Action

Purpose
Step 1
show aaa groups
Example:
firewall/Admin# show aaa groups
TACACS:
    TACACS_group1
RADIUS:
    RAD_group1
LDAP:
    LDAP_group2
Displays the configured server groups.
Displaying RADIUS Server Configuration Information

This task displays the configured RADIUS server and group parameters.

SUMMARY STEPS

1. show radius-server

2. show radius-server groups

3. show radius-server sorted

DETAILED STEPS
Command or Action

Purpose
Step 1
show radius-server
Example:
firewall/Admin# show radius-server
retransmission count:1
timeout value:1
deadtime value:20
total number of servers:2
following RADIUS servers are configured:
        192.168.34.45:
                available for authentication on port:1812
                available for accounting on port:1813
        192.168.2.3:
                available for authentication on port:1812
                available for accounting on port:1813
                RADIUS shared secret:********
Displays the configured RADIUS server parameters.
Step 2
show radius-server groups
Example:
firewall/Admin# show radius-server groups
total number of groups:2
following RADIUS server groups are configured:
        group radius:
                server: all configured radius servers
        group RAD_Server_Group:
                deadtime is 0
Displays the configured RADIUS server groups.
Step 3
show radius-server sorted
Example:
firewall/Admin# show radius-server sorted 
retransmission count:1
timeout value:1
deadtime value:20
total number of servers:2
following RADIUS servers are configured:
        192.168.34.45:
                available for authentication on port:1812
                available for accounting on port:1813
        192.168.2.3:
                available for authentication on port:1812
                available for accounting on port:1813
                RADIUS shared secret:********
Displays the sorted RADIUS server groups.
Displaying TACACS+ Server Configuration Information

This task displays the configured TACACS+ server and group parameters.

SUMMARY STEPS

1. show tacacs-server

2. show tacacs-server groups

3. show tacacs-server sorted

DETAILED STEPS
Command or Action

Purpose
Step 1
show tacacs-server
Example:
firewall/Admin# show tacacs-server
Global TACACS+ shared secret:tacacsPword
timeout value:30
total number of servers:3
following TACACS+ servers are configured:
192.168.58.91:
available on port:2
cisco.com:
available on port:49
192.168.22.95:
available on port:49
TACACS+ shared secret:MyKey
Displays the configured TACACS+ server parameters.
Step 2
show tacacs-server groups
Example:
firewall/Admin# show tacacs-server groups
total number of groups:1
following TACACS+ server groups are configured:
group TacServers:
server 192.168.58.91 on port 2
Displays the configured TACACS+ server groups.
Step 3
show tacacs-server sorted
Example:
firewall/Admin# show tacacs-server sorted 
timeout value:1
total number of servers:1
Displays the the sorted TACACS+ servers.
Displaying LDAP Server Configuration Information

This task displays the configured LDAP server and server group parameters.

SUMMARY STEPS

1. show ldap

2. show ldap groups

DETAILED STEPS
Command or Action

Purpose
Step 1
show ldap
Example:
firewall/Admin# show ldap
timeout : 5
        port : 389
total number of servers : 1
Displays the configured LDAP server parameters.
Step 2
show ldap-server groups
Example:
firewall/Admin# show ldap-server groups
total number of groups: 1
following LDAP server groups are configured:
    group LDAP_Server_Group1:
        baseDN: "dc=sns,dc=cisco,dc=com"
        user profile attribute: usrprof
        search filter: "(&(objectclass=person) 
(&(cn=$userid)(cid=$contextid)))"
Displays the configured LDAP server groups.
How to Configure the AAA Server

This section provides general background information on how to set up a TACACS+ or RADIUS server such as the Cisco Secure Access Control Server (ACS). It also covers general guidelines for setting up an LDAP directory server, such as OpenLDAP Software available from OpenLDAP Project. This section is intended as a guide to help ensure proper communication with the AAA server and a VFW application operating as the AAA client. It includes the following sections:

•Configuring a TACACS+ Server

•Configuring a RADIUS Server

•Configuring an LDAP Server

For details on configuring the Cisco Secure ACS, OpenLDAP Software, or another AAA server, consult the documentation provided with the software.

Configuring a TACACS+ Server

The following sections summarize the recommended Cisco Secure ACS TACACS+ user authentication and accounting settings.

•Configuring Authentication Settings on the TACACS+ Server

•Configuring Accounting Settings on the TACACS+ Server

•Defining Private Attributes for Virtualization Support in a TACACS+ Server

Note For the VFW application to properly perform user authentication using a TACACS+ server, the username and password must be identical on both the VFW application and the TACACS+ server.

Configuring Authentication Settings on the TACACS+ Server

To configure the TACACS+ authentication settings on Cisco Secure ACS, perform the following steps:

Step 1 Proceed to the Network Configuration section of the Cisco Secure ACS HTML interface, the Add AAA Client page.

Step 2 Configure the following selections:

•AAA Client Hostname—Enter the name you want assigned to the VFW application.

•AAA Client IP Address—Enter the IP address of the Ethernet interface that you want to use for communicating with the TACACS+ server.

•Key—Enter the shared secret that the VFW application and Cisco Secure ACS use to authenticate transactions. For correct operation, you must specify the identical shared secret on both the Cisco Secure ACS and the VFW application. The key is case-sensitive.

•Authenticate Using—Select TACACS+ (Cisco IOS).

Note The TACACS+ (Cisco IOS) drop-down item is the general title for the Cisco TACACS+ authentication function. The TACACS+ (Cisco IOS) selection activates the TACACS+ option when using Cisco Systems access servers, routers, and firewalls that support the TACACS+ authentication protocol. This includes support with the VFW application as well.

Step 3 Click Submit + Restart.

Configuring Accounting Settings on the TACACS+ Server

To configure the TACACS+ accounting service for the Cisco Secure ACS:

Step 1 In the System Configuration section of the Cisco Secure ACS interface, the Logging Configuration page, click CSV TACACS+ Accounting. The CSV TACACS+ Accounting File Configuration page appears.

Step 2 Confirm that the Log to CSV TACACS+ Accounting report check box is selected.

Step 3 Under Select Columns To Log in the Attributes column, click the attribute you want to log. Click -> to move the attribute into the Logged Attributes column. Click Up or Down to move the column for this attribute to the desired position in the log. Repeat until all the desired attributes are in the desired position in the Logged Attributes column.

Step 4 Click Submit when you finish moving the attributes into the Logged Attributes.

Defining Private Attributes for Virtualization Support in a TACACS+ Server

The same username can be created across contexts and can be associated with a unique role in a context and in multiple domains. Contexts can share a TACACS+ server, but the user must be authenticated for each context and must use the same password.

When a user attempts to log in to the VFW application, the TACACS+ client on the VFW application sends the username and password to the remote TACACS+ server for authentication. The TACACS+ server retrieves a user's profile as part of the authentication request. When the user is successfully authenticated, the TACACS+ server returns a user profile to the TACACS+ client on the VFW application along with the authentication status. If the associated context of the user attempting to log in matches the contexts of the user profile obtained through the TACACS+ server, then the TACACS+ client updates the user profile with the remote server user profile. If the contexts do not match, then the user profile is updated with the default role (Network-Monitor) and the default domain (default-domain).

Configure the user profile on the TACACS+ server to run an Exec shell to configure a shell command authorization for the user. Define a custom attribute with the value string of the following format:
shell:<contextname>=<role> <domain1> <domain2>...<domainN>
Note The user profile attribute serves an important configuration function for a TACACS+ server group. If the user profile attribute is not obtained from the server during authentication, or if the profile is obtained from the server but the context names in the profile do not match the context in which the user is trying to log in, the default role (Network-Monitor) and default domain (default-domain) are assigned to the user, provided that the authentication is successful.

To configure the TACACS+ role and domain settings on Cisco Secure ACS, perform the following steps:

Step 1 Proceed to the Interface Configuration section of the Cisco Secure ACS HTML interface and access the TACACS+ (Cisco IOS) page. Perform the following actions:

a. Under the TACACS+ Services section of the page, in the User column or the Group column depending on your configuration, click the Shell (exec) check box.

b. Under the Advanced Configuration Options section of the page, click the Display a window for each service selected in which you can enter customized TACACS+ attributes check box.

c. Click Submit.

Step 2 Access the Advanced Options page of the Interface Configuration section of the Cisco Secure ACS HTML interface. Perform the following actions:

a. Click the Per-user TACACS+/RADIUS Attributes check box.

b. Click Submit.

Step 3 Proceed to the User Setup section of the Cisco Secure ACS HTML interface, then double-click the name of an existing user for which you want to define a user profile attribute for virtualization. The User Setup page appears.

Step 4 Under the TACACS+ Settings section of the page, configure the following settings:

•Click the Shell (exec) check box.

•Click the Custom attributes check box.

•In the text box below Custom attributes, enter the user role and associated domain for a specific context in the following format:
shell:<contextname>=<role> <domain1> <domain2>...<domainN>
For example, to assign the selected user to the C1 context with the role ROLE1 and the domain DOMAIN1, enter shell:C1=ROLE1 DOMAIN1.

Step 5 Under the Checking This option Will PERMIT all UNKNOWN Services section of the page, click the Default (Undefined) Services check box to permit unknown services.

Step 6 Click Submit when you finish configuring the TACACS+ role and domain settings.

For example, assume that a user named USER1 is assigned the role ADMIN and the domain MYDOMAIN1 (where shell:Admin=ADMIN MYDOMAIN1):

•If USER1 logs in through the Admin context, that user is automatically assigned the Admin role and the MyDomain1 domain.

•If USER1 logs in through a different context, that user is automatically assigned the default role (Network-Monitor) and the default domain (default-domain). In this case, the user profile attribute is not obtained from the TACACS+ server during authentication.

Configuring a RADIUS Server

The following sections summarize the recommended settings for the Cisco Secure ACS RADIUS user authentication and accounting settings.

•Configuring Authentication Settings on the RADIUS Server

•Configuring Accounting Settings on the RADIUS Server

•Defining Private Attributes for Virtualization Support in a RADIUS Server

Configuring Authentication Settings on the RADIUS Server

To configure the RADIUS authentication settings on Cisco Secure ACS, perform the following steps:

Step 1 Go to the Network Configuration section of the Cisco Secure ACS HTML interface.

Note If you are using Network Device Groups (NDGs), you must also click the name of the NDG that you want to add the AAA client entry to.

Step 2 Under the AAA Clients table, select Add Entry. The Add AAA Client page appears.

Step 3 Configure the entries on the Add AAA Client page as follows:

•AAA Client Hostname—Enter a name you want assigned to the VFW application.

•AAA Client IP Address—Enter the IP address of the Ethernet Management port or of the VFW application circuit (depending on how the VFW application is configured to communicate with the Cisco Secure ACS).

•Key—Enter the shared secret that the VFW application and Cisco Secure ACS use to authenticate transactions. For correct operation, you must specify the identical shared secret on both the Cisco Secure ACS and the VFW application. The key is case-sensitive.

•Authenticate Using—Select the AAA protocol, and in the case of RADIUS, the vendor used for communication with the AAA client.

Step 4 Click Submit + Restart.

Cisco Secure ACS saves the AAA client entry and restarts its services, after which it accepts and processes RADIUS requests from the VFW application.

Configuring Accounting Settings on the RADIUS Server

To configure the RADIUS accounting settings on Cisco Secure ACS:

Step 1 Select System Configuration > Logging > CSV RADIUS Accounting. The CSV RADIUS Accounting File Configuration page appears.

Step 2 Confirm that the Log to CSV RADIUS Accounting report check box is selected.

Step 3 In the Select Columns To Log table, be sure that the RADIUS attributes that you want to see in the RADIUS accounting log appear in the Logged Attributes list. In addition to the standard RADIUS attributes, there are several special logging attributes provided by CiscoSecure ACS, such as Real Name, ExtDB Info, and Logged Remotely. For more information about these attributes, refer to the user guide for your CiscoSecure ACS.

Step 4 (Optional) If you are using CiscoSecure ACS for Windows Server, you can specify log file management, which determines how large RADIUS account files can be, how many are retained, for how long, and where they are stored.

Note Cisco Secure ACS also provides a means of sending accounting data to other AAA servers. This is accomplished by configuring the AAA server entry in the Network Configuration section of the HTML interface. For details, see the applicable CiscoSecure ACS user guide.

Step 5 Click Submit when you finish moving the attributes into the Logged Attributes.

Cisco Secure ACS saves and implements the changes you made to its RADIUS accounting configuration.

Defining Private Attributes for Virtualization Support in a RADIUS Server

The same username can be created across contexts and can be associated with a unique role in a context and multiple domains. Contexts can share a RADIUS server, but the user must be authenticated for each context and must use the same password.

When a user attempts to log in to the VFW application, the RADIUS client on the VFW application sends the username and password to the remote RADIUS server for authentication. The RADIUS server retrieves a user's profile as part of the authentication request. When the user is successfully authenticated, the RADIUS server returns a user profile to the RADIUS client on the VFW application along with the authentication status. If the associated context of the user attempting to log in matches the contexts of the user profile obtained through the RADIUS server, then the RADIUS client updates the user profile with the remote server user profile. If the contexts do not match, then the user profile is updated with the default role (Network-Monitor) and the default domain (default-domain).

Configure the user profile on the RADIUS server as a Vendor Specific Attribute with vendor ID Cisco (09) and subattribute type CiscoAVPair (type 01) with a value string of the following format:
shell:<contextname>=<role> <domain1> <domain2>...<domainN>
Note The user profile attribute serves an important configuration function for a RADIUS server group. If the user profile attribute is not obtained from the server during authentication, or if the profile is obtained from the server but the context names in the profile do not match the context in which the user is trying to log in, the default role (Network-Monitor) and default domain (default-domain) are assigned to the user, provided that the authentication is successful.

To configure the RADIUS role and domain settings on Cisco Secure ACS:

Step 1 Proceed to the User Setup section of the Cisco Secure ACS HTML interface, then double-click the name of an existing user for which you want to define a user profile attribute for virtualization. The User Setup page appears.

Step 2 Under the Cisco IOS/PIX RADIUS Attributes section of the page, configure the following settings:

•Click the [009\001] cisco-av-pair check box.

•In the text box below the [009\001] cisco-av-pair check box, enter the user role and associated domain for a specific context in the following format:
shell:<contextname>=<role> <domain1> <domain2>...<domainN>
For example, to assign the selected user to the C1 context with the role ROLE1 and the domain DOMAIN1, enter shell:C1=ROLE1 DOMAIN1.

Step 3 Click Submit when you finish configuring the RADIUS role and domain settings.

For example, assume that a user named USER1 is assigned the role ADMIN and the domain MYDOMAIN1 (where shell:Admin=ADMIN MYDOMAIN1):

•If USER1 logs in through the Admin context, that user is automatically assigned the Admin role and the MyDomain1 domain.

•If USER1 logs in through a different context, that user is automatically assigned the default role (Network-Monitor) and the default domain (default-domain). In this case, the user profile attribute is not obtained from the RADIUS server during authentication.

Configuring an LDAP Server

This section provides background information on the setup of an LDAP directory server, such as the OpenLDAP and Microsoft Active Directory Servers. This section is intended as a general guide to help ensure proper communication with an LDAP server and a VFW application operating as an LDAP client.

As an example, the following section summarizes the recommended configuration setup for the OpenLDAP directory server:

Step 1 Edit the provided slapd.conf example (usually installed as /usr/local/etc/openldap/slapd.conf) to contain a BDB database definition, schema definition, rootDN, and root password.

Step 2 Add a private schema to include the definition of the private attributes (context ID and user profile) and private objectClass, or modify the existing object class. Include this schema in the slapd.conf.

Step 3 Start the LDAP server, slapd. slapd is a standalone LDAP directory server that runs on many different platforms.

Step 4 Create the LDAP database; that is, create a file in LDIF format that contains the database. Ensure that the LDIF file (example.ldif) contains:

dn: dc=example,dc=com

objectClass: dcObject

objectClass: organization

dc: example

o: Example Corporation

description: The Example Corporation

dn: cn=Manager,dc=example,dc=com

objectclass: organizationalRole

cn: Manager

Step 5 Run ldapadd to insert these entries into your directory. For example:
ldapadd -x -D "cn=Manager,dc=example,dc=com" -w secret -f
example.ldif
Defining Private Attributes for Virtualization Support in an LDAP Server

The LDAP client on the VFW application does not assume any specifics about the database structure maintained by the LDAP server. The assumption is that the {userid, contextid} pair uniquely identifies an entry in the database and that this entry contains the user profile attribute. The LDAP client performs a search based on these two attributes, using the search filter configured on the VFW application. The LDAP server locates the correct user entry and the user profile attribute, which is part of that entry, and returns this information in the search response.

The LDAP client can operate in applications where virtualization is not a requirement. In this case, the username alone uniquely identifies the user entry. You configure the search filter to include only the $userid variable (no $contextid). You define these two private attributes from the VFW application CLI through the attribute user-profile command (see the "Configuring LDAP on the VFW Application" section).

You define the user profile attribute value in the following format:
shell:<contextname>=<role> <domain1> <domain2>...<domainN>
Note The user profile attribute serves an important configuration function for an LDAP server group. If the user profile attribute is not obtained from the server during authentication, or if the profile is obtained from the server but the context names in the profile do not match the context in which the user is trying to log in, default role (Network-Monitor) and default domain (default-domain) are assigned to the user, provided that the authentication is successful.

When virtualization is a requirement, the LDAP server must have the contextid attributes defined in the schema. The user-profile attribute (the role-domain information) is required if you need to assign different roles and domains to different users. Consult the LDAP client documentation for information on how to extend the attributetype directive used by the slapd LDAP directory server.

The following steps provide a general example on how to define private attributes for virtualization support in an LDAP server:

Step 1 Add a private schema to include the definition of the private attributes (context ID and user profile) and the private objectClass. For example:
attributetype (2.5.4.55 NAME ( 'ctxid' 'contextid' )
         DESC 'virtual context name'
         SUP name )
attributetype ( 2.5.4.56 NAME ( 'usrprof' 'userprofile' )
         DESC 'user profile'
         SUP name )
objectclass ( 2.5.6.30 NAME 'ctxperson'
         DESC 'a person'
         SUP top STRUCTURAL
         MUST cn
         MAY  ( $ ctxid $ usrprof ) )
The example outlined above includes arbitrary object identifiers (OIDs). The OIDs that you define must not overlap with any of the existing OIDs in the LDAP server database.

Step 2 Include this private schema in the configuration, which would be sladp.conf in case of OpenLDAP.

Step 3 Define the LDAP database in LDAP Data Interchange Files (LDIF) format with entries containing context ID, user profile. LDIF formats are defined in RFC 2849. For example:
dn: ctxid=admin,cn=john,ou=employees,dc=example,dc=com
objectClass: ctxperson
ctxid: admin
cn: john
usrprof: shell:Admin=ROLE-1 DOMAIN-1
userPassword: xxxxxxxx
Step 4 Start the LDAP server, which would be slapd in the case of OpenLDAP.

The LDAP client and LDAP server initiate their interaction, as follows:

•The LDAP client sends a bind request with DN as the configured rootDN and password as the configured root password for the server group.

•When the bind is successful, the LDAP client sends a search request that includes:

–baseDN: Configured baseDN

–scope: Subtree

–search filter: Configured filter with the $userid and $contextid replaced with the actual username and context name, respectively

–attributes: Configured attribute type for userprofile.

•When the search is successful, the LDAP server extracts the matched DN and user profile attribute value from the search response, where the matched DN is the DN for the user.

•Rebind as the user, which involves the LDAP client sending a bind request with DN as the user DN and password as the user password.

•If the bind is successful, the LDAP server returns an authentication PASS message and includes the user profile attribute value in this message.

•The LDAP client sends an unbind request to the LDAP server.

Additional References

The following sections provide references related to authentication and accounting services.

Related Documents

Related Topic

Document Title

Virtual firewall authentication and accounting command syntax

"Authentication and Accounting Commands on the Virtual Firewall" module in Cisco IOS XR Virtual Firewall Command Reference

Standards

Standards

Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.

—

MIBs

MIBs

MIBs Link

—

To locate and download MIBs using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL and choose a platform under the Cisco Access Products menu: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

RFCs

RFCs

Title

No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.

—

Technical Assistance

Description

Link

The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

http://www.cisco.com/techsupport