Cisco Acs 57 User Guide

							21   
Configuring System Operations
Replicating a Secondary Instance from a Primary Instance
To replicate a secondary instance:
1.Choose System Administration > Operations > Local Operations > Deployment Operations.
The Deployment Operations page appears. See the Table 6 on page 15 for valid field options.
2.Click Force Full Replication.
The system displays the following warning message:
This operation will force a full replication for this secondary server. ACS will be restarted. You 
will be required to login again. Do you wish to continue?
3.Click OK.
4.Log into the ACS machine.
5.Choose System Administration > Operations > Distributed System Management.
The Distributed System Management page appears. On the Secondary Instance table, the Replication Status column 
shows UPDATED. Replication is complete on the secondary instance. Management and runtime services are current 
with configuration changes from the primary instance.
Changing the IP address of a Primary Instance from the Primary Server
To change the IP address of a primary ACS server:
1.Log into the ACS primary web interface and Choose System Administration > Operations > Distributed System 
Management to deregister all the secondary ACS instances from the primary ACS server. 
The Distributed System Management page is displayed.
2.Check the check box near the secondary ACS instance one by one and click Deregister.
Make sure that the log collector is running in the primary ACS server before deregistering all secondary ACS 
instances. If the log collector is running in any one of the secondary ACS server, change the log collector to the 
primary ACS server. 
To change the log collector, see Configuring the Log Collector, page 34. 
3.Check the check boxes near the deregistered secondary ACS instances to delete all deregistered secondary ACS 
instances. 
The deregistered secondary ACS instances are deleted.
4.Log into the ACS server in Admin mode by entering:
acs-5-2-a/admin# conf t
5.Enter the following commands:
int g 0
ip address old ip address new ip address 
6.Press Ctrl z.
The following warning message is displayed. 
Changing the hostname or IP may result in undesired side effects, such as installed application(s) 
being restarted.Are you sure you want to proceed? [y/n]  
						

							22
Configuring System Operations
 
Using the Deployment Operations Page to Create a Local Mode Instance
7.Press y
8.Access the primary ACS server using the administrator mode and the new IP address. 
9.Use the command show application status acs to check if all process are running properly. 
10.Register the secondary instances to the primary ACS server. See Registering a Secondary Instance to a Primary 
Instance, page 15
Failover
ACS 5.7 allows you to configure multiple ACS instances for a deployment scenario. Each deployment can have one 
primary and multiple secondary ACS servers.
Scenario: Primary ACS goes down in a Distributed deployment
Consider we have three ACS instances ACS1, ACS2, and ACS3. 
ACS1 is the primary, and ACS2 and ACS3 are secondaries. You cannot make any configuration changes on the 
secondary servers when the primary server ACS1 is down. If all other secondary ACS servers are active, we can make 
any secondary server as a primary server. 
1.Promote the ACS2 to the primary for the time being and use it to make configuration changes. 
See Promoting a Secondary Instance from the Distributed System Management Page, page 19 and Promoting a 
Secondary Instance from the Deployment Operations Page, page 19 to promote a secondary ACS server as a 
primary server. 
N ow,  AC S 2  i s t h e  n e w  p r i m a r y  i n st a n c e.  S o,  we  c a n  m a ke t h e c o n f i g u r a t i on  ch a n g e s o n  AC S 2  a n d  i t  w i l l  b e  i n s t a n t l y  
replicated to ACS3 and on all secondary servers. 
Now, consider the ACS1 is back online. If you need to retain the changes made on ACS2 and the rest of the 
deployment so that ACS1 is the standalone, do not replicate the changes anymore. 
2.Delete ACS2 and ACS3 from the secondary server list of ACS1.
3.Delete ACS1 from ACS2, the current primary server to register ACS1 as secondary. 
Now, ACS2 is the primary server and ACS1 is the secondary server. The deployment is now completely back online.
If you want ACS1 to be the primary server, then you need to promote ACS1 as a primary server.
Using the Deployment Operations Page to Create a Local Mode Instance
When the secondary instance is in local mode it does not receive any configuration changes from the primary instance. 
The configuration changes you make to the secondary instance are local and do not propagate to the primary instance.
To use the Deployment Operations page to create a local mode instance:
1.Choose System Operations > Operations > Local Operations > Deployment Operations.
The Deployment Operations page appears. See the Table 4 on page 10 for valid field options.
2.Specify the appropriate values in the Registration section for the secondary instance you want to register.
3.Click Register to Primary. 
						

							23   
