-
User Guide for CiscoWorks Common Services 3.2
-
Notices
-
Preface
-
Chapter 1 Overview of Common Services
-
Chapter 2 Interacting With CiscoWorks Home Page
-
Chapter 3 Using Common Services Home
-
Chapter 4 Configuring the Server
-
Chapter 5 Managing Device and Credentials
-
Chapter 6 Administering Groups
-
Chapter 7 Using LMS Setup Center
-
Chapter 8 Using Device Center
-
Chapter 9 Working With Software Center
-
Chapter 10 Diagnosing Problems With CiscoWorks Server
-
Appendix A Understanding CiscoWorks Security
-
Appendix B Acronyms Used in Common Services Documentation
-
Index
-
Table Of Contents
Managing Security in Single-Server Mode
Setting up Browser-Server Security
Creating Self Signed Certificates
Managing Security in Multi-Server Mode
Setting up Peer Server Account
Setting up System Identity Account
Setting up Peer Server Certificate
Authentication Using Login Modules - Overview
Cisco Secure ACS Support for Common Services Client Applications
Setting the Login Module to Non-ACS
Setting the Login Module to ACS
Authentication Failure in ACS Mode
Integrating CiscoWorks Server With ACS Server
Prerequisites for CiscoWorks-ACS Integration
Changing the Login Module to ACS
Assigning Roles to Users and User Groups in ACS
Setting up Cisco.com User Account
CiscoWorks Server Back-end Processes
Managing Processes Through CLI
Changing the Database Password
Effects of Backup-Restore on DCR
Master-Slave Configuration Prerequisites and Restore Operations
Licensing CiscoWorks Applications
Collecting Self Test Information
Configuring Log Files Rotation
Configuring Disk Space Threshold Limit
Effects of Third Party Backup Utility and Virus Scanner
Configuring CiscoWorks Home Page
Registering Applications With CiscoWorks Home Page
Registering Links With CiscoWorks Home Page
Setting Up CiscoWorks Home Page
Using CiscoWorks Server Hostname Change Scripts
Configuring the Server
Common Services includes administrative tools to configure the server, manage security, and data. You can set up security mechanisms, manage processes, jobs, resources, and generate reports that provide troubleshooting information about the status of the server. You can also configure the CiscoWorks application home page.
This chapter has the following sections:
•
Administering Common Services
•
Setting up Security
Common Services provides security mechanisms that help to prevent unauthenticated access to CiscoWorks Server, CiscoWorks applications, and data. Common Services provides features for managing security while operating in single-server and multi-server modes.
You can specify the user authentication mode using the AAA Mode Setup.
This section explains the following:
•
•
•
•
Managing Security in Single-Server Mode
You can set up browser-server security, add and modify users, and create self signed certificate using the features that come under Single-Server Management in the Security Settings user interface.
This section contains the following:
•
•
Setting up Browser-Server Security
Common Services provides secure access between the client browser and management server. It does this using SSL (Secure Socket Layer).
SSL encrypts the transmission channel between the client, and server. Common Services provides secure access between the client browser, and management server.
SSL is an application-level protocol that enables secure transactions of data through privacy, authentication, and data integrity. It relies upon certificates, public keys, and private keys.
You can enable SSL if you want to open the CiscoWorks application in secure mode. If you want to open the CiscoWorks application in non-secure mode (http), you can disable SSL. The login pages always open in SSL mode, irrespective of the Browser-Server security mode.
CiscoWorks Server uses certificates for authenticating secure access between the client browser and the management server. To enable SSL from the client browser, you must have the necessary security certificates on your computer. See Creating Self Signed Certificates for more information.
You can enable or disable the Browser Server Security using CiscoWorks Server GUI or Command Line Interface CLI.
This section has the following:
•
•
•
•
•
•
Enabling Browser-Server Security From the CiscoWorks Server
To enable Browser-Server Security:
Step 1
The Browser-Server Security Mode Setup dialog box appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
Step 4
Step 5
On Windows:
a.
b.
On Solaris:
a.
b.
Step 6
When you restart the CiscoWorks session after enabling SSL, you must enter the URL with the following changes:
•
•
If you do not make the above changes, CiscoWorks Server will automatically redirect you to https mode with port number 443. The port numbers mentioned above are applicable for CiscoWorks Server running on Windows.
On Solaris, if the default port (1741) is used by another application, you can select a different port during CiscoWorks Server installation.
Enabling Browser-Server Security From the Command Line Interface (CLI) On Windows Platforms
To enable Browser-Server Security from CLI:
Step 1
Step 2
Step 3
Step 4
•
•
Step 5
The CiscoWorks Server creates the security certificate. You can use this certificate to enable SSL in the CiscoWorks Server from your client browser.
Step 6
Step 7
a.
b.
Step 8
When you restart the CiscoWorks session after enabling SSL, you must enter the URL with the following changes:
•
•
If you do not make the above changes, CiscoWorks Server will automatically redirect you to HTTPS mode with port number 443. The port numbers mentioned above are applicable for CiscoWorks Server running on Windows.
Enabling Browser-Server Security From the Command Line Interface (CLI) On Solaris Platforms
To enable Browser-Server Security from CLI:
Step 1
Step 2
Step 3
Step 4
•
•
Step 5
The CiscoWorks Server creates the security certificate. You can use this certificate to enable SSL in the CiscoWorks Server from your client browser.
Step 6
Step 7
a.
b.
Step 8
When you restart the CiscoWorks session after enabling SSL, you must enter the URL with the following changes:
•
•
If your CiscoWorks Server is integrated with any Network Management Station (NMS) in your network using the integration utility (NMIM), you must perform the integration every time you enable or disable SSL in the CiscoWorks Server. This is required to update the application registration in NMS.
For more information, see the Integration Utility Online Help.
Disabling Browser-Server Security From the CiscoWorks Server
To disable Browser-Server Security:
Step 1
The Browser-Server Security Mode Setup dialog box appears.
Alternatively, you can navigate to this page from the LMS Portal home page if you have installed the LMS Portal application on CiscoWorks Server.
Step 2
Step 3
Step 4
Step 5
On Windows:
a.
b.
On Solaris:
a.
b.
Step 6
When you restart the CiscoWorks session after disabling SSL, you must enter the URL with the following changes:
•
•
The port numbers mentioned above are applicable for CiscoWorks Server running on Windows.
On Solaris, if the default port (1741) is used by another application, you can select a different port during CiscoWorks Server installation.
Disabling Browser-Server Security From the Command Line Interface (CLI) On Windows Platforms
To disable Browser-Server Security from CLI:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
a.
b.
Step 7
When you restart the CiscoWorks session after disabling SSL, you must enter the URL with the following changes:
•
•
The port numbers mentioned above are applicable for CiscoWorks Server running on Windows.
Disabling Browser-Server Security From the Command Line Interface (CLI) On Solaris Platforms
To disable Browser-Server Security from CLI:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
a.
b.
Step 7
When you restart the CiscoWorks session after disabling SSL, you must enter the URL with the following changes:
•
•
If your CiscoWorks Server is integrated with any Network Management Station (NMS) in your network using the Integration Utility (NMIM), you must perform the integration every time you enable or disable SSL in the CiscoWorks Server. This is required to update the application registration in NMS.
For more information, see the Integration Utility Online Help.
Setting up Local User Policy
You can setup username and password policies for CiscoWorks local users in Common Services.
With the new local user policy, you can:•
•
•
•
You can apply only one local user policy at a time.
You cannot define policies for each local user. The local user policy you set up applies to all users including the administrative users.
The local usernames that begin with numbers and contain special characters overcomes the security limitations of authentication and authorization in CiscoWorks Servers integrated with pluggable authentication modules such as Active Directory.
To set up local user policies:
Step 1
The Local User Policy Setup page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
You can include the following special characters in the username:
~
Tilde
@
Commercial At character
#
Number sign
_
Underscore
'
Apostrophe
-
Hyphen
/
Solidus or Leading slash
\
Trailing slash
.
Period
space
Non-breaking space
Note
Step 3
You can enter any number between 0 to 9 in the username as the first character if you have enabled this option.
Step 4
The default minimum length is 5 characters and the default maximum length is 256 characters.
You can enter any number between 1 to 256 in the minimum and maximum fields.
Ensure that you do not enter a number in minimum username length field that is greater than the number in maximum username length field.
Step 5
The default minimum length is 5 characters and the default maximum length is 256 characters.
You can enter any number between 1 to 256 in the minimum and maximum fields.
Ensure that you do not enter a number in minimum password length field that is greater than the number in maximum password length field.
Step 6
Setting up Local Users
Local User Setup feature helps you in:
You can also set up local users and reset CiscoWorks password through CLI. See the following sections for more information:
•
•
About User Accounts
Several CiscoWorks network management and application management operations are potentially disruptive to the network or to the applications themselves, and must be protected.
To prevent such operations from being used accidentally or maliciously, CiscoWorks uses a multi-level security system that only allows access to certain features to users who can authenticate themselves at the appropriate level.
Common Services provides two predefined login IDs:
•
•
The login named admin is the equivalent of a superuser (in Solaris) or an administrator (in Windows). This login provides access to all CiscoWorks tasks.
However, as an administrator, you can create additional unique login IDs for users at your company.
Note
Understanding Security Levels
System administrators determine user security levels when users are granted access to CiscoWorks. When users are granted logins to the CiscoWorks application, they are assigned one or more roles.
A role is a collection of privileges that dictate the type of system access you have. A privilege is a task or operation defined within the application. The set of privileges assigned to you, defines your role and dictates how much and what type of system access you have.
The user role or combination of roles, dictates which tasks are presented to the users. The following table shows the security levels.
0
Help Desk
1
Approver
2
Network Operator
4
Network Administrator
8
System Administrator
16
Export Data
For information on tasks that can be performed with each role, see Permissions Report. See also About CiscoWorks Common Services Pluggable Authentication. Other roles are displayed, depending on your applications.
Modifying Your Profile
To edit your profile:
Step 1
The Local User Setup page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
Step 4
Step 5
This is mandatory if you assign the approver role to the local user. Otherwise, this is optional.
Step 6
Adding a Local User
You can add further users into CiscoWorks as required.
You can add only one user at a time through the user interface. See Setting Up Local Users Through CLI for adding bulk users.
To add a user:
Step 1
The Local User Setup page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The User Information dialog box appears.
Step 3
The local username is case-insensitive.
You can control the length of the username, start the local username with a number, and include special characters in the local username.
To do this, you must set up the username and password policy in the Local User Policy Setup page. See Setting up Local User Policy for information.
Note
Step 4
You can control the length of the password when you set up policies for local users. See Setting up Local User Policy for information.
Step 5
Step 6
This is mandatory if you assign the approver role to the local user. Otherwise, this is optional.
Step 7
The following roles are available:
•
•
•
•
•
•
See About CiscoWorks Common Services Pluggable Authentication for more details on each role.
Step 8
Editing User Profiles
You can edit the user profiles to modify the roles assigned to the users.
To edit user profiles:
Step 1
The Local User Setup page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The User Information dialog box appears.
Note
Step 3
Step 4
Step 5
This is mandatory if you assign the approver role to the local user. Otherwise, this is optional.
Step 6
Step 7
Deleting Local Users
To delete local users:
Step 1
The Local User Setup page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
A confirmation dialog box appears.
Step 4
Setting Up Local Users Through CLI
You can set up the local users through CLI. This feature helps you in:
Adding Local Users
You can add bulk local users through CLI. This feature allows you to specify a file that has the information about the local users as an input. The input file you use should be a plain text file.
Each local user information should be represented in the following format in the text file:
Username:Password:E-mail:Roles
where,
•
•
You can leave this field blank in the text file and enter the password in the command line when you run the CLI utility.
Note that you should enter the password either in the command line or in the input text file. If you mention the password in both the places, the local user will be added with the password specified in the command line.
•
This is mandatory if you assign the approver role to the local user. Otherwise, this is optional.
•
–
–
–
–
–
–
The following is an example of local user information to be represented in input text file:
admin123:admin123:admin123@cisco.com:sa,na,ap,hdaekaek:aekpasswd:aek@cisco.com:sa,na,ap,hd testuser::testuser@cisco.com:sa,na,ap,hdTo add local users through CLI, enter the following commands:
•
•
where,
•
•
This command line parameter is optional if you have specified the passwords for local users in the input text file. Note that you should enter the password either in the command line or in the input text file.
If you specify this parameter, the local users are added to CiscoWorks only with this password irrespective of the password entries specified in the input text file.
For example, enter the following command to add local users mentioned in the input file localuser.txt with the password admin:
C:\progra~1\CSCOpx\bin\perl C:\progra~1\CSCOpx\bin\AddUserCli.pl -add C:\files\localuser.txt admin
Even if you have entered password for the local users in the localuser.txt file, the local users are added with the password mentioned in the command line.
Importing Local Users
This feature allows to import the local user information to the local server from a remote CiscoWorks server.
You should have the privileges to import local users from remote CiscoWorks server through CLI.
Before you import users from a remote server, you should install the peer certificate of the remote server in the local CiscoWorks server, if the CiscoWorks server is in HTTPS mode. See Setting up Peer Server Certificate for more information.
To import users from a remote server, enter the following commands:
•
•
where,
•
The supported values are HTTP or HTTPS.
•
•
•
•
For example, enter the following command to import the local users from the remote CiscoWorks Server lmsdocpc:
NMSROOT\bin\perl NMSROOT\bin\AddUserCli.pl -import HTTP lmsdocpc 1741 admin admin
Log Files
The information on the users added or imported into the CiscoWorks Server are stored in the following files:
•
•
The AddUser.log file registers the information on the number of users added or imported into CiscoWorks Server successfully, number of duplicate users, error messages and other information which you can use for troubleshooting.
Changing CiscoWorks User Password Through CLI
You can change the CiscoWorks user password using the CiscoWorks user password recovery utility.
To change the user password on Solaris:
Step 1
Step 2
A message appears:
Enter new password for username:Step 3
Step 4
To change the user password on Windows:
Step 1
Step 2
A message appears:
Enter new password for username:Step 3
Enter net start crmdmgtd to start the Daemon Manager.
Creating Self Signed Certificates
CiscoWorks allows you to create security certificates that enable SSL communication between your client browser and management server.
Self signed certificates are valid for five years from the date of creation. When the certificate expires, the browser prompts you to install the certificate again from the server where you have installed CiscoWorks.
Note
This section explains the following:
•
•
•
•
Creating a Self Signed Certificate From the User Interface
To create a certificate from the user interface:
Step 1
The Certificate Setup page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
The process generates the following files:
•
•
•
•
You can use CSR file to request a security certificate, if you want to use a third party security certificate.
If the certificate is not a Self signed certificate, you cannot modify it.
Working With Third Party Security Certificates
CiscoWorks provides an option to use security certificates issued by third party certificate authorities (CAs). You may want to use this option in cases where your organizational policy prevents you from using CiscoWorks self-signed certificates or requires you to use security certificates obtained from a particular CA.
You can use these certificates to enable SSL when you need secure access between CiscoWorks Server and your client browser.
Uploading Third Party Security Certificates to CiscoWorks Server
You can upload Third Party Security Certificates using the SSL Utility Script.
This utility is available at:
•
•
This utility has the following options:
Using the SSL Utility Script to Upload Third Party Security Certificates
To upload the certificates:
Step 1
On Windows:
•
On Solaris:
•
Step 2
On Windows:
a.
b.
On Solaris:
a.
b.
Step 3
Step 4
The script verifies if the server certificate is valid. After the verification is complete, the utility displays the options.
If the script reports errors during validation and verification, the SSL Utility displays instructions to correct these errors. Follow the instructions to correct those errors and then try to upload the certificates.
Step 5
Or
Select option 6, if you have a certificate chain to upload, that is if you have a server certificate and intermediate certificates.
CiscoWorks does not allow you to proceed with the upload if you have not stopped the CiscoWorks Daemon Manager.
The utility displays a warning message if there are hostname mismatches detected in the server certificate being uploaded, but you can continue to upload the certificate.
Step 6
•
•
SSL Utility uploads the certificates, if all the details are correct and the certificates meet CiscoWorks requirements for security certificates.
Step 7
Enable SSL to establish a secured connection between CiscoWorks Server and your client browser, if you have not enabled already.
Managing Security in Multi-Server Mode
Communication among peer servers that are part of a multi-server domain has to be secure. In multi-server mode the server is configured as DCR Master/Slave or SSO Master/Slave. In a multi-server scenario, secure communication between peer CiscoWorks Servers is enabled using certificates and shared secrets.
You must copy certificates between the CiscoWorks Servers. You should also generate a shared secret on one server, and configure it on the other servers that need to communicate with the server. The shared secret is tied to a particular CiscoWorks user (for authorization).
This section has the following information which helps you to understand more about the features that enables secure communication between peer servers part of a multi-server domain:
•
•
•
Setting up Peer Server Account
Peer Server Account Setup helps you create users who can programmatically login to CiscoWorks Servers and perform certain tasks. These users should be set up to enable communication among multiple CiscoWorks Servers. Users created using Peer Server Account Setup can authenticate processes running on remote CiscoWorks Servers.
In ACS mode, the user created with Peer Server Account Setup needs to be configured in ACS, with all the privileges that user has in CiscoWorks.
See Master-Slave Configuration Prerequisites to know more about the usage of this feature.
You can add a Peer Server user, edit user information and role, and delete a user.
To add a Peer Server user:
Step 1
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Peer Server Account Setup page appears.
Step 3
Step 4
Step 5
Step 6
To edit Peer Server user information:
Step 1
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Peer Server Account Setup page appears.
Step 3
Step 4
Step 5
To delete a Peer Server user:
Step 1
The Peer Server Account Setup page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
The confirmation dialog box appears.
Step 4
Setting up System Identity Account
Communication between multiple CiscoWorks Servers is enabled by a trust model addressed by certificates and shared secrets. System Identity setup helps you to create a "trust" user on servers that are part of a multi-server setup. This user enables communication among servers that are part of a domain.
There can only be one System Identity User for each machine.
The System Identity User you configure must be a Peer Server User.
In Non-ACS mode, the System Identity User you create must be a local user with all privileges.
In ACS mode, the System Identity User should be configured in Cisco Secure ACS, with all the privileges the user has in CiscoWorks. You can either configure the System Identity User with the predefined Super Admin role or with a custom role created with all privileges in ACS Server. If you change the System Identity User in ACS later, you must ensure to add the local user with all privileges in CiscoWorks.
CiscoWorks installation program allows you to have the admin user configured as the default System Identity User.
For the admin user to work as a System Identity User, the same password should be configured on all machines that are part of the domain, while installing CiscoWorks on the machines part of that domain. If this is done, the user admin serves the purpose of System Identity user. See Installing and Getting Started With LAN Management Solution 3.1 for details.
However, you can create a System Identity User from the Common Services UI as well (Common Services > Server > Security > Multi-Server Management > System Identity Setup).
If you create a System Identity User, the default System Identity User, admin, is replaced by the newly created user.
While you create the System Identity User, Common Services checks whether:
•
•
•
For peer to peer communication to work in a multi-server domain, you have to configure the same System Identity User on all the machines that are part of the domain.
For example, if S1, S2, S3, S4 are part of a domain, and you configure a new System Identity User, say Joe, on S1, you have to configure the same user, Joe, with the same password you specified on S1, on all the other servers, S2, S3, and S4, to enable communication between them.
See Master-Slave Configuration Prerequisites and Enabling Single Sign-On to know more on the usage of this features.
To add a System Identity user:
Step 1
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
Step 4
Step 5
Setting up Peer Server Certificate
You can add the certificate of another CiscoWorks Server into its trusted store. This will allow one CiscoWorks Server to communicate to another using SSL. If a CiscoWorks Server needs to communicate to another CiscoWorks Server, it must possess the certificate of the other server. You can add certificates of any number of peer CiscoWorks Servers to the trusted store.
You must add peer server certificates if CiscoWorks Servers are configured with Self-Signed Certificates. If the certificates have been signed by popular CAs such as Verisign, GlobalSign etc. this is not compulsory. However we recommend that you add peer server certificates to avoid any possible problems with SSL communication.
You can use this option from the client browser and from a browser session on the server where CiscoWorks Server is installed.
Ensure that there are no mismatches in the date and time settings between the servers. In case you find any date or time mismatch, you need to correct it before proceeding.
If you change the date or time of the peer server, you must regenerate the self signed certificate of the peer server.
To add peer CiscoWorks Server certificates:
Step 1
The Peer Server Certificate page appears with a list of certificates imported from other servers.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
If you specify a server name, it must be entered in DNS. Otherwise specify IP Address.
Step 4
Step 5
To delete peer certificates:
Step 1
Step 2
You can also view the details of the client certificates. For this, select the check box corresponding to the certificate and click View.
Enabling Single Sign-On
With Single Sign-On (SSO), you can use your browser session to transparently navigate to multiple CiscoWorks Servers without authenticating to each of them. Communication among multiple CiscoWorks Servers is enabled by a trust model addressed by Certificates and shared secrets.
The following tasks need to be done initially:
•
•
•
The SSO authentication server is called the Master, and the SSO regular server is called the Slave.
You must perform the following tasks if the server is either configured as Master or Slave:
•
•
SSO uses System Identity user password as the secret key to provide confidentiality and authenticity between Master and Slave. We recommend that you have the same user name and password for both Master and Slave.
The Common Name (CN) in the certificate should match with that of the Master server name. Otherwise it would not be considered as a valid certificate.
SSO is used only for authentication and not for authorization. In SSO, authentication always takes place from the SSO Master server (Authentication Server-AS). Hence you need to provide the username and password as configured in SSO AS. Authorization happens at the respective servers.
If Regular Server (RS) is configured for any Pluggable Authentication Module (PAM), say Active Directory (AD), and AS is configured for CiscoWorks Local, then authentication happens as per the credentials in CiscoWorks Local (AS) and vice versa.
For example, if server A is configured as SSO Master (AS) and the AAA mode setup is Active Directory (AD) and Server B is configured as SSO Slave (RS) and the AAA mode setup is CiscoWorks Local.
When you login to server B (http://B:1741), your authentication request is forwarded to serve A (AS) and you get authenticated according to the username and password configured in AD. However, authorization happens only in server B.
The privileges for the logged in user in any server within the SSO domain will depend upon the user's roles configured in that server. If the user is present only in the SSO authentication server and not in the regular server, then that user gets authenticated according to the credentials in the authentication server, but has only have HelpDesk privileges in the regular server.
We recommend that you:
•
•
•
To set up System Identity User:
Step 1
Step 2
Step 3
SSO uses the System Identity User password as the secret key to provide confidentiality and authenticity between Master and Slave.
The System Identity User password you specify in Master and Slave should be the same.
We recommend that you have the same user name and password across Master and Slave.
To configure Master's Self Signed Certificate in the Slave, select Common Services > Server > Security > Multi-Server Management > Peer Server Certificate Setup > Add.
The Common Name (CN) in the certificate should match with the Master server name. Otherwise it would not be considered as a valid certificate.
Navigating Through the SSO Domain
The Authentication Server and all Regular Servers that are configured on this Authentication Server forms an SSO domain. If you login to any of the servers that are part of the same SSO domain, you can launch any other server that is part of the domain.
You can navigate through the SSO domain in two ways:
•
Registering Server Links
You can register the links of servers part of the SSO domain, in any of the servers, using the Link registration feature. See Registering Links With CiscoWorks Home Page.
The registered links will appear either under Third Party or Custom tools, depending on what you specify during registration. If you click on the registered link, it launches the page corresponding to the registered link.
You must specify the URL, with the context while registering the server link.
For example, let ABC and XYZ be part of the same SSO domain. You can register the link for ABC on XYZ. While registering server ABC in XYZ, you have to specify the URL as:
http://ABC:1741/cwhp/cwhp.applications.doIf ABC is running in HTTPS mode, you have to specify the URL as:
https://ABC:443/cwhp/cwhp.applications.doIn the above example, clicking on the registered link will launch the CiscoWorks home page of server ABC.
Launching a New Browser Instance
After logging into any of the servers part of the SSO domain, you can open a new browser instance from that server, and provide the URL of any other server part of the SSO domain, to which you need to navigate to.
Note
For example, suppose ABC and XYZ are part of an SSO domain.
Step 1
Step 2
Step 3
This launches the CiscoWorks home page of XYZ, directly.
Changing the Single Sign-On Mode
The Common Services server can be configured for Single Sign-On (SSO). It can also be configured to be in Standalone mode (Normal mode, without SSO).
When the server is configured for SSO, it can either be in:
•
Change the SSO mode to Master, if login is required for all SSO regular servers. Login requests for all the SSO regular servers will be served from the Master.
•
While logging into regular server, if the authentication server is not reachable, the following message appears:
SSO unreachableOnly one server is configured to be in the Master mode. All other servers are configured as Slaves. If the server is configured as an SSO Regular server (Slave), you should provide the following details:
•
The Master server name must be DNS resolvable. If you change the name of the SSO Master server, in the /etc/hosts file, you must restart Daemon Manager for the name resolution to reflect in the Slave.
When you have configured more than one SSO Slave servers for a SSO Master server, you must ensure to enter either the fully qualified domain name or hostname of the Master consistently in all the Slave servers.
Authentication would not occur if you enter a domain name of Master in a SSO Slave and hostname of the Master in another SSO Slave of the same Master server.
•
To change the SSO mode to Standalone:
Step 1
The Single Sign-On Configuration page shows the current Single Sign-On mode.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
To change the SSO mode to Master:
Step 1
The Single Sign-On Configuration page shows the current Single Sign On mode.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
To change the SSO mode to Slave:
Step 1
The Single Sign-On Configuration page shows the current Single Sign-On mode.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
If you select the Slave mode, ensure that you specify the Master server name and port. The default port is 443. The server configured as Master (or Authentication Server) should be DNS resolvable.
Step 4
It checks whether:
•
•
•
In case these checks fail, you are prompted to perform these steps before proceeding.
Setting up the AAA Mode
The CiscoWorks Server provides mechanisms used to authenticate users for CiscoWorks applications.
CiscoWorks login modules allow administrators to add new users using a source of authentication other than the native CiscoWorks Server mechanism (that is, the CiscoWorks Local login module). You can use Cisco Secure ACS services for this purpose (see Setting the Login Module to ACS).
However, many network managers already have a means of authenticating users. To use your current authentication database for CiscoWorks authentication, you can select a login module (Kerberos, TACACS+, Radius, and others).
After you select and configure a login module, all authentication transactions are performed by that source.
To assign a user to a different role, such as the System Admin role, you must configure the user locally. Such users must have the same user ID locally, as they have in the alternative authentication source. Users log in with the user ID and password associated with the current login module.
This section contains:
•
•
•
•
Authentication Using Login Modules - Overview
CiscoWorks login modules allow administrators to add new users using a source of authentication other than the native CiscoWorks Server mechanism (that is, the CiscoWorks Local login module).
This section contains:
•
•
About CiscoWorks Common Services Pluggable Authentication
By default, CiscoWorks Common Services uses CiscoWorks Server authentication (CiscoWorks Local) to authenticate users, and authorize them to access CiscoWorks Common Services applications.
After authentication, your authorization is based on the privileges that have been assigned to you.
A privilege is a task or an operation defined within the application. The set of privileges assigned to you, defines your role. It dictates how much, and what type of system access you have.
The CiscoWorks Server authorization scheme has the following default roles. They are listed here from the least privileged to most privileged:
•
•
•
•
•
•
You can assign this role to a user only on Cisco Secure ACS Server and only after you have:
–
–
You cannot assign a local user with this role. This role is not visible in CiscoWorks local mode and during the local user setup in CiscoWorks Server.
The CiscoWorks Server determines user roles. Therefore, all users must be in the local database of user IDs and passwords. Users who are authenticated by an alternative service and who are not in the local database are assigned to the same role as the guest user (by default, the Help Desk role).
If you configure Common Services to use Non-ACS for authentication, authorization services are provided by CiscoWorks Server.
In Non-ACS mode, you cannot change the roles, or the privileges assigned to these roles. However, a user can be assigned a combination of these roles. See Modifying Your Profile.
When the login module is ACS, both authentication and authorization takes place from ACS. Hence it is not mandatory that the user be present in the local database. The user roles will be as assigned in ACS.
In ACS mode, you can create custom roles so that you can customize Common Services client applications to best suit your business workflow and needs.
That is, you can create a user, and assign the user with a set of privileges, that would suit your needs. See Authentication Failure in ACS Mode and Roles in ACS for details.
Understanding Fallback Options for Non-ACS mode
Fallback options allow you to access the software if the login module fails, or you accidentally lock yourself or others. There are three login module fallback options. These are available on all platforms. The following table gives you the details:
Debugging
CiscoWorks allows you to enable debugging on the current login module so that you have additional information in the log files that you can use for troubleshooting. Turn debugging on only when requested to do so by your customer service representative.
Enabling debugging does not alter the behavior of the modules.
Debugging information is not exposed in the user interface, but is stored in the stdout.log file in the following locations:
•
•
where NMSROOT is the CiscoWorks installation directory.
Cisco Secure ACS Support for Common Services Client Applications
CiscoWorks Common Services supports ACS mode of authentication and authorization. To use this mode, you must have a Cisco Secure ACS (Access Control Server), installed on your network. Common Services 3.1 supports the following versions of Cisco Secure ACS:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
We recommend that you install the Admin HTTPS PSIRT patch, if you are using ACS 3.2.3.
To install the patch:
Step 1
Step 2
You can find the link to the Admin HTTPS PSIRT patch, in the table.
CiscoSecure ACS provides authentication, authorization, and accounting services to network devices that function as AAA clients. CiscoSecure ACS uses the TACACS+ and RADIUS protocols to provide AAA services that ensure a secure environment.
Cisco Secure ACS supports Common Services client applications by providing command authorization for network users who use the management application to configure managed network devices. Command authorization for client application users is supported using unique command authorization set types for each client application configured to use Cisco Secure ACS for authorization.
Cisco Secure ACS uses TACACS+ to communicate with client applications. For a client application to communicate with Cisco Secure ACS, you must configure it in Cisco Secure ACS as an AAA client that uses TACACS+.
Also, you must provide the client application with a valid administrator name and password. When a client application initially communicates with Cisco Secure ACS, these requirements ensure the validity of the communication.
Additionally, the administrator (used by the client application) must have the Create New Device Command Set Type privilege enabled. When a client application initially communicates with Cisco Secure ACS, it makes the Cisco Secure ACS create a new device command set type.
This new device command set type appears in the Shared Profile Components section of the HTML interface. It also specifies a custom service to be authorized by TACACS+. The custom service appears on the TACACS+ page in the Interface Configuration section of the HTML interface.
After the client application has specified the custom TACACS+ service and device command set type to CiscoSecure ACS, you can configure command authorization sets for each role supported by the client application. You can then apply those sets to user groups that contain network administrators or to individual users who are network administrators.
For more information about configuring Cisco Secure ACS administrators, users, and command authorization sets, and the various configuration options see the User Guide for CiscoSecure Access Control Server 4.x on Cisco.com, or the CiscoSecure ACS Online help.
Note
Setting the Login Module to Non-ACS
The Login Module defines how authorization and authentication are performed and how to change the login modules.
This section explains the following:
•
•
•
•
•
•
•
•
•
To set the login module to Non-ACS mode:
Step 1
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Login Module window displays the current login module, and the available login modules.
The available login modules are:
•
•
•
•
•
•
•
•
•
The login username is case sensitive when you use the following Non-ACS login modules:
•
•
•
•
•
Step 3
The Login Module Options popup window appears.
Step 4
See the respective login module section for login module options.
Step 5
Changing Login Module to CiscoWorks Local
To change the login module to CiscoWorks Local:
Step 1
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Login Module window displays the available login modules.
Step 3
Step 4
The Login Module Options popup window appears.
Step 5
Set it to True for debugging purposes, when requested by your customer service representative.
Step 6
Changing Login Module to IBM SecureWay Directory
The IBM SecureWay Directory login module implements Lightweight Directory Access Protocol (LDAP). Before a user can log in, a user's account is set up in the LDAP server. The user's account has two fields, Distinguished name and password.
A Distinguished name is made up of three parts, Prefix, User login, and Usersroot. Userroot is queried for the username during login and the Distinguished name is automatically created.
If the user is not found, then the Distinguished name is created by appending Prefix + login name + Usersroot.
For example, a Distinguished name could be represented as: uid=John ou=embu o=cisco.com, where the Prefix is uid=, the login name is John, and the Usersroot ou=embu, o=cisco.com).
To change the login module to IBM SecureWay Directory:
Step 1
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Login Module window displays the available login modules.
Step 3
Step 4
The Login Module Options popup window appears with the following details:
Step 5
Changing Login Module to KerberosLogin
Kerberos provides strong authentication for client/server applications by using secret-key cryptography.
To change the Login Module to KerberosLogin:
Step 1
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Login Module window displays the available login modules.
Step 3
Step 4
The Login Module Options popup window appears with the following details:
Step 5
Changing Login Module to Local Unix System
This option is available only on Unix systems.
To change the login module to Local Unix System:
Step 1
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Login Module window displays the available login modules.
Step 3
Step 4
The Login Module Options popup window appears with the following details:
Step 5
Changing Login Module to Local NT System
This option is available only on Windows
To change the login module to Local NT System:
Step 1
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Login Module window displays the available login modules.
Step 3
Step 4
The Login Module Options popup window appears with the following details:
Step 5
Changing Login Module to MS Active Directory
The MS Active Directory login module implements Lightweight Directory Access Protocol (LDAP). Before an user logs in, the user's account should be set up in the LDAP server.
When you change the login module to MS Active Directory, you should configure any one of the following options to integrate CiscoWorks Server with Active Directory server for authentication services:
•
A distinguished name is made up of three parts, Relative Distinguished Name Prefix (RDN-Prefix), User login, and Usersroot.
You have to configure RDN-Prefix and Usersroot in CiscoWorks. The login name is appended to RDN-Prefix when the user logs into CiscoWorks.
For example, a distinguished name could be represented as:
cn=User_Name ou=org1 dc=embu dc=cisco. The RDN Prefix is cn=, User login is User_Name, and Usersroot is ou=org1 dc=embu, dc=cisco.A Distinguished Name is composed of cn (any numbers), ou (any numbers) and dc (any numbers).
You can specify more than one usersroot value. Each usersroot value should be separated by a semicolon.
•
User principal name is composed of two parts, User login and User Principal Name Suffix (UPN-Suffix).
The login name of the user is appended to User Principal Name Suffix configured in CiscoWorks, when the user logs into CiscoWorks.
The second part of the UPN, the UPN suffix, identifies the domain in which the user account is located. This UPN suffix can be the DNS domain name, the DNS name of any domain, or it can be an alternative name created by an administrator and used just for log on purposes.
For example, a User Principal Name could be represented as user1@mydept.mycompany.com, where user1 is the login name and @mydept.mycompany.com represents the UPN-Suffix.
•
You should configure the Active Directory domain name in CiscoWorks that contains a set of users who needs to be integrated, for a domain based authentication.
For example, if you want the users of MyDomain domain in MS Active Directory server to be authenticated in CiscoWorks Server, you should specify MyDomain in this field.
Each domain also has a pre-Windows 2000 domain name for use by computers running the operating systems released earlier than Windows 2000 operating systems. Similarly each user account has pre-Windows 2000 user login name.
The user account in the DomainName\UserName format used to log into the operating systems released earlier than Windows 2000 operating systems is called Security Account Manager (SAM) account. You can also configure SAM account in the LDAP server and enter the same name in CiscoWorks when you change the login module to Microsoft Active Directory.
When the Distinguished Name based authentication to Active Directory server fails, CiscoWorks attempts to authenticate the Active Directory server using the User Principal Name string.
When both the Distinguished Name based authentication and the User Principal Name based authentication fails, CiscoWorks Server tries to authenticate using the Domain name.
To change login module to MS Active Directory:
Step 1
The AAA Mode setup page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Login Module window displays the available login modules.
Step 3
Step 4
The Login Module Options popup window appears with the following details:
Note
Step 5
After the integration of CiscoWorks Server with MS Active Directory server, you can log into CiscoWorks Server with an Active Directory username and the corresponding password.
Active Directory users logged into CiscoWorks has the privileges of a Help Desk role. To assign other privileges to Active Directory users, you must set up a user in CiscoWorks with the same name.
For example, to assign the System Administrator privileges to a MS Active Directory users User1 and User2 in CiscoWorks, you must set up User1 and User2 in CiscoWorks and assign System Administrator role to them. When the users log into CiscoWorks, they have the System Administrator privileges also.
Changing Login Module to Netscape Directory
The Netscape Directory login module implements Lightweight Directory Access Protocol (LDAP). Before a user can log in, a user's account is set up in the LDAP server. The user's account has two fields, Distinguished name and password.
A Distinguished name is made up of three parts, Prefix, User login, and Usersroot. Userroot is queried for the username during login and the Distinguished name is automatically created. If the user is not found, then the Distinguished name is created by appending Prefix + login name + Usersroot.
For example, a Distinguished name could be represented as:
uid=John ou=embu o=cisco.com, where the Prefix is uid=, the login name is John, and the Usersroot ou=embu, o=cisco.com).To change login module to Netscape Directory:
Step 1
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Login Module window displays the available login modules.
Step 3
Step 4
The Login Module Options popup window appears with the following details:
Step 5
Changing Login Module to Radius
To change login module to Radius:
Step 1
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Login Module window displays the available login modules.
Step 3
Step 4
The Login Module Options popup window appears with the following details:
Step 5
Changing Login Module to TACACS+
To change login module to TACACS+:
Step 1
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Login Module window displays the available login modules.
Step 3
Step 4
The Login Module Options popup window appears with the following details:
Note
Step 5
After you change the login module, you do not have to restart CiscoWorks. The user who logs in after the change, automatically uses the new module. Changes to the login module are logged in the following files:
•
•
where NMSROOT is your CiscoWorks Installation directory.
Setting the Login Module to ACS
By default, the login module is set to local authentication and authorization. You can change this default value to use Cisco Secure ACS for user authentication and authorization. CiscoWorks uses HTTP port 2002 to communicate with ACS Server.
Before you change the login module to ACS, you must do the following:
•
•
•
See Integrating CiscoWorks Server With ACS Server for detailed steps on how to set up the ACS Server.
This section contains the following:
•
•
•
•
•
Setting Up the AAA Mode to ACS
To set the login module to ACS:
Step 1
The AAA Mode Setup page appears with the AAA Mode Setup dialog box.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
•
•
•
Enter the corresponding ACS TACACS+ port numbers. The default port is 49. TACACS+ is used for AAA requests.
Secondary and Tertiary IP address/hostname details are optional. When the Primary ACS Server fails, the AAA requests are redirected to the Secondary or Tertiary backup servers.
An active ACS Server is determined among the three servers, Primary, Secondary, and Tertiary, and the authentication requests from CiscoWorks Server are forwarded to the active server. The active ACS Server is determined and maintained when you log into CiscoWorks Server.
When you have multiple ACS Servers, ensure that all of the servers have the same configuration.
If you enter hostname of ACS Servers in the Primary, Secondary or Tertiary Server fields instead of IP addresses on CiscoWorks Server, ensure that the hostname is reachable and DNS (Domain naming system) resolvable from the CiscoWorks Server.
Step 4
•
•
•
Also, re-enter the ACS Admin Password, and ACS Shared Secret Key in the Verify fields.
For Primary, Secondary, and Tertiary servers, the ACS Admin Name, the ACS Admin Password, and the ACS Shared Secret Key should be the same.
Step 5
If an application is already registered with ACS, the current registration will overwrite the previous registration.
When you select the Register all installed applications with ACS checkbox, you will be prompted to confirm whether you want to proceed with the registration. When you confirm this, all installed applications are registered with ACS, but any custom role created in ACS will be lost. See Additional Notes on Setting the AAA Mode to ACS for more information.
To register an application with ACS without overwriting the custom roles created for other applications, use AcsRegCli.pl command line script. See Registering Applications With ACS Through CLI for details.
Step 6
HTTP/HTTPS mode is used for application registration, device or device group import/export tasks, and for administrative purposes such as audit logging, accounting and so on.
Primary, Secondary, and Tertiary servers should use the same protocol. All of them should either operate in HTTP mode, or HTTPS mode.
You must enable ACS communication on HTTPS, if ACS is in HTTPS mode. You need not enable CiscoWorks Server in HTTPS mode when HTTPS protocol is selected in the login module page.
Step 7
The system verifies the connectivity with all ACS Servers through the specified protocol.
The ACS Verification Status popup window appears with the verification status of one or more ACS Servers configured.
For example, if you had configured only the primary and secondary ACS Servers in the AAA Mode Setup window, the ACS Verification Status popup window appears with the verification status of only these two servers.
The ACS Verification Status popup window lists the status of the following:
If the verification status fails for all the ACS Servers configured, you will not be able to apply the mode change. You should change the settings and try again to change the mode.
Step 8
The Apply button is enabled only when the verification status for atleast one of the ACS Servers is successful.
The login module is set to ACS and all applications are registered successfully with the ACS Server.
Step 9
On Windows:
a.
b.
On Solaris:
a.
b.
Additional Notes on Setting the AAA Mode to ACS
You should read the following notes before using the CiscoWorks applications in ACS mode:
•
•
•
See Integrating CiscoWorks Server With ACS Server for the complete procedure to integrate CiscoWorks Server with ACS Server.
Registering Applications With ACS
You should register the applications in ACS Server, when you change the login module to ACS in CiscoWorks Server.
When you register the applications in ACS Server:
•
•
The application registration with ACS fails due to any of the following reasons:
•
If ACS is running in HTTPS mode, enable the Connect to ACS in HTTPS mode checkbox in the Login Module dialog box.
•
Ensure that the ACS credentials provided in the CiscoWorks AAA Mode setup screen are correct.
•
Configure the ACS administrator with at least the following privileges in ACS:
–
–
–
•
Nearly 9 administrative ports are required to register an application with ACS. For example, to register three CiscoWorks applications, you must allocate 27 administrative ports.
Check whether you have assigned sufficient administrative ports before registering the applications.
After registering, you can reduce the number of administrative ports allocated.
Registering Applications With ACS Through CLI
You can use the AcsRegCli.pl command line script to register an application without affecting the registration status of other applications. The script is located at NMSROOT/bin.
You can run AcsRegCli.pl only when the CiscoWorks Server is in ACS mode.
You can perform any one of the following functions using the CLI script:
•
•
•
•
To get a list of available options, run the script AcsRegCli.pl without specifying any option.
The following options are listed:
•
•
•
To know this value, run AcsRegCli.pl with the option -listRegApp or -listNotRegApp.
•
For example, to register RME with the ACS Server, you should run the following command:
/opt/CSCOpx/bin/perl /opt/CSCOpx/bin/AcsRegCli.pl -register rme
When you register one or more applications in ACS Server:
•
•
You will be prompted for confirmation even when you have not registered the application from the current server. If you have already registered the application with ACS from another server and if you confirm and proceed after the warning message, any custom roles you have created in ACS for this application will be lost.
Unregistering Applications From ACS Through CLI
You can use the AcsRegCli.pl command line script to unregister an application without affecting the registration status of other applications.
You can unregister a specific application or all the applications.
•
–
–
where,
NMSROOT — CiscoWorks Installation directory.
•
•
–
–
Authentication Failure in ACS Mode
When you try log into CiscoWorks Server in ACS mode, authentication may fail due to the following possible reasons:
•
•
•
•
•
•
You can try to login into ACS mode again or you can change the login module of CiscoWorks Server to CiscoWorks local. See Resetting Login Module for more information.
Before you try again to login into ACS mode, you should:
•
•
Resetting Login Module
If there is an authorization failure with ACS Server, most of the Common Services features will be disabled. To recover, you have to reset the login module of CiscoWorks Server to CiscoWorks local:
Step 1
•
or
•
Step 2
•
or
•
where NMSROOT is your CiscoWorks Installation directory.
Step 3
•
or
•
This resets the login module to CiscoWorks local mode.
Step 4
Step 5
Step 6
You are now logged into CiscoWorks Server.
Multiple instances of same application (for example, Common Services) using the same ACS Server will share the settings. Any change affects all instances of the application. If the application is configured with ACS and then the application is reinstalled, the application inherits the old settings.
Integrating CiscoWorks Server With ACS Server
The Login Module determines the type of authentication and authorization Common Services uses. By default, the login module is set to local authentication and authorization.
You can change this default value to use Cisco Secure ACS for user authentication and authorization. CiscoWorks uses HTTP port 2002 to communicate with ACS Server.
See Cisco Secure ACS Support for Common Services Client Applications for more information on ACS support for CiscoWorks applications.
You should read the following documents to understand about Cisco Secure ACS, and its support for CiscoWorks application:
•
This guide explains the features in Cisco Secure ACS. We recommend you to review the guide available on Cisco.com for any updates.
•
This whitepaper contains the end-to-end integration instructions of CiscoWorks Server with ACS Server. This whitepaper is available on Cisco.com at:
http://www.cisco.com/en/US/products/sw/cscowork/ps2425/prod_white_papers_list.html
This section explains the following:
•
•
•
Prerequisites for CiscoWorks-ACS Integration
Before you integrate the CiscoWorks Server with ACS, ensure that you:
1.
See Setting up System Identity Account to configure a System Identity User.
2.
You should add the System Identity User as a local user and assign all the privileges in CiscoWorks Server.
See Setting up Local Users to configure System Identity User configured as a local user and assign all privileges in CiscoWorks Server.
If System Identity User is not configured with all local user privileges, authorization fails when you try perform certain tasks in CiscoWorks Server.
Setting up ACS Server
You should set up your ACS Server before you change the login module to ACS mode. The following sections explain you the configurations to be done in ACS Server:
•
•
•
•
•
Configuring ACS Administrators
You should configure the ACS administrators with all privileges in ACS. The ACS administrator account in ACS is required to:
•
•
Also, if you do not configure the ACS administrative user with all the privileges, the application registration with ACS will fail.
Note
To configure an ACS Administrator:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
To remove the assigned privileges, click Revoke All.
Step 8
Creating a Network Device Group
Network Device Groups (NDGs) are collection of AAA clients such as servers and network devices.
You should add the group of servers and network devices only under a NDG. You can use the existing NDGs or you can create a new NDG for this purpose.
You should have administrative privileges on Cisco Secure ACS Server to create or edit NDGs.
Note
You can create a NDG in the Network Configuration page. By default, you cannot create a Network Devices Groups in a ACS Server after a fresh installation of ACS software.
To enable the creation and modification of NDGs:
Step 1
Step 2
Step 3
Step 4
To create a new Network Device Group:
Step 1
Step 2
The list of Network Device Groups appear.
Step 3
The New Network Device Group page appears.
Step 4
Step 5
Step 6
Tip
Adding CiscoWorks Server and Network Devices as AAA Clients in ACS
You should configure the following as AAA Clients in ACS Server:
1.
2.
You should add the devices managed by CiscoWorks in ACS after you have configured the CiscoWorks Server as a AAA client.
If you do not configure the devices as AAA clients in ACS, the devices will not be visible in CiscoWorks Server after the integration.
We recommend that you have 50,000 devices as a maximum in your ACS Server. More number of devices may affect the system performance.
To configure the AAA clients in ACS:
Step 1
Step 2
Step 3
If a NDG is not available, you can create a NDG using the Add Entry button. See Configuring ACS Administrators for more information.
Step 4
Step 5
The name entered in this field for a network device will be updated in the Display Name field in DCR.
Step 6
You can specify multiple IP Addresses in the text field. If the CiscoWorks Server is a multi-homed machine, you should enter all the IP Addresses of the machine in this field. To separate the IP Addresses, press Enter.
You can use the following to enter the IP Address of CiscoWorks Server:
•
•
You can also enter the hostname of the devices in this field. If the devices are resolved by their DNS from CiscoWorks Server, then these devices are imported in DCR using their IP addresses during the device import from ACS.
If the devices are not resolved by its DNS from CiscoWorks Server, they are imported into DCR using their hostnames.
Step 7
This secret key is used for device authorization. You should enter the same value in the Common Services AAA Mode Setup page during the mode change.
The NDG key entered during NDG creation has priority than a secret key of individual AAA clients. Each AAA client that is associated to a NDG will use the NDG key if entered. The secret keys that are entered for individual devices or AAA clients will be ignored.
Step 8
Step 9
Step 10
Or
Click Submit + Apply if you are using ACS 4.0 or later versions.
We recommend that you use the Submit + Restart or Submit + Apply button only when required, as this could temporarily interrupt all Cisco Secure ACS services.
Otherwise, you can use the Submit option, and you can apply the changes later when you are ready to implement them.
You can also configure a default AAA client. To configure a default AAA client, you should follow the procedure mentioned as above. However, you need not specify the hostname and IP Address while configuring the default client. The client will be configured in ACS with default name as Others and default IP Address as 0.0.0.0.
Configuring CiscoWorks Administrative Users in ACS
You should add CiscoWorks System Identity User and other CiscoWorks administrators in ACS. Otherwise if you log in as a user configured only in Common Services, authentication will not happen.
You can create a user group in ACS and add all users to that user group.
To define a user group in ACS:
Step 1
Step 2
Step 3
Users logging in for the first time are mapped to the default group and will be assigned the privileges and restrictions that the default group has.
Step 4
To add CiscoWorks Administrative users including the System Identity User in ACS:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Configuring Multiple ACS Servers
You can configure multiple ACS Servers to handle the incoming authentication requests without any network downtime. Configuration of multiple ACS Servers is particularly useful if the primary server goes out of service.
If you are using more than one ACS Server to provide authentication, authorization and accounting services to CiscoWorks Server, you should do the necessary configurations in all the ACS Servers. The AAA clients, NDGs and other settings must be the same across all ACS Servers.
For example, to integrate a CiscoWorks Server, if you want to set up Server X, Server Y and Server Z as Primary, Secondary and Tertiary ACS Servers, you must ensure that the settings are the same in all the servers.
You can also duplicate the information stored in a Cisco Secure ACS Server to one or more ACS Servers using the Database replication feature available in ACS.
See User Guide for CiscoSecure Access Control Server 4.x on Cisco.com to know more about the ACS multi-server configuration and database replication.
Changing the Login Module to ACS
After you have configured the necessary settings in ACS Server, you should change the login module of CiscoWorks Server to ACS.
See Setting the Login Module to ACS for detailed steps on changing the login module to ACS.
However, note the following before you proceed to the next step in the integration:
•
•
•
Roles in ACS
After authentication, your authorization is based on the privileges that have been assigned to you. A privilege is a task or an operation defined within the application. The set of privileges assigned to you, defines your role.
You can either:
•
Or
•
This section explains the following:
Predefined Roles
The ACS authorization scheme provides you the following default roles.
•
•
•
•
•
•
Custom Roles
If you do not want to use the default roles, you can create the custom roles. You can create custom roles and assign any subset of tasks to users and user groups.
To create a new role:
Step 1
Step 2
The Shared Profile Components page appears.
Step 3
Step 4
Step 5
Tasks are displayed as a checklist tree on the left pane of the ACS UI.
•
•
Step 6
To edit an existing role:
Step 1
Step 2
The Shared Profile Components page appears.
Step 3
The Shared Profile Components page displays the Edit dialog box.
Step 4
If you want to remove any task associated with the role, deselect the check box corresponding to the task.
Step 5
To delete a role:
Step 1
Step 2
The Shared Profile Components page appears.
Step 3
The Shared Profile Components page displays the Edit dialog box.
Step 4
Common Services Tasks
When Common Services is registered with ACS, the following is a subset of Common Services tasks that appear in ACS:
•
•
•
•
•
•
•
•
•
The tasks are allowed or denied to a user or a user group based on the role assigned in ACS.
The Permissions Report in Common Services displays the detailed information on default roles in CiscoWorks Server and the privileged tasks for each role. See Permissions Report for more information.
Assigning Roles to Users and User Groups in ACS
You ensure that the CiscoWorks user or the user group has been assigned the proper privileges in ACS mode. You can assign a desired role to the user or user group, or assign roles per NDG basis.
This section contains the following:
•
•
Assigning Roles to User Groups
To assign the roles and privileges to the user if ACS is configured to use group authentication:
Step 1
Step 2
Step 3
A page appears with the group settings.
Step 4
•
Authorization will fail for any task.
•
Select the desired role from the drop-down list. The user group can perform the tasks that are assigned to the chosen role on all devices and device groups.
•
Select the device group from the Device Group drop-down list. Choose the role you want to associate with the device group. The user group can perform the tasks that are assigned to the chosen roles on the chosen device groups.
For example, you can assign the system administrator role to the selected user group for one device group and assign the operator role to the same user group for another network device group. See Assigning Roles on NDG Basis for more information.
Step 5
Step 6
Assigning Roles to Users
You can assign roles to users in ACS to perform CiscoWorks tasks, only when you have enabled the user authentication for CiscoWorks Services.
To enable the user authentication for CiscoWorks Services in ACS:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
To assign the roles and privileges if ACS is configured to use user authentication:
Step 1
Step 2
Or,
Click List all Users and click the required user link from the User List.
A page appears with the user details and settings.
Step 3
The CiscoWorks options are available only when you have enabled the user authentication for CiscoWorks Services.
The options are:
•
•
•
Select the desired role from the drop-down list. The user can perform the tasks that are assigned to the chosen role, on every device.
•
Select the device group from the Device Group drop-down list. Choose the role you want to associate with the device group. The user can perform the tasks that are assigned to the chosen roles on the chosen device groups.
For example, you can assign the system administrator role to the selected user for one device group and assign the operator role to the same user for another network device group.
See Assigning Roles on NDG Basis for more information.
Step 4
Step 5
Assigning Roles on NDG Basis
You can choose to assign any number of role and device group combinations for a selected user or user group to operate on Network Device Groups.
You should note the following to assign roles on a NDG basis:
•
You cannot have role and device group combinations assigned to a user without assigning the Network Device Group where your AAA client is present.
•
•
For example, if a user needs to have Approver and Network Operator privileges to operate on NDG1, you can create a new custom role with Network Operator and Approver privileges, and assign the role to the user to operate on NDG1.
•
•
To assign the proper role, the network access server (NAS) should be added in the device groups other than DEFAULT.
Network Access Restrictions to Users and User Groups in ACS
You can restrict the network access to any user or user group from a specified AAA client hostname or IP Address. You can create any additional conditions which a user or user group should meet before accessing the network.
You should use a Network Access Restrictions (NAR) filter in ACS to allow or deny the users to access the network.
You will be able to configure the NAR filters only when only have enabled the group-level and user-level Network Access Restrictions options in the Advanced Options page.
See User Guide for CiscoSecure Access Control Server 4.x on Cisco.com to know more about Network Access Restrictions.
Managing Cisco.com Connection
Certain Software Center features require Cisco.com access. This means that CiscoWorks must be configured with a Cisco.com account which is to be used when downloading new and updated packages.
This section explains:
•
Setting up Cisco.com User Account
To set up Cisco.com login account:
Step 1
The Cisco.com Login dialog box appears.
If LMS Portal is installed on the CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
Step 4
Setting Up the Proxy Server
You can update the proxy server configuration using the Proxy Server set up option.
To update your proxy server configuration:
Step 1
The Proxy Information dialog box appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Optionally, you can enter the Username and Password for accessing the proxy server.
If you have entered your Password, re-enter the same password in the Verify Password field.
Step 3
Generating Reports
Common Services includes a Report Generator that provides detailed reports on log file status, roles and privileges, users currently logged in, processes that are currently running and system activities that occur within CiscoWorks Common Services client applications.
The following reports are available:
The following sections describe how to launch these reports, and explain each report.
To generate a report:
Step 1
The Reports page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
The Report window appears with the summary of details. You can use the navigation buttons provided to navigate between the report pages, if the generated reports has more records.
You can perform the following activities from the Reports window:
•
•
•
•
Log File Status Report
The Log File Status Report provides information on log file size and file system utilization.
To generate the log file status report:
Step 1
The Reports page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
The Log File Status Report appears with the following details:
Permissions Report
The Permissions Report provides information on roles and privileges associated with the roles. It specifies the tasks that a user in a particular role can perform.
A privilege is a task or an operation defined within the application. The set of privileges assigned to you, defines your role and dictates how much, and what type of system access you have.
The Permissions Report does not display the information about new Super Admin role added to CiscoWorks applications and the tasks associated with this role.
To generate the Permissions Report:
Step 1
The Reports page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
The Permissions Report appears.
In the enhanced Permissions Report, the tasks are grouped based on applications or modules and presented in a tabular form. Each task group displays the tasks associated with an application and the roles assigned to perform the task.
You can locate a particular task within a task group in the permissions report. You can also sort the display of tasks in alphabetical order or in reverse alphabetical order, within a task group.
Users Logged In Report
The Users Logged In Report provides information on users currently logged into Common Services.
To generate the Report:
Step 1
The Reports page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
The Users Logged In report appears with the following information:
The privileges displayed are applicable only for Non-ACS mode and the report may not display the complete list in ACS mode.
You should use the Logout button to close all the browser sessions and logout from the CiscoWorks Server. Otherwise, the sessions will not be closed properly and the Who is Logged On report may show the incorrect user information.
Tip
Process Status Report
The Process Status Report shows the status of the processes running on the CiscoWorks Server.
To generate the Process Status Report:
Step 1
The Reports page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
The Process Status Report appears with the following information:
Process Name
Name of the process. Describes how process is registered.
See CiscoWorks Server Back-end Processes for more information about Common Services Server processes. For information on suite-specific processes, see the relevant Online Help.
State
Current state of the process and a summary of the log file entries for the process. This column will be highlighted in red if the process fails.
Pid
Process ID. A unique number by which the operating system identifies each running program.
RC
Return code. 0 represents normal program operation. Any other number typically represents an error. Refer to the error log.
Signo
Signal number. 0 represents normal program operation. Any other number is the last signal delivered to the program before it terminated.
Start Time
Time at which the process started.
Stop time
Time at which the process stopped.
Core
Not applicable means the program is running normally.
CORE FILE CREATED means the program is not running normally and the operating system has created a file called core*.
The core file stores important data about processes.
core* refers to name of the core file. The core file name contains the executable file name of the program and the process ID.
For example, the name of the core file created for the Perl module is:
core.perl.51234Information
Describes what the process is doing.
Not applicable means the program is not running normally.
Viewing Audit Log Report
In both non-ACS mode and ACS mode, Audit log report provides information on:
•
•
•
•
•
Audit Logs are stored as comma-separated value lists (CSVs) on local server even if you are using local authentication or ACS authentication.
To view Audit Log Report:
Step 1
The Report Page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Audit Log Data Viewer appears with a list of audit logs.
The Audit Logs are listed in reverse chronological order, with the most recent logs appearing at the bottom of the list. The logs are named and listed by the date on which they were created. For example: Audit-Log-2004-10-27.csv.
Step 3
The Audit Log report contains:
Administering Common Services
Common Services includes several administrative features to ensure that the server is performing properly. You can manage process, set up backup parameters, update licensing information, collect server information, manage jobs and resources, and configure system-wide information on the CiscoWorks Server.
This section has the following information:
•
•
•
•
•
•
Using Daemon Manager
The Daemon Manager provides the following services:
•
•
•
•
The Daemon Manager is useful to applications that have long-running processes that must be monitored and restarted, if necessary. It is also used to start processes in a dependency sequence, and to start transient jobs.
Restarting Daemon Manager on Solaris
To restart Daemon Manager on Solaris:
Step 1
Step 2
Step 3
Do not start the Daemon Manager immediately after you stop it. The ports used by Daemon Manager will be in use for some more time even after the Daemon Manager is stopped. Wait for at least a minute before you start the Daemon Manager.
If the System resources are less than the required resources to install the application, Daemon Manager restart displays warning messages that are logged into dmgtd.log.
You cannot start the Daemon Manager if there are Non-SSL compliant applications installed on the server when SSL is enabled in Common Services.
Restarting Daemon Manager on Windows
To restart Daemon Manager on Windows:
Step 1
Step 2
Step 3
Do not start the Daemon Manager immediately after you stop it. The ports used by Daemon Manager will be in use for some more time even after the Daemon Manager is stopped. Wait for at least one minute before you start the Daemon Manager.
If the System resources are less than the required resources to install the application, Daemon Manager restart displays warning messages that are logged into syslog.log.
Managing Processes
CiscoWorks applications use back-end processes to manage application-specific activities or jobs. The process management tools enable you to manage these backend processes to optimize or troubleshoot the CiscoWorks Server.
You can do the following activities:
•
•
•
•
All mandatory processes are started when you start the system.
See CiscoWorks Server Back-end Processes for a list of CiscoWorks back-end processes used by Common Services.
You can manage the CiscoWorks processes through CLI. See Managing Processes Through CLI for more information.
Note
This section contains the following:
•
Process States
The state of the CiscoWorks backend processes fall under either one of the following categories:
Viewing Process Details
To view Process details:
Step 1
The Process Management page appears with all CiscoWorks processes listed.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
You can see the following information of a CiscoWorks process in the Process Management window:
ProcessName
Name of the process. Describes how process is registered. See CiscoWorks Server Back-end Processes for more information on process description. For information on suite-specific processes, see the relevant Online help.
You cannot view the details of Apache and Tomcat processes or restart them from the user interface. But you can view the details of these processes in Process Status report. See Process Status Report for more information.
ProcessState
Process status and a summary of the log file entries for the process. If the process fails, this column is highlighted in red.
ProcessId
Unique number by which the operating system identifies each running program.
ProcessRC
Return code. 0 represents normal program operation. Any other number typically represents an error. See the error log for details.
ProcessSigNo
Signal number. 0 represents normal program operation. Any other number is the last signal delivered to the program before it terminated.
ProcessStartTime
Time and date the process was started.
ProcessStopTime
Time and date the process was stopped.
Step 2
The Process Details popup window appears with the following information:
You can click the Refresh icon on the top-right corner of the page to initiate a page refresh and view the updated information of the processes.
Viewing Processes of a Specific State
To view processes of a specific state:
Step 1
The Process page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
You can select any one of the following process states:
•
•
•
•
•
•
•
See Process States for description of each of these process states.
The details of processes of the selected state appears.
Starting a Process
To start a process:
Step 1
The Process page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
Stopping a Process
To stop a process:
Step 1
The Process page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
CiscoWorks Server Back-end Processes
The back-end processes in the CiscoWorks Server are required to manage application specific activities and jobs.
Table 4-1 lists the back-end processes in CiscoWorks Server, their description and dependent process.
Table 4-1 CiscoWorks Server Back-end Processes and their Descriptions
Apache
Apache web server used on both UNIX and Windows systems. This hosts the base CiscoWorks home page and all major applications.
You cannot view the details of this process or restart this process from the user interface (from Process Management page).
Program started - No mgt msgs received
Tomcat
CmfDbEngine
Sybase database instance used by the base CiscoWorks framework.
Program started - No mgt msgs received
None
CmfDbMonitor
Monitors the CmfDbEngine process and periodically checks for connectivity and SQL errors.
Running normally
CmfDbEngine
CMFOGSServer
Device grouping service in CS that provides grouping capability based on device attributes stored in DCRServer.
Never started
CmfDbMonitor, EssMonitor, DCRServer
CSDiscovery
Transient process created by Daemon Manager and is responsible for initiating Device Discovery.
Transient Terminated
—
CSRegistryServer
Registry Server for other CS processes such as DCRServer and CMFOGSServer and provides the backbone for inter-process communication for DCRServer and CMFOGSServer.
Sometimes, the Tomcat process may start this process. In such cases, the process status is displayed as follows:
Administrator has shut down this server
You can ignore this error message.
Running normally
—
DCRServer
Device List and Credential Repository Server that provides the repository for shared device list and credentials to be used across applications.
Running normally
TomcatMonitor, CmfDbMonitor, EssMonitor
diskWatcher
Monitors disk space availability on the CiscoWorks Server.
See Configuring Disk Space Threshold Limit for more information.
Running normally
—
EDS
Legacy Event Distribution engine. This is currently used by some applications to send and receive event messages.
Running normally
NameServiceMonitor
EDS-GCF
EDS - Generic Consumer Framework process. It is an extension to EDS that allows Generic Event Consumers to provide a pluggable event interface.
Running normally
EDS, CmfDbMonitor
ESS
Event Services Software. The new engine that handles distribution of events between processes. This is slated to eventually replace EDS.
Program started - No mgt msgs received
—
EssMonitor
Monitors ESS process to check if events related functionality works properly. This process shuts down automatically when the ESS process fails or does not function properly.
Running normally
ESS
FDRewinder
(Solaris Only)
Enables the rotation of log files functionality using logrot.
Never started
—
jrm
Job and Resource Manager. This allows scheduling of jobs to be run at specific times. It also allows locking/unlocking of resources.
Program started - No mgt msgs received
CmfDbMonitor, NameServiceMonitor, EDS, EssMonitor
LicenseServer
Provides Licensing functionality for evaluation and file based licensing mechanisms.
Program started - No mgt msgs received
—
NameServiceMonitor
Name Service agent that monitors objects and messages and acts as a gateway between the JacORB clients and the Name Server.
Program started - No mgt msgs received
NameServer
NameServer
Object Request Broker for the JacORB framework used in CiscoWorks.
Running Normally
—
Tomcat
Java servlet engine used on Windows and Solaris systems hosting applications based on the CiscoWorks desktop.
You cannot view the details of this process or restart this process from the user interface (from Process Management page).
Program started - No mgt msgs received
—
TomcatMonitor
Monitors the health of Tomcat process and shuts down automatically when Tomcat fails or does not function properly.
Running normally
Tomcat
Managing Processes Through CLI
You can also manage the CiscoWorks processes through CLI. You can perform the following activities through CLI:
•
•
Viewing Process Details Through CLI
The pdshow command displays the details of the specified processes or all processes in the CLI prompt.
•
–
–
where NMSROOT is the CiscoWorks installation directory.
•
–
–
where ProcessName1 and ProcessName2 are the name of the processes, and NMSROOT is the CiscoWorks installation directory.
The command displays the process details of one or more processes. See Viewing Process Details for description of each of these items.
•
•
•
•
•
•
•
The pdshow command additionally displays the following process details.
During the startup of Daemon Manager, sometimes the pdshow command may display information message requesting to wait and enter the command again.
This happens particularly when Daemon Manager is busy in running the tasks one by one in the queue. You must enter the command again to view the process details.
Viewing Brief Details of Processes
The pdshow -brief command displays the brief status of all processes or specified processes in tabular format in the CLI prompt.
•
–
–
where NMSROOT is the CiscoWorks installation directory.
•
–
–
where ProcessName1 and ProcessName2 are the name of the processes, and NMSROOT is the CiscoWorks installation directory.
The command displays the following details in tabular format:
•
•
•
For example, if you enter /opt/CSCOpx/bin/pdshow -brief Tomcat Apache in the command prompt, the following output is displayed:
Process State Pid******* ***** ***Tomcat Program Started - No mgt msgs received 13824Apache Running normally 13847Viewing Processes Statistics
The pdshow -stat command displays the statistics of all processes or specified processes in tabular format.
Note
To display the brief details of all processes, enter:
/opt/CSCOpx/bin/pdshow -stat (on Solaris)
To display the details of one or more specified processes, enter:
/opt/CSCOpx/bin/pdshow -stat ProcessName1 ProcessName2 (on Solaris)
where ProcessName1 and ProcessName2 are the name of the processes.
The command displays the following details in tabular format in the command line.
Starting a Process
You must enter the following commands to start a process through CLI:
•
•
The dependent processes are started first before the specified process is started.
If the process is being restarted after a shutdown, any dependent processes registered with the Daemon Manager is not automatically restarted. Dependent processes are automatically restarted only when the Daemon Manager itself is restarted.
Stopping a Process
You must enter the following commands to stop a process through CLI:
•
•
The dependent processes are also shut down using this CLI command.
Backing Up Data
You should back up the database regularly so that you have a safe copy of the database. You can schedule immediate, daily, weekly, or monthly automatic database backups. You should have necessary privileges to use this option.
You cannot back up the database while restoring the database. Common Services uses multiple databases to store client application data. These databases are backed up whenever you perform a backup.
Backup requires enough storage space on the target location for the backup to start.
Caution
To schedule a backup:
Step 1
The Backup page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
The Schedule Backup message verifies your schedule and provides the location of backup log files. Examine the log file at the following location to verify backup status:
On Solaris:
/var/adm/CSCOpx/log/dbbackup.log
On Windows:
NMSROOT\log\dbbackup.log
You can remove the scheduled backup at any time. Click Remove to delete the scheduled backup job. The Remove button appears only if you have scheduled any backup.
Backing up Using CLI
To back up data using CLI on Windows and Solaris:
On Windows, run:
NMSROOT/bin/perl NMSROOT/bin/backup.pl BackupDirectory [LogFile] [Num_Generations]
On Solaris, run:
/opt/CSCOpx/bin/perl /opt/CSCOpx/bin/backup.pl BackupDirectory [LogFile] [Num_Generations]
•
•
•
Data Backed up During CS 3.2 Backup
The following data is backed up:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Restoring Data
The new restore framework supports restore across versions. This enables you to restore data from versions 3.0.5, 3.0,6, 3.1, 3.1.1in addition to Common Services 3.2. The restore framework checks the version of the archive.
•
•
You can restore your database by running a script from the command line. You have to shut down and restart CiscoWorks while restoring data.
In all backup-restore scenarios, a back up is taken from a machine A, and the backed up data, say Ab, is restored on the same machine A, or on a different machine B.
Ensure that you do not run any critical tasks during data restoration. Otherwise, you may lose the data for such tasks.
For details on effect of restore operation on DCR modes, and Groups, see Effects of Backup-Restore on DCR and Effects of Backup-Restore on Groups.
Caution
The list of applications in a backup archive should match the list of applications installed a CiscoWorks server where you want to restore the data. You should not continue the restore when there is a mismatch, as it may cause problems in the functionality of CiscoWorks applications.
This section explains the following:
•
Restoring Data On Solaris
To restore the data on Solaris:
Step 1
Step 2
/etc/init.d/dmgtd stopStep 3
/opt/CSCOpx/bin/perl /opt/CSCOpx/bin/restorebackup.pl [-t temporary directory] [-gen generationNumber] [-d backup directory] [-h]
•
By default the temporary directory is created under NMSROOT as NMSROOT/ tempBackupData. You can customize this, by using this - t option, where you can specify your own temp directory. This is to avoid overloading NMSROOT
•
•
•
To restore the most recent version, enter:
/opt/CSCOpx/bin/perl /opt/CSCOpx/bin/restorebackup.pl -d backup directory
For example, -d /var/backup
Step 4
/var/adm/CSCOpx/log/restorebackup.log
Step 5
/etc/init.d/dmgtd startRestoring Data On Windows
To restore the data on Windows, make sure you have the correct permissions, and do the following:
Step 1
net stop crmdmgtd
Step 2
NMSROOT\bin\perl NMSROOT\bin\restorebackup.pl [-t temporary directory] [-gen generationNumber] [-d backup directory] [-h]where NMSROOT is the CiscoWorks installation directory. See the previous section for command option descriptions.
To restore the most recent version, enter the following command:
NMSROOT\bin\perl NMSROOT\bin\restorebackup.pl -d backup directoryStep 3
NMSROOT\log\restorebackup.log
Step 4
net start crmdmgtdWhile restoring using a backup taken from a machine that is in ACS mode, the machine on which data is restored needs to be added as a client in ACS. Contact ACS administrator to add the restored machine as ACS client. See also, Setting the Login Module to ACS.
Data Restored From Common Services 3.0.x/CS 3.1.x/CS 3.2 Backup Archive
The following data will be restored from a Common Services 3.0.x/3.1.x/3.2 backup archive:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Changing the Database Password
You must enter the database password while installing CiscoWorks. If you do not enter the password, CiscoWorks generates the password at random. However, we recommend that you change the password periodically to ensure system security.
Caution
Changing Password on Solaris
To change the password on Solaris:
Step 1
Step 2
/etc/init.d/dmgtd stopStep 3
cd NMSROOT/bin
To list the different formats available for changing the database password, enter:
NMSROOT/bin/perl dbpasswd.pl
Step 4
Step 5
/etc/init.d/dmgtd startChanging Password on Windows
To change the password on Windows:
Step 1
Step 2
net stop crmdmgtdStep 3
cd NMSROOT\bin
To list the different formats available for changing the database password, enter:
NMSROOT\bin\perl dbpasswd.pl
Step 4
Step 5
net start crmdmgtdFormats Available for Changing the Database Password
The different formats available and the commands for changing the database passwords on Windows and Solaris platform are tabulated below:
Effects of Backup-Restore on DCR
Data changes are a normal part of any restore from a backup. However, because Device and Credential Repository (DCR) is a distributed system with varying modes, it is also possible for any restored DCR to:
•
For example, a Standalone DCR can be set after a backup to act as a Slave. When the restore is performed, it will be reset to the Standalone mode. It depends on source machine's DCR mode where backup was taken, and on the target machine's DCR mode on which the data was restored.
•
For example, a DCR Slave may be using Master A at the time a backup is taken. Later, the domain may be changed to use Master B, and the Slave reset to use Master B. When the restore is performed, the Slave will attempt to use Master A.
For detailed information on DCR, see Managing Device and Credentials.
The following scenarios helps you understand the implications of Restore operations on DCR.
•
Restoring Data From a DCR Standalone
If you restore the data backed up from a machine in the Standalone mode, on any machine whose working mode is either Standalone, Master, or Slave, the end mode will be Standalone.
Let X be a machine in Standalone mode.
If you restore the data backed up from X, say Xb, on another Standalone machine Y, or a Slave S, or a Master M, the end mode of Y, S, and M will be Standalone. Also, any slave of M will switch to Standalone mode.
Further scenarios can be better explained based on the following DCR set up.
Let us assume there are two DCR domains.
•
•
Restoring Data From S1 on S1
Suppose you take a backup from S1. After sometime, you restore the backed up data, say S1b, on S1. S1 will look for its Master M1, and the Master-Slave relation between S1 and M1 will be intact, since M1 is available.
However, note that the restore on S1 will practically be of no effect since S1 and M1 will synchronize after the restore on S1. The changes that have taken place after the backup was taken from S1 will be reflected in S1, even if S1b is restored on S1.
In the above example, if the restore on S1 is performed when Master M1 is down, or has crashed, the end mode of S1 will be Standalone. This is because S1 will try to contact M1, and will fail because M1 is down.
Restoring Data From S1 to M1
Suppose you take a backup from S1 and restore the backed up data, say S1b, on M1. M1 will switch to Standalone mode because, after backup, it will not be able to find a Master. S1 will also switch to Standalone mode.
At the time of backup, if there were 1000 devices in M1, the Slave S1 would also have 1000 devices. Assume more devices are added to M1 after the Backup. S1 will have the up-to-date device list. However, after restore on M1, M1 will have only 1000 devices. In other words, the data on S1 will be more recent than the data on M1.
Restoring Data From S1 on M2
Suppose you take a backup from S1 and restore the backed up data, say S1b, on M2, which is the Master in the DCR Domain 2 in our example.
After the restore, the end mode of M2 will be Slave. That is, M2 will become a Slave of M1. Also, S3, and S4, which were Slaves of M2, will switch to the Standalone mode.
Restoring Data From M1 on M1
Suppose you take a back up from M1. After the backup you would be performing several operations that would bring about changes in the Master and the corresponding Slaves; M1, S1, and S2 in our example.
Now, if you restore the backed up data M1b, on M1 itself. The Master M1 will have data that is older than the data in the Slaves, S1, and S2. In other words, the Slaves will have more recent data than that on the Master.
To avoid this, you must perform the Restore operation in the following sequence:
Step 1
Step 2
This is to ensure that the data backed up from M1 is more recent than the data backed up from S1 and S2.
Step 3
Step 4
Step 5
Step 6
Step 7
This ensures that Master has more recent data than the Slaves.
Note
Restoring Data From M1 to M2
Suppose you take a backup from M1, and restore the backed up data, say M1b, on M2.
S3, and S4 which were Slaves of M2, will switch to Standalone mode.
Master-Slave Configuration Prerequisites and Restore Operations
DCR Master-Slave setup requires you to perform certain tasks prior to Master-Slave configuration, to enable proper, and secure communication between them. This involves copying certificates, and setting up a valid system identity user. For details, see Master-Slave Configuration Prerequisites.
Restore operations can affect Master-Slave relationships because it may modify these pre-configured parameters.
For example, let M1 be the Master, and S1 its Slave. Let X be a standalone server.
Suppose you take a backup from S1, and restore the backed up data, say S1b on X.
Now, X has to be in Slave mode.
Since, M1 and S1 already shared a Master-Slave relationship, M1 will have the peer certificate of S1, and S1 will have the certificate of M1.
After the restore operation, X will get the certificate of M1. However, if peer certificate of X is not present on M1, X will not be able to have M1 as its Master.
So you have to ensure that the certificates of the peer machines are in place, before you do a Restore.
Other Master-Slave configuration prerequisites such as System Identity user configuration and Peer Server Account user configuration might get affected by Restore operations.
For example: In M1 you have Joe as a Peer Server User and in S1 you add Joe as a System Identity user. You take a backup from S1.
After you take the backup, say you change the Peer Server User and System Identity User to Bob.
Now if you restore the backed up data, say S1b the system Identity User would not be the Bob anymore. This will upset the Master-Slave relationship.
During restore you are prompted to confirm whether you need to overwrite the SSL certificate.
SSL certificates are tied to individual machines. So if you take a backup on one machine and restore it on another, you should be careful not to overwrite the SSL certificate.
However, if you backup data from a machine and restore it to the same machine, you may overwrite the SSL certificate.
Effects of Backup-Restore on Groups
Backup-Restore operations have an implication on the way Groups will be displayed in the Common Services (CS) UI. The changes in Groups behavior is discussed in relation with the Device and Credential Repository (DCR) mode changes explained in the above section.
If you perform a backup on machine A and restore the backed up data, say Ab, on the same machine, the system-defined groups, and the user-defined groups created after the data backup will be removed.
Restoring Data From a DCR Standalone
The following scenarios have to be considered:
•
The provider group name will change accordingly. That is, the provider group CS @A will become CS@B.
•
The Master will switch to Standalone mode. The provider group name will be updated accordingly. The Slave groups will be removed from the Master.
Only the groups pertaining to Common Services and the applications installed in the Standalone machine will be visible. All dependent Slaves of M will become Standalone.
•
The Slave will switch to Standalone mode. The provider group name is updated accordingly. The groups pertaining to other Slaves in the domain, and the Master of S, will be removed from S. The groups UI will be enabled.
The subsequent sections are based on the scenarios discussed in the Effects of Backup-Restore on DCR.
Restoring Data From S1 on S1
No impact on CS groups.
There may be applications installed on S1. Say you create 10 groups in the Applications before you backup data from S1. After backup, assume you create 10 more groups in the Applications. After restore, the 10 groups you created after backup will not be present. This also propagates to other Slaves in the domain.
Restoring Data From S1 on M1
After restore, both S1 and M1 will switch to Standalone mode. Both will have only those groups pertaining to Common Services and Applications installed on the individual machines. Groups UI is enabled on S1. Also, the other Slaves of M1 will switch to Standalone mode.
Restoring Data From S1 on M2
After restore, M2 will become a Slave of M1. The Groups UI in M2 will be disabled. M2 will pickup all the groups from M1. Groups in M2 will be propagated to other slaves in the domain. All the slaves of M2 (before restore) will now switch to Standalone mode.
Restoring Data From M1 on M2
Slaves of M2, that is S3 and S4, will switch to Standalone mode. Groups pertaining to S3 and S4 will be deleted from M2.
In all the cases the System Defined Groups, and the User Defined Groups, are carried over and updated in the target machine.
Licensing CiscoWorks Applications
You must register your software and obtain a product license before you start using an application. You can obtain a product license and license your application, view details of your current software license, or update to a new license from the Licensing page.
Common Services will not perform the license check. The applications should authenticate and perform the license check.
Obtaining a License for CiscoWorks Applications
To obtain a product license for your CiscoWorks applications, register your software at one of the following websites. You will need to provide the Product Authorization Key (PAK), which is printed on a label affixed to the Bundle sub-box.
If you are a registered user of Cisco.com, use this website:
http://www.cisco.com/go/license
If you are not a registered user of Cisco.com, use this website:
http://www.cisco.com/go/license/public
The product license will be sent to the e-mail address you provide during registration.
Retain this license with your CiscoWorks software records.
Licensing the Application
After you obtain the product license, perform these steps to license your software:
Step 1
Step 2
The License Information dialog box appears. The License Information page displays the name, version, device limit, status and expiration date of the license.
Step 3
Step 4
Step 5
The system verifies whether the license file is valid, and updates the license. The updated licensing information appears in the License Information page. Otherwise an error message is displayed.
Viewing License Information
To view details of your current software license, select Common Services > Server > Admin > Licensing to open the License Information page.
If LMS Portal is installed on CiscoWorks Server, you can open this page from the LMS Portal home page.
The license name, license version, size (device limit for the licensed application), status of the license, and the expiration date of the license appear under License Information.
The license version shows the major version of the applications. To know the version with patch level, select Common Services > Software Center > Software Updates.
Updating Licenses
You can view details of your current software license, or update to a new license from the License page.
To update to a new license from the Licensing page:
Step 1
The License Information page displays the license name, license version, status of the license, and the expiration date of the license.
Step 2
Step 3
Step 4
The system verifies whether the license file is valid, and updates the license. The updated licensing information appears in the License Information page. Otherwise, an error message is displayed.
Collecting Server Information
This feature helps you to get the required information about the server. The information about the server include system information, environment, configuration, logs, web server information, device and credentials administration information, and grouping services information.
You can use the collected server information for troubleshooting.
For example, when you have chosen to collect the grouping services information about the server, the following details will be collected and stored:
•
•
•
•
Server. The status of the grouping server may be running or not running.•
•
•
You can look into this collected information to find out the errors with grouping servers and debug them further.
To collect the server information:
Step 1
The Collect Server Information page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Collect Server Information popup dialog box appears a list of options. The available options are:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Step 3
You can use the All checkbox to select or deselect all the available options.
By default all the check boxes are selected.
Step 4
The server information for the selected components is collected.
To view the collected information:
Step 1
The Collect Server Information page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The popup window displays the server information collected.
Step 3
To delete the collected server information:
Step 1
The Collect Server Information page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
Collecting Server Information Using CLI
You can also generate the collect server information using CLI.
Enter the following command:
•
or
•
where NMSROOT is the directory where you installed CiscoWorks.
Collecting Self Test Information
You can view self test reports using this option. Self test feature helps to test certain basic functions of the server.
Step 1
Step 2
Step 3
A popup window displays the selftest information report.
To delete a Self Test Information report, select the check box and click Delete.
Messaging Online Users
You can use the Notify User feature in Common Services to broadcast messages to online users.
You can post messages to users with active CiscoWorks browsers. By default, the messages will be received within 60 seconds. You can also change this polling interval. See Setting Up CiscoWorks Home Page for information to change the polling interval.
To send a broadcast message:
Step 1
The Logged in Users dialog box lists all the users currently logged in.
Step 2
The Status field displays the status of the message.
Note
Managing Jobs
Common Services provides a Job Browser to manage jobs. From the Job browser you can view a listing of jobs, view details of each job, stop a job, and delete a job from the list.
Users in Help Desk, Approver, and Network Operator roles are not allowed to stop and delete jobs. All users (including Help Desk) can access the Job Browser page. The Refresh icon in Job browser is available for all users.
Note
To view the list of jobs:
Step 1
The Job Browser page appears with the following details:
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
To view Job details:
Step 1
The Job Browser page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Job Details popup displays the job details.
To stop a Job:
Step 1
The Job Browser page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
When you stop a Normal job, you are prompted to confirm whether you want to stop the job.
However, when you stop jobs that have several instances, you are prompted to specify whether you need to stop the current instance of the job alone, or the current instance and all the future instances as well.
You can stop only one job at a time.
To delete a job, click Delete, after selecting the desired check box.
You can delete multiple jobs at a time. You cannot delete a running job. All users (except Help Desk) can perform Stop and Delete operations in the job browser.
Managing Resources
Common Services provides a Resource Browser for managing resources. You can free locked resources, when necessary, if you have appropriate privileges. All users (including those with Help Desk role alone) can access the Resource browser page. The Refresh icon in the Resource browser is available for all users.
Note
To view Resource details:
Step 1
The Resource Browser page displays the following details:
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
To free locked resources:
Step 1
The Resource Browser page appears.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
All users (except those with only Help Desk role) can perform the Free Resource operation in the Resource browser.
To view updated resources, click Refresh.
Maintaining Log Files
Log files can grow and fill up disk space. CiscoWorks includes a script that enables you to control this growth.
Files maintained by this script include the following log files:
•
•
Most log files are located in directories in the following locations:
•