Configuring System Operations
Using the Deployment Operations Page to Create a Local Mode Instance
The system displays the following warning message:
This operation will register this ACS Instance as a secondary to the specified Primary Instance. 
ACS will be restarted. You will be required to login again. Do you wish to continue?
4.Click OK.
5.Log into the ACS local machine.
6.Choose System Administration > Operations > Local Operations > Deployment Operations.
The Deployment Operations page appears. 
7.Click Request Local Mode.
The secondary instance is now in local mode. 
After you reconnect the secondary instance to a primary instance you will lose the configuration changes you made 
to the local secondary instance. You must manually restore the configuration information for the primary instance. 
You can use the configuration information on the ACS Configuration Audit report to manually restore the 
configuration information for this instance.
Creating, Duplicating, Editing, and Deleting Software Repositories
To create, duplicate, edit, or delete a software repository:
1.Choose System Administration > Operations > Software Repositories.
The Software Repositories page appears with the information described in Table 7 on page 23:
2.Perform one of these actions:
Click Create.
Check the check box corresponding to the software repository that you want to duplicate and click Duplicate.
Click the software repository that you want to modify; or, check the check box for the name and click Edit.
Table 7 Software Repositories Page 
Option Description
Name  Name of the software repository.
Note: In ACS web interface, you cannot configure utf-8 characters for a backup filename and a 
repository name.
Protocol Name of the protocol (DISK, FTP, SFTP, TFTP, NFS) you want to use to transfer the upgrade file.
Server Name Name of the server.
Path Name of the path for the directory containing the upgrade file. You must specify the protocol and 
the location of the upgrade file; for example, ftp://acs-home/updates.
Description Description of the software repository.
Download RSA Key Click this option to download the generated RSA public authentication key.
Generate RSA Key Click this option to generate RSA public authentication key for SFTP repositories. 
						

							24
Configuring System Operations
 
Using the Deployment Operations Page to Create a Local Mode Instance
Check one or more check boxes of the software repository that you want to delete and click Delete.
The Software Update Repositories Properties Page page appears. 
3.Complete the fields in the Software Repositories Properties Page as described in Table 8 on page 24:
4.Click Submit. 
The new software repository is saved. The Software Repository page appears, with the new software repository that 
you created, duplicated, or edited.
Related Topics
Managing Software Repositories from the Web Interface and CLI, page 25
Table 8 Software Update Repositories Properties Page 
Option Description
General
Name  Name of the software repository.
Note: In ACS web interface, you cannot configure utf-8 characters for a backup filename and a 
repository name.
Description Description of the software repository.
Repository Information
Protocol The name of the protocol that you want to use to transfer the upgrade file. Valid options are:
DISK—If you choose this protocol, you must provide the path.
FTP—If you choose this protocol, you must provide the server name, path, and credentials.
SFTP—If you choose this protocol, you must provide the server name, path, and credentials.
TFTP—If you choose this protocol, you must enter the name of the TFTP server. You can 
optionally provide the path.
NFS—If you choose this protocol, you must provide the server name and path. You can 
optionally provide the credentials. If you choose this protocol, make sure that ACS has full 
access to the NFS file system. You must have read-write and allow root access permission 
on the NFS file system.
Server Name Name of the FTP, SFTP, TFTP, or NFS server.
Note: The actual location that the repository points to is /localdisk/pathname
Path Name of the path for the upgrade file. You must specify the protocol and the location of the 
upgrade file; for example, ftp://acs-home/updates.
Enable RSA public key 
authenticationCheck this check box if you want to use RSA public key for authentication against SFTP 
repositories. If you enable this option, you have to generate the RSA key from Software 
Repositories page and ACS uses the generated RSA key to connect to the SFTP server. 
User Credentials
Username Administrator name.
Password Administrator password. 
						

							25   
Configuring System Operations
Using the Deployment Operations Page to Create a Local Mode Instance
Managing Software Repositories from the Web Interface and CLI
You can manage repositories from the web interface or the CLI. Keep in mind the rules for creating or deleting 
repositories from the web interface or CLI:
If you create a repository from the CLI, that repository is not visible from the web interface, and can only be deleted 
from the CLI. 
If you create a repository from the web interface, it can be deleted from the CLI; however, that repository still exists 
in the web interface. If you use the web interface to create a repository for a software update, the repository is 
automatically created again in the CLI. 
If you delete a repository using the web interface, it is also deleted in the CLI.
Configuring RSA Public Key for Authentication against SFTP Repositories
In general, when you want to configure an SFTP repository in ACS, you need to configure it with a username and 
password. The password of SFTP users are changing frequently according to the system requirement. Every time when 
there is a change in the user password, user needs to update the password in ACS repository configuration which is 
troublesome. To overcome this problem, ACS allows you to configure SFTP repository with RSA public key based 
authentication. In ACS 5.7, you can configure an SFTP repository with a username and RSA public key using which you 
can authenticate the users.
To configure SFTP repository with RSA Public key authentication, complete the following steps:
1.Login to ACS CLI.
2.Configure an SFTP Repository with RSA public key authentication. For more information, see Configuring SFTP 
Repository in ACS CLI, page 25.
3.Generate RSA Public key. You can generate RSA public key from ACS CLI and ACS web interface. For more 
information on generating RSA public key from ACS CLI, see Generating RSA Public Key, page 26.
4.Export the generated RSA public key to a remote repository. For more information on exporting RSA public key, see 
Exporting RSA Public Key to a remote Repository, page 27.
5.Enable the RSA public key authentication in the SFTP server.   For more information, see Enabling RSA Public Key 
Authentication in SFTP Repository, page 27.
6.Add the exported RSA public key to the authorized keys list on the SFTP server. For more information on adding the 
public key to the authorized keys list, see Adding the Exported RSA Public Key to the Authorized Key List in SFTP 
Repository, page 27.
Note: The RSA public key for SFTP repository is local to ACS server. The RSA public key will not work if you take backup 
on one server and try to restore the backup on a different server.
Configuring SFTP Repository in ACS CLI
To configure SFTP repository in ACS CLI, complete the following steps.
1.Login to ACS CLI.
2.Enter configure terminal to enter the configuration mode.
3.Enter the repository sftp command to enter the configure repository mode.
4.Enter the url sftp:  / command where “repository IP address” is the IP address of 
the SFTP repository and the “path” is the path in which you are going to store the data in the SFTP repository. 
						

							26
Configuring System Operations
 
Using the Deployment Operations Page to Create a Local Mode Instance
5.Perform one of the following actions:
Enter the user  Password {hash  plain}  command to configure the SFTP repository with 
username and password.
Enter the user  rsa-public-key command to configure the SFTP repository with username and RSA 
public key authentication.
Note: You can configure the SFTP repository either using password or RSA public key. 
6.Enter the exit command to come out of the repository configuration mode.
ACS CLI displays the following warning message.
% Warning: Host key of the server must be added using “crypto host_key add” exec command before 
sftp repository can be used.
7.Enter the exit command to come out of the configuration mode.
8.Enter show running-config to see the configured RSA public key for sftp repository.
Generating RSA Public Key
You can generate RSA public key from both ACS CLI and ACS web interface.
Generating RSA Public Key using ACS CLI
To generate RSA public key from ACS CLI, complete the following steps.
1.Login to ACS CLI.
2.Enter the crypto key generate rsa passphrase  command.
3.Press Enter.
The following message is displayed.
RSA key pair for user admin generated.
Generating RSA Public Key using ACS web interface
To generate RSA public key from ACS web interface, complete the following steps.
1.Login to ACS web interface.
2.Choose System Administration > Operations > Software Repositories.
3.Click Generate RSA Key.
4.Enter the Passphrase.
5.Enter the same Passphrase again in the Confirm Passphrase field.
6.Click OK. 
The RSA key is now generated.
Note: If you generate RSA public key from ACS web interface, then you need to download it using the Download RSA 
Key to add it to the authorized_keys file in SFTP repository.  
						

							27   
Configuring System Operations
Using the Deployment Operations Page to Create a Local Mode Instance
Exporting RSA Public Key to a remote Repository 
The SFTP repository is not functional yet. Therefore, you need to export the RSA public key file to a remote repository, 
copy the key file contents from the remote repository and add it to the SFTP repository authorized key file. 
To export the RSA public key to a remote repository, complete the following steps.
1.Login to ACS CLI.
2.Enter the crypto key export  repository  to export the generated RSA key to 
a remote repository.
You can now open the remote repository to which the RSA public key is exported, copy it, and add it to the SFTP 
repository authorized_keys file. 
Enabling RSA Public Key Authentication in SFTP Repository
To enable RSA public key authentication in SFTP repository, complete the following steps.
1.Login to SFTP server with required permission to edit the /etc/ssh/sshd_config file.
2.Enter the vi /etc/ssh/sshd_config command.
SFTP server lists the contents of the sshd_config file. 
3.Remove the “#” symbol from the following three lines to enable the RSA public key authentication. 
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      ~/.ssh/authorized_keys
RSA public key authentication is now enabled in this SFTP server. 
Adding the Exported RSA Public Key to the Authorized Key List in SFTP Repository
To add the exported RSA public key to authorized keys file in SFTP repository, complete the following steps.
1.Login to SFTP server with required permission to edit the /etc/ssh/sshd_config file.
2.Enter the vi /home//.ssh/authorized_keys command. 
This command opens the authorized_keys file from the home repository. If the authorized_keys file is not available, 
then SFTP repository creates a file on the same name. 
3.Copy the contents from RSA public key file that you have exported to a remote repository and paste it in the 
authorized_keys file. 
4.Enter “wq!” to save the authorized_keys file. 
The generated RSA public key is now added to the authorized_keys file in SFTP repository. 
Related Topics
Creating, Duplicating, Editing, and Deleting Software Repositories, page 23
Exporting Policies from ACS Web Interface
Note: This feature works only after installing ACS 5.7 patch 1.  
						

							28
Configuring System Operations
 
Using the Deployment Operations Page to Create a Local Mode Instance
ACS allows you to export the following policies and policy elements from the ACS web interface as an XML file to a 
remote repository or to email ids that you have configured:
Service Selection Policies
Access Service Policies
Network Access Policies
Authorization Profiles
Device Administration Policies
Command Sets
Shell Profiles
Identity Policies
Group Mapping Policies
Authorization Policies
Downloadable Access Lists
You can configure remote repositories in ACS from Software Repositories page in ACS web interface. You can perform 
an instant export or schedule it for a future day and time from the ACS web interface. ACS exports the above mentioned 
policies and policy elements as an XML file and encrypts it with a password. ACS stores the exported XML file in a the 
remote repository or sends an email to recipients configured in the ACS web interface. You can decrypt the exported 
XML file using the encryption password to perform a quick analysis of the ACS configuration and identify any errors. You 
must have an administrator account with SuperAdmin role to export policies from the ACS web interface. ACS does not 
export access service policies of type external proxy. 
Before you Begin
Ensure that you have an administrator account with SuperAdmin role.
To export policies from the ACS web interface:
1.Choose System Administration > Operation > Scheduled Policy Export.
The Scheduled Policy Export properties page appears.
2.Complete the fields in the Scheduled Policy Export page as described in Table 9 on page 28.
Table 9 Scheduled Policy Export Page Properties
Option Description
Export Policy Configuration Data
Encryption Password Enter the password that ACS uses to encrypt the policies file that is being exported. You need to 
use this password to decrypt the exported XML file.
Confirm Encryption 
PasswordEnter the password again which must match the encryption password entry exactly.
Repository Click Select to open the Software Update and Backup Repositories dialog box, from which you 
can select the appropriate repository in which you can store the exported policy file. You need to 
configure the remote repository in Software Repositories page on the ACS web interface.
Email file to  Enter the email address to which an email notification should be sent with the exported XML file. 
You can add multiple email addresses separating them with a comma. 
						

							29   
Configuring System Operations
Trust Communication in a Distributed Deployment
3.Click Submit.
ACS exports the policies and policy elements:
—Immediately after submitting the request if you select the On Demand Export option.
—Saves the schedule and performs the export operation on the scheduled date and time if you select the 
Schedule Export option.
Related Topics
Creating, Duplicating, Editing, and Deleting Software Repositories, page 23
Trust Communication in a Distributed Deployment
ACS introduces the Trust Communication feature, which provides additional security for communication between the 
ACS instances in your deployment. You can use this feature to establish a secure tunnel for communication between the 
primary and secondary ACS instances in a deployment. You can enable Trust Communication on both the primary and 
secondary ACS instances or on either instance. However, for increased security, Cisco recommends that you enable 
Trust Communication on all nodes in your deployment. After the deployment is ready, you cannot edit the Enable Nodes 
Trust Communication settings on secondary ACS instances. The changes that you make in the Trust Communication 
settings of the primary ACS instance will be replicated to all secondary ACS instances. 
In ACS 5.7, when you register a secondary instance to a primary instance, both the primary and secondary instances 
verify each other’s certificates before establishing a secure tunnel for communication. All subsequent transactions 
between these two nodes happen through the established secure tunnel.
By default, Trust Communication is enabled on a fresh ACS instance. If you do not need this type of security, you can 
uncheck the Enable Nodes Trust Communication check box in the Trust Communication Settings page.
When you enable Trust Communication on your primary and secondary ACS instance, and you register the 
secondary instance with the primary, both the primary and secondary instance check the CA and server certificates 
of each other. After the certificates are verified: Mail Server Enter a valid IPv4 or IPv6 email host server. You will not receive an email if you do not configure 
the email server.
Schedule Options
On Demand Export Check this check box if you want ACS to export the policies immediately after submitting the 
request (instant export).
Schedule Export Check this check box if you want ACS to schedule the export operation for a future day and time.
Time of Day Choose the time of the day at which you want ACS to export the policies. The export operation 
can be scheduled on a daily, weekly, or monthly basis.
Daily—Choose this option to export the policies at the specified time every day.
Weekly—Choose this option and specify the day of the week to export policies every week 
on the specified day.
Monthly—Choose this option and specify the day of the month to export policies every month 
on the specified day.
Table 9 Scheduled Policy Export Page Properties (continued)
Option Description 
						

							30
Configuring System Operations
 
Trust Communication in a Distributed Deployment
—If the certificates in both the primary and secondary ACS instances are valid certificates, the instances establish 
a secure tunnel between them and register the secondary instance to the primary.
—If any of the certificates in the primary instance are invalid, the secondary ACS instance stops the registration 
process.
—If any of the certificates in the secondary instance are invalid, the primary ACS instance rejects the register 
request from the secondary ACS instance.
When you enable Trust Communication only in the primary ACS instance and register a secondary to this primary, 
then this primary instance verifies the secondary’s certificates. If the certificates are valid, the primary registers the 
new ACS instance as a secondary instance. The secondary does not verify the primary’s certificates. 
When you enable Trust Communication only in the secondary ACS instance and register this instance to the primary 
instance, then this secondary instance verifies the primary’s certificates during registration. If the certificates are 
valid, the secondary instance proceeds with the registration process. The primary instance does not verify the 
secondary’s certificates. 
Note: If the certificates that you have used for ACS instances in a deployment are invalid (such as expired certificates, 
revoked certificates, and not yet valid certificates), then the primary and secondary ACS instances cannot communicate 
and the system will not work as expected.
Configuring Trust Communication in a Distributed Deployment
Before You Begin
Before enabling Trust Communication between nodes in a distributed deployment, you need to make sure that you have 
done the following:
1.Add a trusted Certificate Authority (CA) certificate in your Primary ACS instance. For more information, see Adding 
a Certificate Authority, page 84.
2.Add a management server certificate duly signed by a valid CA to the primary ACS instance. For more information, 
see Configuring Local Server Certificates, page 16.
3.Add a trusted CA to the ACS instance which is going to be registered as a secondary ACS instance. For more 
information, see Adding a Certificate Authority, page 84. 
4.Add a management server certificate duly signed by a valid CA to the ACS instance that is going to be registered as 
a secondary ACS instance. For more information, see Configuring Local Server Certificates, page 16.
5.Make sure that the CA that issued the server certificate of the secondary instance is present in the primary instance 
and that the CA that issued the server certificate of the primary instance is present in the secondary instance. 
To configure Trust Communication between nodes in a distributed deployment.
1.Choose System Administration > Configuration > Global System Options > Trust Communication Settings.
2.Check the Enable Nodes Trust Communication check box.
3.Click Submit.
Trust Communication between the nodes is enabled now. You can now register a secondary instance to the primary. 
For more information, see Registering a Secondary Instance to a Primary Instance, page 15.