Table Of Contents
Configuring the Server
Setting up Security
Managing Security in Single-Server Mode
Setting up Browser-Server Security
Setting up Local User Policy
Setting up Local Users
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
Enabling Single Sign-On
Setting up the AAA Mode
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
Setting up ACS Server
Changing the Login Module to ACS
Roles in ACS
Assigning Roles to Users and User Groups in ACS
Managing Cisco.com Connection
Setting up Cisco.com User Account
Setting Up the Proxy Server
Generating Reports
Log File Status Report
Permissions Report
Users Logged In Report
Process Status Report
Viewing Audit Log Report
Administering Common Services
Using Daemon Manager
Managing Processes
CiscoWorks Server Back-end Processes
Managing Processes Through CLI
Backing Up Data
Restoring Data
Changing the Database Password
Effects of Backup-Restore on DCR
Master-Slave Configuration Prerequisites and Restore Operations
Licensing CiscoWorks Applications
Collecting Server Information
Collecting Self Test Information
Messaging Online Users
Managing Jobs
Managing Resources
Maintaining Log Files
Configuring Log Files Rotation
Modifying System Preferences
Configuring Logging
Configuring Disk Space Threshold Limit
Effects of Third Party Backup Utility and Virus Scanner
Configuring TFTP
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:
•
Setting up Security
•
Generating Reports
•
Administering Common Services
•
Configuring CiscoWorks Home Page
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
•
Managing Security in Multi-Server Mode
•
Setting up the AAA Mode
•
Integrating CiscoWorks Server With ACS Server
•
Managing Cisco.com Connection
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
•
Setting up Local User Policy
•
Setting up Local Users
•
Creating Self Signed Certificates
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
•
Enabling Browser-Server Security From the Command Line Interface (CLI) On Windows Platforms
•
Enabling Browser-Server Security From the Command Line Interface (CLI) On Solaris Platforms
•
Disabling Browser-Server Security From the CiscoWorks Server
•
Disabling Browser-Server Security From the Command Line Interface (CLI) On Windows Platforms
•
Disabling Browser-Server Security From the Command Line Interface (CLI) On Solaris Platforms
Enabling Browser-Server Security From the CiscoWorks Server
To enable Browser-Server Security:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > Single-Server Management > Browser-Server Security Mode Setup.
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
Select the Enable option to enable SSL.
Step 3
Click Apply.
Step 4
Log out from your CiscoWorks session, and close all browser sessions.
Step 5
Restart the Daemon Manager from the CiscoWorks Server CLI:
On Windows:
a.
Enter net stop crmdmgtd
b.
Enter net start crmdmgtd
On Solaris:
a.
Enter /etc/init.d/dmgtd stop
b.
Enter /etc/init.d/dmgtd start
Step 6
Restart the browser, and the CiscoWorks session.
When you restart the CiscoWorks session after enabling SSL, you must enter the URL with the following changes:
•
The URL should begin with https instead of http to indicate secure connection. CiscoWorks will automatically redirect you to HTTPS mode if SSL is enabled.
•
Change the port number suffix from 1741 to 443.
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
Go to the command prompt.
Step 2
Navigate to the directory NMSROOT\MDC\Apache.
Step 3
Enter NMSROOT\bin\perl ConfigSSL.pl -enable
Step 4
Press Enter.
•
If you have the required security certificates available on the server, CiscoWorks enables SSL.
•
If you do not have the security certificates on the server, CiscoWorks prompts you to create your own self-signed certificate and enter the details required to create a self-signed certificate.
Step 5
Create a self-signed certificate or use certificates you obtained from a Certification Authority (CA).
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
Log out from your CiscoWorks session, and close all browser sessions.
Step 7
Restart the Daemon Manager from the CiscoWorks Server CLI:
a.
Enter net stop crmdmgtd
b.
Enter net start crmdmgtd
Step 8
Restart the browser, and the CiscoWorks session.
When you restart the CiscoWorks session after enabling SSL, you must enter the URL with the following changes:
•
The URL should begin with https instead of http to indicate secure connection. CiscoWorks will automatically redirect you to HTTPS mode if SSL is enabled.
•
Change the port number suffix from 1741 to 443.
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
Go to the command prompt.
Step 2
Navigate to the directory NMSROOT\MDC\Apache\bin.
Step 3
Enter ./ConfigSSL.pl -enable
Step 4
Press Enter.
•
If you have the required security certificates available on the server, CiscoWorks enables SSL.
•
If you do not have the security certificates on the server, CiscoWorks prompts you to create your own self-signed certificate and enter the details required to create a self-signed certificate.
Step 5
Create a self-signed certificate or use certificates you obtained from a Certification Authority (CA).
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
Log out from your CiscoWorks session, and close all browser sessions.
Step 7
Restart the Daemon Manager from the CiscoWorks Server CLI:
a.
Enter /etc/init.d/dmgtd stop
b.
Enter /etc/init.d/dmgtd start
Step 8
Restart the browser, and the CiscoWorks session.
When you restart the CiscoWorks session after enabling SSL, you must enter the URL with the following changes:
•
The URL should begin with https instead of http to indicate secure connection. CiscoWorks will automatically redirect you to HTTPS mode if SSL is enabled.
•
Change the port number suffix from 1741 to 443.
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
Go to the CiscoWorks home page and select Common Services > Server > Security > Single-Server Management > Browser-Server Security Mode Setup.
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
Select the Disable option to disable SSL.
Step 3
Click Apply.
Step 4
Log out from your CiscoWorks session, and close all browser sessions.
Step 5
Restart the Daemon Manager from the CiscoWorks Server CLI:
On Windows:
a.
Enter net stop crmdmgtd
b.
Enter net start crmdmgtd
On Solaris:
a.
Enter /etc/init.d/dmgtd stop
b.
Enter /etc/init.d/dmgtd start
Step 6
Restart the browser, and the CiscoWorks session.
When you restart the CiscoWorks session after disabling SSL, you must enter the URL with the following changes:
•
The URL should begin with http instead of https to indicate that connection is not secure.
•
Change the port number suffix from 443 to 1741.
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
Go to the command prompt.
Step 2
Navigate to the directory NMSROOT\MDC\Apache.
Step 3
Enter NMSROOT\bin\perl ConfigSSL.pl -disable
Step 4
Press Enter.
Step 5
Log out from your CiscoWorks session, and close all browser sessions.
Step 6
Restart the Daemon Manager from the CiscoWorks Server CLI:
a.
Enter net stop crmdmgtd
b.
Enter net start crmdmgtd
Step 7
Restart the browser, and the CiscoWorks session.
When you restart the CiscoWorks session after disabling SSL, you must enter the URL with the following changes:
•
The URL should begin with http instead of https to indicate that connection is not secure.
•
Change the port number suffix from 443 to 1741.
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
Go to the command prompt.
Step 2
Navigate to the directory NMSROOT\MDC\Apache\bin.
Step 3
Enter ./ConfigSSL.pl -disable
Step 4
Press Enter.
Step 5
Log out from your CiscoWorks session, and close all browser sessions.
Step 6
Restart the Daemon Manager from the CiscoWorks Server CLI:
a.
Enter /etc/init.d/dmgtd stop
b.
Enter /etc/init.d/dmgtd start
Step 7
Restart the browser, and the CiscoWorks session.
When you restart the CiscoWorks session after disabling SSL, you must enter the URL with the following changes:
•
The URL should begin with http instead of https to indicate that connection is not secure.
•
Change the port number suffix from 443 to 1741.
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:
•
Start the local username with a number
•
Include special characters in local username
•
Specify the length of local username
•
Specify the length of local user password
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
Go to the CiscoWorks home page and select Common Services > Server > Security > Single-Server Management > Local User Policy Setup.
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
Select Allow Special Characters in username to allow special characters in the username.
You can include the following special characters in the username:
Special Character
|
Description
|
~
|
Tilde
|
@
|
Commercial At character
|
#
|
Number sign
|
_
|
Underscore
|
'
|
Apostrophe
|
-
|
Hyphen
|
/
|
Solidus or Leading slash
|
\
|
Trailing slash
|
.
|
Period
|
space
|
Non-breaking space
|
Note
You can add the special characters including hyphen and period in local username only when you have selected this checkbox. You cannot start a local username with special characters except _ (Underscore).
Step 3
Select Allow Username to start with numbers to allow the first character of a local username to be a numeral.
You can enter any number between 0 to 9 in the username as the first character if you have enabled this option.
Step 4
Enter the minimum and maximum length of username of local users.
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
Enter the minimum and maximum length of password of local users.
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
Click Apply to save the changes.
Setting up Local Users
Local User Setup feature helps you in:
•
Modifying Your Profile
•
Adding a Local User
•
Editing User Profiles
•
Deleting Local Users
You can also set up local users and reset CiscoWorks password through CLI. See the following sections for more information:
•
Setting Up Local Users Through CLI
•
Changing CiscoWorks User Password Through CLI
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:
•
guest—Specify a password during installation. User role is Help Desk.
•
admin—Specify the password during installation. The user role is a combination of System Administrator, Network Administrator, Network Operator, Approver, and Help Desk.
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
The CiscoWorks Server Administrator can set the passwords for admin and guest users during installation. Contact the CiscoWorks Server Administrator if you do not know the password for admin.
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.
Level
|
Description
|
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
Go to the CiscoWorks home page and select Common Services > Server > Security > Single-Server Management > Local User Setup.
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
Click Modify My Profile to modify the logged in user credentials.
Step 3
Enter the password in the Password field.
Step 4
Re-enter the password in the Verify field.
Step 5
Enter an e-mail address in the E-mail field.
This is mandatory if you assign the approver role to the local user. Otherwise, this is optional.
Step 6
Click OK.
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
Go to the CiscoWorks home page and select Common Services > Server > Security > Single-Server Management > Local User Setup.
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
Click Add.
The User Information dialog box appears.
Step 3
Enter the username in the Username field.
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
You can add the special characters including hyphen and period in local username only when you have selected the Allow Special Characters in username checkbox in the Local User Policy Setup page.
Step 4
Enter the password in the Password field.
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
Re-enter the password in the Verify field.
Step 6
Enter the e-mail ID in the E-mail field.
This is mandatory if you assign the approver role to the local user. Otherwise, this is optional.
Step 7
Select the check box corresponding to the role to specify the roles to be assigned to the user from the Roles pane.
The following roles are available:
•
Help Desk (available by default)
•
Approver
•
Network Operator
•
Network Administrator
•
System Administrator
•
Export Data
See About CiscoWorks Common Services Pluggable Authentication for more details on each role.
Step 8
Click OK.
Editing User Profiles
You can edit the user profiles to modify the roles assigned to the users.
To edit user profiles:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > Single-Server Management > Local User Setup.
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
Click Edit.
The User Information dialog box appears.
Note
You cannot edit the local username.
Step 3
Enter the password in the Password field.
Step 4
Re-enter the password in the Verify field.
Step 5
Enter the e-mail ID in the E-mail field.
This is mandatory if you assign the approver role to the local user. Otherwise, this is optional.
Step 6
Select or deselect the check boxes corresponding to roles from the Roles pane.
Step 7
Click OK.
Deleting Local Users
To delete local users:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > Single-Server Management > Local User Setup.
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
Select the check boxes corresponding to the users listed.
Step 3
Click Delete.
A confirmation dialog box appears.
Step 4
Click OK to confirm.
Setting Up Local Users Through CLI
You can set up the local users through CLI. This feature helps you in:
•
Adding Local Users
•
Importing Local Users
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,
•
Username — Local username. The local username is case-insensitive.
•
Password — Password for the local user account name.
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.
•
E-mail — E-mail address of the local user.
This is mandatory if you assign the approver role to the local user. Otherwise, this is optional.
•
Roles — Roles to be assigned to the local user. You should assign one or more of the following roles to the user separated by comma.
–
hd (Help Desk)
–
ap (Approver)
–
sa (System Administrator)
–
na (Network Administrator)
–
no (Network Operator)
–
EX (Export Data)
The following is an example of local user information to be represented in input text file:
admin123:admin123:admin123@cisco.com:sa,na,ap,hd
aekaek:aekpasswd:aek@cisco.com:sa,na,ap,hd
testuser::testuser@cisco.com:sa,na,ap,hd
To add local users through CLI, enter the following commands:
•
NMSROOT/bin/perl NMSROOT/bin/AddUserCli.pl -add Filename Password (on Solaris)
•
NMSROOT\bin\perl NMSROOT\bin\AddUserCli.pl -add Filename Password (on Windows)
where,
•
Filename — Absolute path of the filename containing local users information.
•
Password — Common password for all user accounts specified in the input text file.
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:
•
NMSROOT/bin/perl NMSROOT/bin/AddUserCli.pl -import Protocol Hostname Portnumber Username Password (on Solaris)
•
NMSROOT\bin\perl NMSROOT\bin\AddUserCli.pl -import Protocol Hostname Portnumber Username Password (on Windows)
where,
•
Protocol — Protocol of the remote CiscoWorks Server.
The supported values are HTTP or HTTPS.
•
Hostname — Hostname or IP Address of the remote CiscoWorks Server.
•
Portnumber — Port Number of the remote CiscoWorks Server.
•
Username — Remote CiscoWorks Server Login Username.
•
Password — Remote CiscoWorks Server Login Password.
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:
•
/var/adm/CSCOpx/log/AddUser.log (on Solaris)
•
NMSROOT\log\AddUser.log (on Windows)
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
Enter /etc/init.d/dmgtd stop to stop the Daemon Manager.
Step 2
Enter NMSROOT/bin/resetpasswd username at the command prompt.
A message appears:
Enter new password for username:
Step 3
Enter the new password.
Step 4
Enter /etc/init.d/dmgtd start to start the Daemon Manager.
To change the user password on Windows:
Step 1
Enter net stop crmdmgtd to stop the Daemon Manager.
Step 2
Enter NMSROOT\bin\resetpasswd username at the command prompt.
A message appears:
Enter new password for username:
Step 3
Enter the new password.
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
If you re-generate the certificate, when you are in multi-server mode, any existing peer relation might break. The peers need to re-import the certificate in this scenario.
This section explains the following:
•
Creating a Self Signed Certificate From the User Interface
•
Working With Third Party Security Certificates
•
Uploading Third Party Security Certificates to CiscoWorks Server
•
Using the SSL Utility Script to Upload Third Party Security Certificates
Creating a Self Signed Certificate From the User Interface
To create a certificate from the user interface:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > Single-Server Management > Certificate Setup.
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
Enter the values required for the fields described in the following table:
Field
|
Usage Notes
|
Country Name
|
Two character country code.
|
State or Province
|
Two character state or province code or the complete name of the state or province.
|
Locality
|
Two character city or town code or the complete name of the city or town.
|
Organization Name
|
Complete name of your organization or an abbreviation.
|
Organization Unit Name
|
Complete name of your department or an abbreviation.
|
Host Name
|
DNS name of the computer or the IP address of the computer.
Enter the Host Name with a proper and resolvable domain name. This is displayed on your certificate (whether self-signed or third party issued). Local host or 127.0.0.1 should not be given.
|
Email Address
|
E-mail address to which the mail has to be sent.
|
Step 3
Click Apply to create the certificate.
The process generates the following files:
•
server.key—Server's private key.
•
server.crt—Server's self- signed certificate.
•
server.pk8—Server's private key in PKCS#8 format.
•
server.csr—Certificate Signing Request (CSR) file.
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:
•
NMSROOT\MDC\Apache (On Windows)
•
NMSROOT/MDC/Apache/bin (On Solaris)
This utility has the following options:
Number
|
Option
|
What it Does...
|
1
|
Display CiscoWorks Server certificate information
|
• Displays the Certificate details of the CiscoWorks Server.
For third party issued certificates, this option displays the details of the server certificate, the intermediate certificates, if any, and the Root CA certificate.
• Verifies if the certificate is valid.
|
2
|
Display the input certificate information
|
This option accepts a certificate as an input and:
• Verifies if the certificate is in Base64 Encoded X.509 certificate format.
• Displays subject and issuer details of the certificate.
• Verifies if the certificate is valid on the server.
|
3
|
Display Root CA certificates trusted by CiscoWorks Server
|
Generates a list of all Root CA Certificates.
|
4
|
Verify the input certificate or certificate chain
|
Verifies whether the server certificate issued by third party CAs, can be uploaded.
When you choose this option, the utility:
• Verifies if the certificate is in Base64 Encoded X.509Certificate format.
• Verifies if the certificate is valid on the server
• Verifies if the server private key and input server certificate match.
• Verifies if the server certificate can be traced to the required Root CA certificate using which it was signed.
• Constructs the certificate chain, if the intermediate chains are also given, and verifies if the chain ends with the proper Root CA certificate.
After the verification is successfully completed, you are prompted to upload the certificates to CiscoWorks Server.
The utility displays an error:
• If the input certificates are not in required format
• If the certificate date is not valid or if the certificate has already expired.
• If the server certificate could not be verified or traced to a root CA certificate.
• If any of the intermediate Certificates were not given as input.
• If the server's private key is missing or if the server certificate that is being uploaded could not be verified with the server's private key.
You must contact the CA who issued the certificates to correct these problems before you upload the certificates to CiscoWorks.
|
5
|
Upload single server certificate to CiscoWorks Server
|
You must verify the certificates using option 4 before you select this option.
Select this option, only if there are no intermediate certificates and there is only the server certificate signed by a prominent Root CA certificate.
If the Root CA is not one trusted by CiscoWorks, do not select this option.
In such cases, you must obtain a Root CA certificate used for signing the certificate from the CA and upload both the certificates using option 6.
When you select this option, and provide the location of the certificate, the utility:
• Verifies if the certificate is in Base64 Encoded X.509 certificate format.
• Displays subject and issuer details of the certificate.
• Verifies if the certificate is valid on the server.
• Verifies if the server private key and input server certificate match.
• Verifies if the server certificate can be traced to the required Root CA certificate using which it was signed.
After the verification is successfully completed, the utility uploads the certificate to CiscoWorks Server.
The utility displays an error:
• If the input certificates are not in required format
• If the certificate date is not valid or if the certificate has already expired.
• If the server certificate could not be verified or traced to a root CA certificate.
• If the server's private key is missing or if the server certificate that is being uploaded could not be verified with the server's private key.
You must contact the CA who issued the certificates to correct these problems before you upload the certificates in CiscoWorks again.
|
6
|
Upload a certificate chain to CiscoWorks Server
|
You must verify the certificates using option 4 before you select this option.
Select this option, if you are uploading a certificate chain. If you are also uploading the root CA certificate also, you must include it as one of the certificates in the chain.
When you select this option and provide the location of the certificates, the utility:
• Verifies if the certificate is in Base64 Encoded X.509 Certificate format.
• Displays subject and issuer details of the certificate.Verifies if the certificate is valid on the server
• Verifies if server private key and the server certificate match.
• Verifies if the server certificate can be traced to the root CA certificate using which it was signed.
• Constructs the certificate chain, if intermediate chains are given and verifies if the chain ends with the proper root CA certificate.
After the verification is successfully completed, the server certificate is uploaded to CiscoWorks Server.
All the intermediate certificates and the Root CA certificate are uploaded and copied to the CiscoWorks TrustStore.
The utility displays an error:
• If the input certificates are not in required format.
• If the certificate date is not valid or if the certificate has already expired.
• If the server certificate could not be verified or traced to a root CA certificate.
• If any of the intermediate certificates were not given as input.
• If the server's private key is missing or if the server certificate that is being uploaded could not be verified with the server's private key.
You must contact the CA who issued the certificates to correct these problems before you upload the certificates in CiscoWorks again.
|
7
|
Modify Common Services Certificate
|
This option allows you to modify the Host Name entry in the Common Services Certificate.
You can enter an alternate Hostname if you wish to change the existing Host Name entry.
|
Using the SSL Utility Script to Upload Third Party Security Certificates
To upload the certificates:
Step 1
Stop the Daemon Manager from the CiscoWorks CLI:
On Windows:
•
Enter net stop crmdmgtd
On Solaris:
•
Enter /etc/init.d/dmgtd stop
Step 2
Navigate to the directory where the SSL Utility script is located.
On Windows:
a.
Go to NMSROOT\MDC\Apache
b.
Enter NMSROOT\bin\perl SSLUtil.pl
On Solaris:
a.
Go to NMSROOT/MDC/Apache/bin
b.
Enter NMSROOT/bin/perl SSLUtil.pl
Step 3
Select option 4, Verify the input Certificate/Certificate Chain.
Step 4
Enter the location of the certificates (server certificate and intermediate certificate).
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
Select option 5, if you have only one certificate to upload, that is if you have a server certificate signed by a Root CA certificate.
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
Enter the following required details:
•
Location of the certificate
•
Location of intermediate certificates, if any.
SSL Utility uploads the certificates, if all the details are correct and the certificates meet CiscoWorks requirements for security certificates.
Step 7
Restart the Daemon Manager for the new security certificate take effect.
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
•
Setting up System Identity Account
•
Setting up Peer Server Certificate
•
Enabling Single Sign-On
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
Go to the CiscoWorks home page and select Common Services > Server > Security > Multi-Server Management > Peer Server Account Setup.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Click Add.
The Peer Server Account Setup page appears.
Step 3
Enter the username in the Username field.
Step 4
Enter the password in the Password field.
Step 5
Re-enter the password in the Verify field.
Step 6
Click OK.
To edit Peer Server user information:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > Multi-Server Management > Peer Server Account Setup.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Click Edit.
The Peer Server Account Setup page appears.
Step 3
Enter the password in the Password field.
Step 4
Re-enter the password in the Verify field.
Step 5
Click OK.
To delete a Peer Server user:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > Multi-Server Management > Peer Server Account Setup.
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
Select the check box corresponding to the user you want to delete.
Step 3
Click Delete.
The confirmation dialog box appears.
Step 4
Click OK to confirm.
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:
•
The user is a Local User with all privileges in non-ACS mode. If the user is not present, or if the user does not have all privileges, an error message appears.
•
The user has all privileges in ACS server for all applications installed on CiscoWorks server in ACS mode. If the user is not present, or if the user does not have all privileges, an error message appears.
•
The System Identity User is also a Peer Server User. If not, the user will be made a Peer Server User.
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
Go to the CiscoWorks home page and select Common Services > Server > Security > Multi-Server Management > System Identity Setup
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Enter the username in the Username field.
Step 3
Enter the password in the Password field.
Step 4
Re-enter the password in the Verify field.
Step 5
Click Apply.
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
Go to the CiscoWorks home page and select Common Services > Server > Security > Multi-Server Management > Peer Server Certificate Setup.
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
Click Add.
Step 3
Enter the IP address/hostname of peer CiscoWorks Server in the corresponding fields.
If you specify a server name, it must be entered in DNS. Otherwise specify IP Address.
Step 4
Enter the value of the SSL (HTTPS) Port of the peer CiscoWorks Server. The default SSL(HTTPS) Port of the peer CiscoWorks Server is 443.
Step 5
Click OK.
To delete peer certificates:
Step 1
Select the check box corresponding to the certificate you want to delete.
Step 2
Click Delete.
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:
•
One of the CiscoWorks Servers should be set up as the authentication server.
•
Trust should be built between the CiscoWorks Servers, using self signed certificates. A trusted certificate is created by adding it in the trust key store of the server. CiscoWorks TrustStore or KeyStore is maintained by the certificate management framework in Common Services.
•
Each CiscoWorks Server should setup a shared secret with the authentication server. The System Identity user password acts as a secret key for SSO.
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:
•
Configure the System Identity User and password in both Master and Slave. The System Identity User name and password you specify in Master and Slave should be the same.
•
Configure Master's Self Signed Certificate in 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:
•
Add the user across all servers within the SSO domain.
•
Assign appropriate roles to the user, in each of the CiscoWorks Servers.
•
Ensure that all the servers within the SSO domain are in ACS mode, if ACS is used as the AAA mode.
To set up System Identity User:
Step 1
Select Common Services > Server > Security > Multi-Server Management > System Identity Setup.
Step 2
Enter the username and password.
Step 3
Click Apply.
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
•
Launching a New Browser Instance
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.do
If ABC is running in HTTPS mode, you have to specify the URL as:
https://ABC:443/cwhp/cwhp.applications.do
In 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
We recommend that you do not use IP address of the servers that are part of SSO or localhost, while specifying the URL.
For example, suppose ABC and XYZ are part of an SSO domain.
Step 1
Login to ABC.
Step 2
Launch a new browser instance (File > New > Window, in Internet Explorer) from the same browser window.
Step 3
Enter the URL, with the context (http://XYZ:1741/cwhp/cwhp.applications.do) of XYZ in the new browser instance.
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:
•
Master mode—The SSO Authentication Server does the authentication and sends the result to the Regular Server.
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.
•
Slave mode—SSO Regular server for which authentication is done at the Master.
While logging into regular server, if the authentication server is not reachable, the following message appears:
Only 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:
•
Master server name
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.
•
Login Port of the Master (443)
To change the SSO mode to Standalone:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > Single Sign-On.
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
Select Standalone (Normal) radio button.
Step 3
Click Apply.
To change the SSO mode to Master:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > Single Sign-On.
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
Select the Master (SSO Authentication Server) radio button.
Step 3
Click Apply.
To change the SSO mode to Slave:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > Single Sign-On.
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
Select the Slave (SSO Regular Server) radio button.
Step 3
Enter the Master server name and port number.
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
Click Apply.
It checks whether:
•
The System Identity user password of the Slave matches that of the Master.
•
The Self Signed Certificate of the Master is added as the peer certificate in the Slave. The Common Name (CN) in the certificate should match with the Master server name.
•
The Master is up and running on the specified port.
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
•
Cisco Secure ACS Support for Common Services Client Applications
•
Setting the Login Module to Non-ACS
•
Setting the Login Module to ACS
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
•
Understanding Fallback Options for Non-ACS mode
•
Debugging
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:
•
Help Desk — Can access network status information only. Can access persisted data on the system and cannot perform any action on a device or schedule a job which will reach the network.
•
Approver — Can approve all tasks.
•
Network Operator — Can perform all Help Desk tasks. Can perform tasks related to network data collection. Cannot perform any task that requires write access on the network.
•
Network Administrator — Can perform all Network Operators tasks. Can perform tasks that result in a network configuration change.
•
System Administrator — Can perform all CiscoWorks system administration tasks.
•
Super Admin — Can perform all CiscoWorks operations including the administration and approval tasks.
You can assign this role to a user only on Cisco Secure ACS Server and only after you have:
–
Changed the AAA mode to ACS.
–
Registered the applications successfully on a ACS Server.
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:
Option
|
Description
|
Allow all CiscoWorks Local users to fallback to the CiscoWorks Local login.
|
All users can access CiscoWorks using the Local login if the current login module fails.
|
Only allow the following user(s) to fallback to the CiscoWorks Local login if preceding login fails: username.
|
Specified users can access CiscoWorks using the Local login if the current login module fails. Use commas between user names.
|
Allow no fallbacks to the CiscoWorks Local login.
|
No access is allowed if the current login module fails.
|
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:
•
NMSROOT/MDC/tomcat/logs/stdout.log (on Solaris)
•
NMSROOT\MDC\tomcat\logs\stdout.log (on Windows)
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:
•
Cisco Secure ACS 3.2 for Windows Server
•
Cisco Secure ACS 3.2.3 for Windows Server
•
Cisco Secure ACS 3.3.2 for Windows Server
•
Cisco Secure ACS 3.3.3 for Windows Server
•
Cisco Secure ACS 3.3.4 for Windows Server
•
Cisco Secure ACS 4.0.1 for Windows Server
•
Cisco Secure ACS 4.1 for Windows Server
•
Cisco Secure ACS 4.1.1 for Windows Server
•
Cisco Secure ACS 4.1.4 for Windows Server
•
Cisco Secure ACS 4.2 for Windows Server
•
Cisco Secure Appliance 3.3.3
•
Cisco Secure Appliance 3.3.4
•
Cisco Secure Appliance 4.0.1
•
Cisco Secure Appliance 4.1
•
Cisco Secure Appliance 4.1.1
•
Cisco Secure Appliance 4.1.4
•
Cisco Secure Appliance 4.2
We recommend that you install the Admin HTTPS PSIRT patch, if you are using ACS 3.2.3.
To install the patch:
Step 1
Go to http://www.cisco.com/pcgi-bin/tablebuild.pl/cs-acs-win
Step 2
Click the Download CiscoSecure ACS Software (Windows) link.
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
The fallback options are not available when you set the AAA mode as ACS.
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:
•
Changing Login Module to CiscoWorks Local
•
Changing Login Module to IBM SecureWay Directory
•
Changing Login Module to KerberosLogin
•
Changing Login Module to Local Unix System
•
Changing Login Module to Local NT System
•
Changing Login Module to MS Active Directory
•
Changing Login Module to Netscape Directory
•
Changing Login Module to Radius
•
Changing Login Module to TACACS+
To set the login module to Non-ACS mode:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > AAA Mode Setup.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Select the Non-ACS radio button.
The Login Module window displays the current login module, and the available login modules.
The available login modules are:
•
CiscoWorks Local
•
IBM SecureWay Directory
•
KerberosLogin
•
Local UNIX System
•
Local NT System
•
MS Active Directory
•
Netscape Directory
•
Radius
•
TACACS+
The login username is case sensitive when you use the following Non-ACS login modules:
•
KerberosLogin
•
Netscape Directory
•
Local UNIX System
•
Radius (only on Solaris)
•
TACACS+ (only on Solaris)
Step 3
Select a login module.
The Login Module Options popup window appears.
Step 4
Enter the corresponding login module information.
See the respective login module section for login module options.
Step 5
Click OK.
Changing Login Module to CiscoWorks Local
To change the login module to CiscoWorks Local:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > AAA Mode Setup.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Select the Non-ACS radio button.
The Login Module window displays the available login modules.
Step 3
Select the CiscoWorks Local radio button.
Step 4
Click Change.
The Login Module Options popup window appears.
Step 5
Set the Debug option to False.
Set it to True for debugging purposes, when requested by your customer service representative.
Step 6
Click OK.
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
Go to the CiscoWorks home page and select Common Services > Server > Security > AAA Mode Setup.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Select the Non-ACS radio button.
The Login Module window displays the available login modules.
Step 3
Select the IBM SecureWay Directory radio button.
Step 4
Click Change.
The Login Module Options popup window appears with the following details:
Field
|
Description
|
Selected Login Module
|
IBM SecureWay Directory
|
Description
|
CiscoWorks IBM LDAP module.
|
Server
|
Default set to ldap://ldap.company.com.
|
Usersroot
|
Default set to ou=active, ou=employees, ou=people, o=company
|
Prefix
|
Default set to cn=
|
Debug
|
Set to False, by default.
Set to True for debugging purposes, when requested by your customer service representative.
|
Login fallback options
|
Set the option for fallback to the CiscoWorks Local module if the alternative service fails.
|
Step 5
Click OK.
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
Go to the CiscoWorks home page and select Common Services > Server > Security > AAA Mode Setup.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Select the Non-ACS radio button.
The Login Module window displays the available login modules.
Step 3
Select the KerberosLogin radio button.
Step 4
Click Change.
The Login Module Options popup window appears with the following details:
Field
|
Description
|
Selected Login Module
|
KerberosLogin Kerberos login module.
|
Description
|
Kerberos login module.
|
Debug
|
Set to False, by default.
Set to True for debugging purposes, when requested by your customer service representative.
|
Realm
|
The Kerberos realm name. Although the realm can be any ASCII string, the convention is to make it the same as your domain name, in upper-case letters.
For example, SERVER.COM.
|
KDC
|
The Kerberos Key Distribution Center. For example, my_kdc.server.com.
|
Login fallback options
|
Set the option for fallback to the CiscoWorks Local module if the alternative service fails.
|
Step 5
Click OK.
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
Go to the CiscoWorks home page and select Common Services > Server > Security > AAA Mode Setup.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Select the Non-ACS radio button.
The Login Module window displays the available login modules.
Step 3
Select the Local Unix System radio button.
Step 4
Click Change.
The Login Module Options popup window appears with the following details:
Field
|
Description
|
Selected Login Module
|
Local UNIX System.
|
Description
|
CiscoWorks native Solaris module.
|
Debug
|
Set to False, by default.
Set to True for debugging purposes, when requested by your customer service representative.
|
Login fallback options
|
Set the option for fallback to the CiscoWorks Local module if the alternative service fails.
|
Step 5
Click OK.
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
Go to the CiscoWorks home page and select Common Services > Server > Security > AAA Mode Setup.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Select the Non-ACS radio button.
The Login Module window displays the available login modules.
Step 3
Select Local NT System radio button.
Step 4
Click Change.
The Login Module Options popup window appears with the following details:
Field
|
Description
|
Selected Login Module
|
Local NT System.
|
Description
|
CiscoWorks native NT login module.
|
Debug
|
Set to False, by default.
Set to True for debugging purposes, when requested by your customer service representative.
|
Domain
|
Set to localhost.
|
Login fallback options
|
Set the option for fallback to the CiscoWorks Local module if the alternative service fails.
|
Step 5
Click OK.
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:
•
Distinguished Name (DN)
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 (UPN)
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.
•
Domain name
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
Go to the CiscoWorks home page and select Common Services > Server > Security > AAA Mode Setup.
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
Select the Non-ACS radio button.
The Login Module window displays the available login modules.
Step 3
Select MS Active Directory radio button.
Step 4
Click Change.
The Login Module Options popup window appears with the following details:
Field
|
Description
|
Selected Login Module
|
Name of the login module (MS Active Directory) you have selected in the AAA Mode setup page.
|
Description
|
Brief description about the login module you have selected.
For the MS Active Directory login module, the description displayed is CiscoWorks MS Active Directory module.
|
Server
|
Name of the LDAP server.
Default set to ldap://ldap.company.com.
|
Usersroot
|
User objects in MS Active Directory.
Default set to cn=users, dc=servername, dc=company, dc=com.
For example, if users in the Active Directory have ou=myDept, dc=myCompany, dc=com in their Distinguished Name (DN) strings, you should specify the same in this field to integrate the CiscoWorks Server with the MS Active Directory server.
You can also enter multiple usersroot values separated by semicolon.
For example, you can enter ou=myDept, dc=myCompany, dc=com; ou=Dept1, ou=Dept2, dc=myCompany, dc=com.
When you integrate your CiscoWorks Server with MS Active server, you should configure this field for a Distinguished Name based authentication.
If you are using Windows 2003 Active Directory, you have to provide the complete Usersroot information (including cn=Username). This is because Windows 2003 Active Directory implementation has disabled anonymous search requests.
Otherwise, if your Active Directory Server allows anonymous binds, you can specify only dc=servername, dc=company, dc=com.
|
RDN-Prefix
|
String prefixed with login username to form a Relative Distinguished Name (RDN).
Default is set to cn=.
For example when you have configured this field as cn= and log into the server as MyUser, the RDN formed is cn=MyUser.
When you integrate your CiscoWorks Server with MS Active server, you must configure this field for a Distinguished Name based authentication.
|
UPN-Suffix
|
String suffixed with login username, usually the domain in which the user account is located to form a User Principal name.
You should configure this field for a UPN based authentication.
For example, if the UPN of Active Directory users who need to be integrated with CiscoWorks are user1@mydept.mycompany.com, user2@mydept.mycompany.com, and user3@mydept.mycompany.com, you should mention @mydept.mycompany.com in this field.
|
AD-Domain
|
Active Directory domain.
You should configure this field for a domain based authentication. Users of the specified domain in MS Active Directory server are authenticated when you integrate the CiscoWorks Server with MS Active Directory server.
|
Debug
|
Set to False, by default.
Set to True for debugging purposes, when requested by your customer service representative.
|
Login fallback options
|
Set the option for fallback to the CiscoWorks Local module if the alternative service fails.
You can set any of the following options:
• Allow all CiscoWorks local users to fallback to the CiscoWorks Local login.
• Allow only the specified users to fallback to the CiscoWorks Local login.
When you select this option, you should enter one or more CiscoWorks local usernames separated by commas.
This is the default login fallback option.
• Do not allow any fallback to the CiscoWorks Local login.
|

Note
You must enter a value for atleast one of the fields: Usersroot, UPN-Suffix, and AD-Domain. You cannot leave all the three fields blank.
Step 5
Click OK.
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
Go to the CiscoWorks home page and select Common Services > Server > Security > AAA Mode Setup.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Select the Non-ACS radio button.
The Login Module window displays the available login modules.
Step 3
Select the Netscape Directory radio button.
Step 4
Click Change.
The Login Module Options popup window appears with the following details:
Field
|
Description
|
Selected Login Module
|
Netscape Directory.
|
Description
|
CiscoWorks Netscape LDAP module.
|
Server
|
Default set to ldap://ldap.company.com.
|
Usersroot
|
Default set to ou=active, ou=employees, ou=people, o=company.com.
|
Prefix
|
Default set to uid=
|
Debug
|
Set to False, by default.
Set to True for debugging purposes, when requested by your customer service representative.
|
Login fallback options
|
Set the option for fallback to the CiscoWorks Local module if the alternative service fails.
|
Step 5
Click OK.
Changing Login Module to Radius
To change login module to Radius:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > AAA Mode Setup.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Select the Non-ACS radio button.
The Login Module window displays the available login modules.
Step 3
Select the Radius radio button.
Step 4
Click Change.
The Login Module Options popup window appears with the following details:
Field
|
Description
|
Selected Login Module
|
Radius.
|
Description
|
CiscoWorks Radius module.
|
Server
|
Set to module type servername, radius.company.com.
|
Port
|
Set to 1645. Attempt to override it only if your authentication server was configured with a non-default port.
|
Key
|
Enter the secret key.
|
Debug
|
Set to False, by default.
Set to True for debugging purposes, when requested by your customer service representative.
|
Login fallback options
|
Set the option for fallback to the CiscoWorks Local module if the alternative service fails.
|
Step 5
Click OK.
Changing Login Module to TACACS+
To change login module to TACACS+:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > AAA Mode Setup.
If LMS Portal is installed on CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Select the Non-ACS radio button.
The Login Module window displays the available login modules.
Step 3
Select TACACS+ radio button.
Step 4
Click Change.
The Login Module Options popup window appears with the following details:
Field
|
Description
|
Selected Login Module
|
TACACS+.
|
Description
|
CiscoWorks TACACS+ login module.
|
Server
|
Set to module type tacacs.company.com
|
Port
|
Set to 49. The listed port number is the default for this protocol.
Attempt to override it only if your authentication server was configured with a non-default port.
|
Secondary Server
|
Set to module type tacacs.company.com. This is the secondary fallback server.
|
Secondary Port
|
Set to 49. The listed port number is the default for this protocol.
Attempt to override it only if your authentication server was configured with a non-default port.
|
Tertiary Server
|
Set to module type tacacs.company.com. This is the tertiary fallback server.
|
Tertiary Port
|
Set to 49. The listed port number is the default for this protocol.
Attempt to override it only if your authentication server was configured with a non-default port.
|
Key
|
Enter the secret key.
|
Debug
|
Set to False, by default.
Set to True for debugging purposes, when requested by your customer service representative.
|
Login fallback options
|
Set the option for fallback to the CiscoWorks Local module if the alternative service fails.
|

Note
The values True or False should not be entered in the Server, Secondary Server and Tertiary Server fields, the corresponding Port fields or the Key field.
Step 5
Click OK.
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:
•
NMSROOT/MDC/Tomcat/logs/stdout.log (On Solaris)
•
NMSROOT\MDC\Tomcat\logs\stdout.log (On Windows)
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:
•
Add the CiscoWorks Server as an AAA client in ACS Server
•
Add the network devices to be managed by CiscoWorks Server as AAA clients in ACS
•
Configure users in ACS with required administrative privileges
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
•
Additional Notes on Setting the AAA Mode to ACS
•
Registering Applications With ACS
•
Registering Applications With ACS Through CLI
•
Unregistering Applications From ACS Through CLI
Setting Up the AAA Mode to ACS
To set the login module to ACS:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > AAA Mode Setup.
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
Select the ACS radio button.
Step 3
Enter the following server details:
•
Primary IP Address/Hostname
•
Secondary IP Address/Hostname
•
Tertiary IP Address/Hostname
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
Enter the following login details:
•
ACS Admin Name—Enter the admin name which you use to log into ACS Server.
•
ACS Admin Password—Enter the password which you use to log into ACS Server.
•
ACS Shared Secret Key—Enter the shared secret key which you used to add the CiscoWorks Server as an AAA client in ACS Server.
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
Select Register all installed applications with ACS to register all the installed applications with the ACS Server for the first time.
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
Select either HTTP or HTTPS as your current ACS Administrative Access Protocol.
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
Click Apply.
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:
Summary
|
Description
|
TACACS+ Connectivity
|
Displays whether the TACACS+ connectivity with ACS is:
• Reachable
Or
• Not Reachable
When the ACS Server is not reachable, it also displays the reason for failure. The possible reasons for failure include:
– ACS services are not running in given port
– Server is not reachable
– ACS Server name is invalid
|
HTTP/HTTPS Connectivity
|
Displays whether the HTTP or HTTPS connectivity with ACS is:
• Reachable
Or
• Not Reachable
When the connectivity fails, it also displays the reason for failure. The possible reasons for failure include:
– Protocol mismatch detected
– ACS Admin credentials are configured wrongly
– ACS Admin User may not have full privileges
– IP Filtering may be configured in ACS
|
AAA Client
|
Displays whether the AAA client in ACS as:
• Configured
Or
• Not Configured
|
Secret Key Verification
|
Displays the verification status as:
• Succeeded
Or
• Mismatch Detected
|
System Identity User
|
Displays the verification status as:
• Configured
Or
• Not configured properly for AppName,
where AppName is the name or names of the CiscoWorks Applications.
|
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
Click Apply in the ACS Verification Status popup window.
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
Restart the Daemon Manager:
On Windows:
a.
Enter net stop crmdmgtd
b.
Enter net start crmdmgtd
On Solaris:
a.
Enter /etc/init.d/dmgtd stop
b.
Enter /etc/init.d/dmgtd start
Additional Notes on Setting the AAA Mode to ACS
You should read the following notes before using the CiscoWorks applications in ACS mode:
•
If you install any application on the CiscoWorks Server when AAA mode is set to ACS, you might be prompted to re-register the application with ACS. See Registering Applications With ACS or Registering Applications With ACS Through CLI to register the applications with ACS Server.
•
You must restart the Daemon Manager when you change the login module to ACS. Only then the mode change will come into effect.
•
Ensure that the system identity user configured in Common Services is available in CiscoSecure ACS with all privileges.
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:
•
All the applications already registered in ACS Server are over-written.
•
Custom roles created in ACS Server are lost.
The application registration with ACS fails due to any of the following reasons:
•
Protocol mismatch
If ACS is running in HTTPS mode, enable the Connect to ACS in HTTPS mode checkbox in the Login Module dialog box.
•
Invalid ACS admin credentials
Ensure that the ACS credentials provided in the CiscoWorks AAA Mode setup screen are correct.
•
ACS Administrative user not configured with all privileges
Configure the ACS administrator with at least the following privileges in ACS:
–
Create New Device Command Set Type
–
Network Configuration
–
Tacacs+ Administration
•
Sufficient number of administrative ports not allocated for registration
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:
•
List the applications registered with ACS from this CiscoWorks Server.
•
List the applications installed in this CiscoWorks Server that are not registered with ACS.
•
Register a given application with ACS.
•
Register all the installed applications with ACS.
To get a list of available options, run the script AcsRegCli.pl without specifying any option.
The following options are listed:
•
listRegApp —List the applications registered with ACS in the current CiscoWorks Server.
•
listNotRegApp—List the installed applications that are not registered with ACS in the current CiscoWorks Server.
•
register AppName —Register an application with ACS. AppName is the name by which an application will be registered with ACS.
To know this value, run AcsRegCli.pl with the option -listRegApp or -listNotRegApp.
•
register all— Register all the installed applications with ACS.
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:
•
If the application is already registered with ACS, you are prompted to confirm whether you want to proceed with the registration. If you confirm this, the application is registered with ACS, and any custom roles created in ACS for this application are lost.
•
If you use the -register all option, you are prompted to confirm whether you want to proceed with registering all the installed applications with ACS. If you confirm, all the installed applications will be registered with ACS, and any custom roles created in ACS are lost.
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.
•
To unregister a specific application, run the command:
–
NMSROOT/bin/perl NMSROOT/bin/AcsRegCli.pl -unregister AppName (On Solaris)
–
NMSROOT\bin\perl NMSROOT\bin\AcsRegCli.pl -unregister AppName (On Windows)
where,
NMSROOT — CiscoWorks Installation directory.
•
AppName — Short name of the application. For example, you can enter cmf, rme and so on. To know this value, run AcsRegCli.pl with the option -listRegApp or -listNotRegApp.
•
To unregister all the registered applications from ACS, run the command:
–
NMSROOT/bin/perl NMSROOT/bin/AcsRegCli.pl -unregister all (On Solaris)
–
NMSROOT\bin\perl NMSROOT\bin\AcsRegCli.pl -unregister all (On Windows)
Authentication Failure in ACS Mode
When you try log into CiscoWorks Server in ACS mode, authentication may fail due to the following possible reasons:
•
Invalid username or password.
•
Invalid ACS configurations such as secret key mismatch.
•
ACS Server is not reachable.
•
TACACS is not enabled in ACS.
•
CiscoWorks Server is not added as an AAA client in ACS.
•
Authentication protocol is not set up as TACACS + (CISCO IOS) in ACS for CiscoWorks Server configured as a AAA client.
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:
•
Check the connectivity of the ACS Server
•
Verify the ACS configurations
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
Stop the Daemon Manager using:
•
net stop crmdmgtd (On Windows)
or
•
/etc/init.d/dmgtd stop (On Solaris)
Step 2
Run the following script:
•
NMSROOT\bin\perl NMSROOT\bin\ResetLoginModule.pl (On Windows)
or
•
NMSROOT/bin/perl NMSROOT/bin/ResetLoginModule.pl (On Solaris)
where NMSROOT is your CiscoWorks Installation directory.
Step 3
Start the Daemon Manager using:
•
net start crmdmgtd (On Windows)
or
•
/etc/init.d/dmgtd start (On Solaris)
This resets the login module to CiscoWorks local mode.
Step 4
Enter a username in the User ID field.
Step 5
Enter the corresponding password in the Password field.
Step 6
Click Login or press Enter.
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:
•
User Guide for Cisco Secure Access Control Server 4.x
This guide explains the features in Cisco Secure ACS. We recommend you to review the guide available on Cisco.com for any updates.
•
CiscoWorks LMS Integration with Cisco Secure ACS whitepaper
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
•
Setting up ACS Server
•
Changing the Login Module to ACS
•
Roles in ACS
•
Assigning Roles to Users and User Groups in ACS
Prerequisites for CiscoWorks-ACS Integration
Before you integrate the CiscoWorks Server with ACS, ensure that you:
1.
Set up a System Identity User on CiscoWorks Server
See Setting up System Identity Account to configure a System Identity User.
2.
Assign all the local user privileges to System Identity User on CiscoWorks Server
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
•
Creating a Network Device Group
•
Adding CiscoWorks Server and Network Devices as AAA Clients in ACS
•
Configuring CiscoWorks Administrative Users in ACS
•
Configuring Multiple ACS Servers
Configuring ACS Administrators
You should configure the ACS administrators with all privileges in ACS. The ACS administrator account in ACS is required to:
•
Access the ACS server from any remote machine.
•
Enter the login details during the AAA mode setup in Common Services. Only then the authentication takes place from the ACS Server.
Also, if you do not configure the ACS administrative user with all the privileges, the application registration with ACS will fail.
Note
The default administrative user in ACS Appliance may not have all the required privileges. We recommend you to create a new administrator account in ACS and assign all the required privileges.
To configure an ACS Administrator:
Step 1
Log into Cisco Secure ACS Server.
Step 2
Click Administration Control from the navigation bar at the left.
Step 3
Click Add Administrator from the Administration Control page.
Step 4
Enter the name of the ACS administrator in the Administrator Name field.
Step 5
Enter the password for the ACS administrator account.
Step 6
Re-enter the password in the Confirm field.
Step 7
Click Grant All to grant all the privileges to the administrator. Otherwise, you should select and assign the required privileges.
To remove the assigned privileges, click Revoke All.
Step 8
Click Submit.
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
If you add or change device information in a NDG, the change will be propagated to Common Services only upon a refresh of Common Services DCR Administration user interface.
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
Go to Cisco Secure ACS and select Interface Configuration.
Step 2
Click Advanced Options from the Interface Configuration page to open the Advanced Options page.
Step 3
Select Network Device Groups.
Step 4
Click Submit.
To create a new Network Device Group:
Step 1
Log into Cisco Secure ACS Server.
Step 2
Click Network Configuration from the navigation bar at the left.
The list of Network Device Groups appear.
Step 3
Click Add Entry.
The New Network Device Group page appears.
Step 4
Enter a name for the NDG you want to create in the Network Device Group Name field.
Step 5
Enter a value for NDG key in the Key Field. This is optional.
Step 6
Click Submit.
Tip
We recommend that you have 50 NDGs as a maximum in your ACS Server. More number of NDGs in the ACS Server may affect the system performance.
Adding CiscoWorks Server and Network Devices as AAA Clients in ACS
You should configure the following as AAA Clients in ACS Server:
1.
CiscoWorks Server
2.
Devices managed by CiscoWorks Server
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
Log into Cisco Secure ACS Server.
Step 2
Click Network Configuration from the navigation bar at the left.
Step 3
Select a Network Device Group (NDG) from the list of Network Device Groups available.
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
Click Add Entry to launch the Add AAA Client page.
Step 5
Enter the hostname of the CiscoWorks Server or a network device to be added as a AAA client in the AAA Client Hostname field.
The name entered in this field for a network device will be updated in the Display Name field in DCR.
Step 6
Enter the IP Address of CiscoWorks Server or a network device in the AAA Client IP Address field.
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:
•
Wildcard characters —For example, you can enter the IP Address of CiscoWorks Server as *.*.*.* as AAA client IP Address.
•
IP Address Range—For example, you can enter 10.77.210.100-200.
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
Enter a value for key (secret key) in the Key Field.
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
Select a different NDG from the Network Device Group drop-down list, if you want to change the Network Device Group. This is optional.
Step 9
Choose the authentication protocol as TACACS+ (Cisco IOS) from the Authenticate Using drop-down list.
Step 10
Click Submit + Restart if you are using ACS version earlier than 4.0.
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
Log into Cisco Secure ACS.
Step 2
Click Group Setup from the navigation bar at the left.
Step 3
Select a group name from the Group drop-down list.
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
Rename the group you have selected with a meaningful and suitable name.
To add CiscoWorks Administrative users including the System Identity User in ACS:
Step 1
Log into Cisco Secure ACS.
Step 2
Click User Setup from the navigation bar at the left.
Step 3
Enter the username for CiscoWorks Administrative user in ACS.
Step 4
Click Add/Edit.
Step 5
Enter the password for the CiscoWorks user in the User Setup page that appears.
Step 6
Re-enter the password to confirm.
Step 7
Map the user to a user group by selecting a group name from the drop-down list.
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:
•
Restart the Daemon Manager after you have changed the AAA mode to ACS.
•
If you install any application on the CiscoWorks Server when AAA mode is set to ACS, you might be prompted with a message to re-register the application with ACS. See Registering Applications With ACS or Registering Applications With ACS Through CLI to register the applications with ACS Server.
•
AAA clients, Network Device Groups (NDGs), users, groups, registered applications, and custom roles must be the same across Primary, Secondary, and Tertiary ACS servers.
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:
•
Assign predefined roles to CiscoWorks Users in ACS
Or
•
Create custom roles and assign them to CiscoWorks Users in ACS.
This section explains the following:
•
Predefined Roles
•
Custom Roles
•
Common Services Tasks
Predefined Roles
The ACS authorization scheme provides you the following default roles.
•
Help Desk — Can access network status information only. Can access persisted data on the system and cannot perform any action on a device or schedule a job which will reach the network.
•
Approver — Can approve all tasks.
•
Network Operator — Can perform all Help Desk tasks. Can perform tasks related to network data collection. Cannot perform any task that requires write access on the network.
•
Network Administrator — Can perform all Network Operators tasks. Can perform tasks that result in a network configuration change.
•
System Administrator — Can perform all CiscoWorks system administration tasks.
•
Super Admin — Can perform all CiscoWorks operations including the administration and approval tasks. By default, this role has full privileges.
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
Go to Cisco Secure ACS.
Step 2
Select Shared Profile Components > CiscoWorks Common Services.
The Shared Profile Components page appears.
Step 3
Click Add.
Step 4
Enter the name and description for the new role.
Step 5
Select the Common Services tasks that you need to associate with the role.
Tasks are displayed as a checklist tree on the left pane of the ACS UI.
•
If you select an expandable check box node, all check boxes within that node are selected.
•
If you select the first check box in the checklist tree, all check boxes in the checklist tree are selected.
Step 6
Click Submit.
To edit an existing role:
Step 1
Go to Cisco Secure ACS.
Step 2
Select Shared Profile Components > CiscoWorks Common Services.
The Shared Profile Components page appears.
Step 3
Select the role you need.
The Shared Profile Components page displays the Edit dialog box.
Step 4
Select the Common Services tasks that you need to associate with the role.
If you want to remove any task associated with the role, deselect the check box corresponding to the task.
Step 5
Click Submit.
To delete a role:
Step 1
Go to Cisco Secure ACS.
Step 2
Select Shared Profile Components > CiscoWorks Common Services.
The Shared Profile Components page appears.
Step 3
Select the role you need to delete.
The Shared Profile Components page displays the Edit dialog box.
Step 4
Click Delete.
Common Services Tasks
When Common Services is registered with ACS, the following is a subset of Common Services tasks that appear in ACS:
•
Home Page Configuration
•
Server Configuration
•
Device and Credential Admin
•
Group Administration
•
Software Center
•
Device Center
•
Job and Resource Management Tasks
•
Light Weight Messaging System
•
Connectivity Tools
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
•
Assigning Roles to Users
•
Assigning Roles on NDG Basis
•
Network Access Restrictions to Users and User Groups in ACS
Assigning Roles to User Groups
To assign the roles and privileges to the user if ACS is configured to use group authentication:
Step 1
Go to Cisco Secure ACS and select Group Setup.
Step 2
Select the group to which the user belongs, from the Group drop-down list. See Configuring CiscoWorks Administrative Users in ACS to define a group.
Step 3
Click Edit Settings.
A page appears with the group settings.
Step 4
Scroll down to CiscoWorks. The available options are :
•
None
Authorization will fail for any task.
•
Assign a Ciscoworks for any network device.
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.
•
Assign a Ciscoworks on a per Network Device Group Basis.
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
Select any of the options, based on the required security level.
Step 6
Click Submit to save the changes.
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
Go to Cisco Secure ACS and select Interface Configuration.
Step 2
Click Advanced Options from the Interface Configuration page to open the Advanced Options page.
Step 3
Select the Per-user TACACS+/RADIUS Attributes option.
Step 4
Click Submit to return to the Interface Configuration page.
Step 5
Click TACACS+ (Cisco) from the Interface Configuration page to open the TACACS+ (Cisco) page.
Step 6
Go to the New Services panel.
Step 7
Enable the User checkboxes for a desired list of CiscoWorks Services available in the New Services panel.
Step 8
Click Submit.
To assign the roles and privileges if ACS is configured to use user authentication:
Step 1
Go to Cisco Secure ACS and select User Setup.
Step 2
Enter the user name and click Add/Edit.
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
Scroll down to CiscoWorks.
The CiscoWorks options are available only when you have enabled the user authentication for CiscoWorks Services.
The options are:
•
None: Authorization will fail for any task.
•
As Group: The privileges applicable to the group, the user is part of.
•
Assign a Ciscoworks for any network device.
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.
•
Assign a Ciscoworks on a per Network Device Group Basis.
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
Select any of the options, based on the required security level.
Step 5
Click the Submit button to save the changes.
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:
•
If you have assigned any Network Device Group to your AAA client (CiscoWorks Server and network devices), you must assign that device group to any role.
You cannot have role and device group combinations assigned to a user without assigning the Network Device Group where your AAA client is present.
•
You can assign only one role to a user in ACS, to operate on the same NDG.
•
If a user requires privileges other than those associated with the current role, to operate on an NDG, a custom role should be created. All necessary privileges to enable the user operate on the NDG should be given to this role.
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.
•
You should assign the predefined Super Admin role for System Identity user in ACS Server. Otherwise you should create a custom role with all privileges and assign the custom role to the system identity user. See Roles in ACS for more information.
•
We recommend that you do not assign roles to DEFAULT device group. When DEFAULT (unassigned device group) is selected, you can perform only Help Desk role, irrespective of the roles chosen.
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
•
Setting Up the Proxy Server
Setting up Cisco.com User Account
To set up Cisco.com login account:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Security > Cisco.com Connection Management > Cisco.com User Account Setup.
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
Enter your Cisco.com Username, and Cisco.com Password.
Step 3
Re-enter Password in the Verify Password field.
Step 4
Click Apply.
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
Go to the CiscoWorks home page and select Common Services > Server > Security > Cisco.com Connection Management > Proxy Server Setup.
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
Enter the Proxy Server host name or IP address, and the port number.
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
Click Apply.
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:
•
Log File Status Report
•
Permissions Report
•
Users Logged In Report
•
Process Status Report
•
Viewing Audit Log Report
The following sections describe how to launch these reports, and explain each report.
To generate a report:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Reports.
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
Select a report from the left panel tree to view a short description, summary, or parameters of the report.
Step 3
Click Generate Report to view the report.
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:
•
Sort the report using any column in the ascending or descending order.
•
View the report in a printer-friendly format.
•
Export the report to a file of CSV or PDF format.
•
Set the number of records to be displayed per report page, as desired. You can set the number as 20, 50, 100, or 500.
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
Go to the CiscoWorks home page and select Common Services > Server > Reports.
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
Select Log File Status from the Available Reports pane.
Step 3
Click Generate Report.
The Log File Status Report appears with the following details:
Item
|
Description
|
Log File
|
Name of the log file.
* displayed with the log file name denotes that there are multiple files available.
|
Location
|
Location of the log file.
|
File Size
|
Current size of the log file.
File size displayed in red means the size has exceeded the limit.
|
Size Limit
|
Maximum size a log file can have.
|
File System Utilization
|
File system utilization in percentage.
If the value appears n red, it denotes that the size has exceeded the limit of 90% utilization. You should reduce the size of your log files if your file system utilization is over 90%.
|
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
Go to the CiscoWorks home page and select Common Services > Server > Reports.
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
Select Permissions Report from the Available Reports pane.
Step 3
Click Generate Report.
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
Go to the CiscoWorks home page and select Common Services > Server > Reports.
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
Select Who is Logged On from the Available Reports pane.
Step 3
Click Generate Report.
The Users Logged In report appears with the following information:
Item
|
Description
|
Status
|
Displays the status as Online
|
User Name
|
User name.
|
HD
|
Help Desk role
|
AP
|
Approver role
|
NO
|
Network Operator role
|
NA
|
Network Administrator role
|
SA
|
System Administrator role
|
IP address
|
IP address.
|
Last Active
|
Date and time when the user was previously active.
|
Logged in
|
Time when the user previously logged in.
|
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
If you are using Microsoft Internet Explorer, make sure your browser is set to check for updates on every visit to the page.
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
Go to the CiscoWorks home page and select Common Services > Server > Reports.
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
Select Process Status from the Available Reports pane.
Step 3
Click Generate Report.
The Process Status Report appears with the following information:
Item
|
Description
|
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:
|
Information
|
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:
•
User login and logout from CiscoWorks
•
CiscoWorks Local user addition
•
CiscoWorks Local user modification
•
CiscoWorks Local user deletion
•
Change of CiscoWorks server mode from non-ACS to ACS or from ACS to non-ACS
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
Select Common Services > Server > Reports > Audit Log in the CiscoWorks Common Services navigation tree.
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
Click Generate Report.
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
Click an Audit Log file link to view the audit log details.
The Audit Log report contains:
Item
|
Description
|
Date
|
Date on which the activity is carried out.
|
Time
|
Time at which the activity is carried out.
|
User
|
User who performed the activity. If you reset the CiscoWorks user password using resetpasswd utility, User is shown as CLI Utility
|
Acct-Flags
|
Status of the activity.
For example: start
|
Service
|
Application that the user accessed. For Common Services, the value displayed is cwhp.
|
Cmd
|
Activity that was performed.
Examples:
1. Logout
2. Mode
|
Reason
|
Description of the activity.
Examples:
1. User admin logged out of cwhp
2. ACS
|
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
•
Managing Processes
•
Backing Up Data
•
Licensing CiscoWorks Applications
•
Collecting Server Information
•
Collecting Self Test Information
•
Messaging Online Users
•
Managing Jobs
•
Managing Resources
•
Maintaining Log Files
•
Configuring Log Files Rotation
•
Modifying System Preferences
•
Configuring Logging
•
Configuring Disk Space Threshold Limit
•
Effects of Third Party Backup Utility and Virus Scanner
•
Configuring TFTP
Using Daemon Manager
The Daemon Manager provides the following services:
•
Maintains the startup dependencies among processes.
•
Starts and stops processes based on their dependency relationships.
•
Restarts processes if an abnormal termination is detected.
•
Monitors the status of processes.
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
Log in as root.
Step 2
Enter /etc/init.d/dmgtd stop to stop the Daemon Manager.
Step 3
Enter /etc/init.d/dmgtd start to start the Daemon Manager.
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
Go to the command prompt.
Step 2
Enter net stop crmdmgtd to stop the Daemon Manager.
Step 3
Enter net start crmdmgtd to start the Daemon Manager.
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:
•
View the details of all processes
•
Filter and show only processes of a specific state
•
Start the processes
•
Stop the processes
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
Your role and privileges determine whether you can use this option.
This section contains the following:
•
Process States
•
Viewing Process Details
•
Viewing Processes of a Specific State
•
Starting a Process
•
Stopping a Process
Process States
The state of the CiscoWorks backend processes fall under either one of the following categories:
State
|
Description
|
Running normally
|
Processes are started and are running normally.
Sometimes, you find the state of few processes as follows:
Program started - No mgt msgs received
This indicates that the processes are started automatically at boot and are running normally.
|
Never started
|
Processes that cannot start automatically and are to be started by operator or administrator.
|
Failed to run
|
Processes that failed to start because of an error in the system.
|
Administratively shutdown
|
Processes that are stopped by the system or by the administrator.
|
Transient Terminated
|
Terminated transient processes.
Processes that are created or started by Daemon Manager whenever required are called transient processes.
|
Waiting to Initialize
|
Processes that are yet to run normally and are in initialization phase.
|
Viewing Process Details
To view Process details:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Admin > Process.
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:
Column
|
Description
|
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
Click the ProcessName link of a process to view its details.
The Process Details popup window appears with the following information:
Column
|
Description
|
Process
|
Name of the process.
|
Path
|
File Location.
|
Flags
|
Flags used to register the process with the Daemon Manager.
|
Startup
|
Method used to start the process (manual or automatic).
|
Dependencies
|
Other processes that are running and are required for this process to run.
|
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
Go to the CiscoWorks home page and select Common Services > Server > Admin > Process.
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
Select a process state from the Show Only process state.
You can select any one of the following process states:
•
Never started
•
Waiting to initialize
•
Running normally
•
Failed to run
•
Transient terminated
•
Administrator has shut down this server
•
Program started — No mgt msgs received
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
Go to the CiscoWorks home page and select Common Services > Server > Admin > Process.
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
Select the check box corresponding to the process.
Step 3
Click Start.
Stopping a Process
To stop a process:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Admin > Process.
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
Select the check box corresponding to the process.
Step 3
Click Stop.
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
Process Name
|
Description
|
Normal Process State
|
Dependent Process
|
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
•
Viewing Brief Details of Processes
•
Viewing Processes Statistics
•
Starting a Process
•
Stopping a Process
Viewing Process Details Through CLI
The pdshow command displays the details of the specified processes or all processes in the CLI prompt.
•
To display the details of all processes, enter:
–
/opt/CSCOpx/bin/pdshow (on Solaris)
–
pdshow (on Windows)
where NMSROOT is the CiscoWorks installation directory.
•
To display the details of one or more specified processes, enter:
–
/opt/CSCOpx/bin/pdshow ProcessName1 ProcessName2 (on Solaris)
–
pdshow ProcessName1 ProcessName2 (on Windows)
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.
•
Process Name
•
Process State
•
Process ID
•
Process Return Code
•
Process Signal Number
•
Process Start Time
•
Process Stop Time
The pdshow command additionally displays the following process details.
Process Details
|
Description
|
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:
|
Information
|
Describes what the process is doing and how it is started.
Not applicable means the program is not running normally.
|
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.
•
To display the brief details of all processes, enter:
–
/opt/CSCOpx/bin/pdshow -brief (on Solaris)
–
pdshow -brief (on Windows)
where NMSROOT is the CiscoWorks installation directory.
•
To display the details of one or more specified processes, enter:
–
/opt/CSCOpx/bin/pdshow -brief ProcessName1 ProcessName2 (on Solaris)
–
pdshow -brief ProcessName1 ProcessName2 (on Windows)
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:
•
Process Name
•
Process State
•
Process ID
For example, if you enter /opt/CSCOpx/bin/pdshow -brief Tomcat Apache in the command prompt, the following output is displayed:
Tomcat Program Started - No mgt msgs received 13824
Apache Running normally 13847
Viewing Processes Statistics
The pdshow -stat command displays the statistics of all processes or specified processes in tabular format.
Note
You can enter this command only on Solaris systems.
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.
Process Details
|
Description
|
Pid
|
Process ID
|
%CPU
|
CPU usage of a process at a particular time expressed in terms of percentage
|
RSS
|
Resident set size displayed in terms of KB
|
VSZ
|
Virtual memory size of process displayed in terms of KB
|
%MEM
|
Ratio of resident set size and physical memory expressed in terms of percentage
|
NLWP
|
Number of light weight processes of the specified process
|
Process
|
Name of the process
|
Starting a Process
You must enter the following commands to start a process through CLI:
•
/opt/CSCOpx/bin/pdexec ProcessName (on Solaris)
•
pdexec ProcessName (on Windows)
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:
•
/opt/CSCOpx/bin/pdterm ProcessName (on Solaris)
•
pdterm ProcessName (on Windows)
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 
You should never backup data to the CiscoWorks Installation directory
NMSROOT/backup. Sometimes, storing the backup data in this location may corrupt the CiscoWorks installation.
To schedule a backup:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Admin > Backup.
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
Enter the appropriate information in the following fields:
Field
|
Description
|
Backup Directory
|
Location of the backup directory. We recommend that your target location be on a different partition than the CiscoWorks installation location.
The backup directory should not contain any special character.
|
Generations
|
Maximum number of backups to be stored in the backup directory.
|
Time
|
From the lists, select the time period between which you want the backup to occur. Use a 24-hour format.
|
E-mail
|
Enter a valid e-mail ID in this field.
You can enter multiple e-mail IDs separated by comma.
The system uses the e-mail ID or e-mail IDs to notify you the following:
• New backup schedules.
• Status of immediate or scheduled backup jobs upon their completion.
• Cancelled backup schedules.
Warning  There may be a problem in sending e-mails when you have enabled virus scanner in the CiscoWorks Server.
|
Frequency
|
Select the backup schedule:
• Immediately - The database is backed up immediately.
• Daily - The database is backed up every day at the time specified.
• Weekly - The database is backed up once a week on the day and time specified. Select a day from the Day of week list.
• Monthly - The database is backed up once a month on the day and time specified. Select a day from the Day of month list.
You cannot schedule more than one backup at a time. The new schedule overwrites the previous schedule, if any.
|
Step 3
Click Apply.
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]
•
BackupDirectory—Directory that you want to be your Backup directory.
•
LogFile— Log file name that contains the details of the backup
•
Num_Generations—Maximum backup generations to be kept in the backup directory.
Data Backed up During CS 3.2 Backup
The following data is backed up:
•
CiscoWorks User information
•
Single Sign-on configuration
•
Device and Credential Repository (DCR) configuration
•
Peer Certificates and Self Signed certificates
•
Peer Server Account information
•
Login Module settings
•
Software Center map files
•
License data
•
Core Client Registry
•
System Identity Account configuration
•
Cisco.com User configuration
•
Proxy User configuration
•
Database. Jobs and Resources data, DCR data, Groups data, and other data stored in the database
•
Discovery settings and scheduled jobs
•
ACS Credentials
•
Local User policy setup
•
System Preferences
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.
•
If the archive is of the current version, then the restore from current version is run.
•
If the backup archive is of an older version, the backup data is converted to Common Services 3.0.5 format, if needed, and applied to the machine.
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 
Restoring the database from a backup permanently replaces your database with the backed up version.
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
•
Restoring Data On Windows
•
Data Restored From Common Services 3.0.x/CS 3.1.x/CS 3.2 Backup Archive
Restoring Data On Solaris
To restore the data on Solaris:
Step 1
Log in as the superuser, and enter the root password.
Step 2
Stop all processes by entering:
Step 3
Restore the database by entering:
/opt/CSCOpx/bin/perl /opt/CSCOpx/bin/restorebackup.pl [-t temporary directory] [-gen generationNumber] [-d backup directory] [-h]
•
[-t temporary directory]—The restore framework uses a temporary directory to extract the content of backup archive.
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
•
[-gen generationNumber]—Optional. By default, it is the latest generation. If generations 1 through 5 exist, then 5 will be the latest.
•
[-d backup directory]—Required. Which backup directory to use.
•
[-h]—Provides help. When used with -d <backup directory> syntax, shows correct syntax along with available suites and generations.
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
Examine the log file in the following location to verify that the database was restored by entering:
/var/adm/CSCOpx/log/restorebackup.log
Step 5
Restart the system:
Restoring Data On Windows
To restore the data on Windows, make sure you have the correct permissions, and do the following:
Step 1
Stop all processes by entering the following at the command line:
net stop crmdmgtd
Step 2
Restore the database by entering:
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 directory
Step 3
Examine the log file in the following location to verify that the database was restored by entering:
NMSROOT\log\restorebackup.log
Step 4
Restart the system by entering:
While 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:
•
CiscoWorks User information
•
Single Sign-on configuration
•
Device and Credential Repository (DCR) configuration
•
Peer certificates
•
Self Signed certificate (based on your confirmation)
•
Peer Server Account information
•
Login Module settings
•
Software Center map files (Will not overwrite existing data)
•
Application and Link registrations
•
Log backup configuration
•
Licence data (Will not be restored. But will compare and display a warning and ask for confirmation to continue, if licenses are different)
•
ACS credentials
•
System Identity Account configuration
•
Cisco.com User configuration
•
Proxy User configuration
•
Database. Jobs data, DCR data, Groups data, and other data stored in the database
•
Discovery settings and scheduled jobs (only from CS 3.1.1/CS 3.2 backup archive)
•
Local User policy setup (only from CS 3.1.1/CS 3.2 backup archive)
•
System preferences
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 
You need to shut down CiscoWorks, change the password and then restart CiscoWorks, for the changes to take effect. Make sure you are not running any critical tasks. Otherwise, you might lose data.
Changing Password on Solaris
To change the password on Solaris:
Step 1
Log in as the superuser, and enter the root password.
Step 2
Stop all processes by entering:
Step 3
Change to the installation directory by entering:
cd NMSROOT/bin
To list the different formats available for changing the database password, enter:
NMSROOT/bin/perl dbpasswd.pl
Step 4
When prompted, enter the new password and verify it by re-entering it.
Step 5
Start all processes by entering:
Changing Password on Windows
To change the password on Windows:
Step 1
At the command line, make sure you have the correct permissions .
Step 2
Stop all processes by entering:
Step 3
Change to the Installation Directory by entering:
cd NMSROOT\bin
To list the different formats available for changing the database password, enter:
NMSROOT\bin\perl dbpasswd.pl
Step 4
When prompted, enter the new password and verify it by re-entering it.
Step 5
Start all processes by entering:
Formats 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:
Format
|
Command
|
Format 1 detects the available datasource names and databases and prompts you to enter and confirm the passwords for each of them.
It also allows you to encrypt the password.
|
On Solaris:
NMSROOT/bin/perl dbpasswd.pl all
On Windows:
NMSROOT\bin\perl dbpasswd.pl all
|
Format 2 allows you to list all the available databases and datasource names (DSNs) available in the server.
|
On Solaris:
NMSROOT/bin/perl dbpasswd.pl listdsn
On Windows:
NMSROOT\bin\perl dbpasswd.pl listdsn
|
Format3 allows you to change the database password.
|
On Solaris:
NMSROOT/bin/perl dbpasswd.pl dsn=odbc_datasource
On Windows:
NMSROOT\bin\perl dbpasswd.pl dsn=odbc_datasource
|
Format 4 allows you to change the database password for a specific DSN.
It also allows you to enter a new password in the command line using the npwd option.
|
On Solaris:
NMSROOT/bin/perl dbpasswd.pl dsn=dsn-name npwd=new-password
On Windows:
NMSROOT\bin\perl dbpasswd.pl dsn=dsn-name npwd=new-password
|
Format 5 allows you to encrypt the existing database password.
|
On Solaris:
NMSROOT/bin/perl dbpasswd.pl dsn=dsn-name encyption=yes
On Windows:
NMSROOT\bin\perl dbpasswd.pl dsn=dsn-name encyption=yes
|
Format 6 allows you to change the database password for a specific DSN.
Format 6.0 also:
• Allows you to enter a new password in the command line using the npwd option.
• Allows you to encrypt the password using the encryption option.
|
On Solaris:
NMSROOT/bin/perl dbpasswd.pl dsn=dsn-name npwd=new-password encryption=yes
On Windows:
NMSROOT\bin\perl dbpasswd.pl dsn=dsn-name npwd=new-password encryption=yes
|
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:
•
Change modes.
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.
•
Change Master/Slave relationships.
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
•
Restoring Data From S1 on S1
•
Restoring Data From S1 to M1
•
Restoring Data From S1 on M2
•
Restoring Data From M1 on M1
•
Restoring Data From M1 to M2
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.
•
For Domain 1, you have M1 as Master, and S1, and S2 as Slaves.
•
For Domain 2, you have M2 as Master, and S3, and S4 as Slaves.
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
Back up data from the slaves, S1 and S2.
Step 2
Backup data from the Master, M1.
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
Stop Daemon Manager on all three machines.
Step 4
Restore data on the Master, M1.
Step 5
Restart Daemon Manager on M1.
Step 6
Restore data on S1, and S2 after the Master is up and stable,
Step 7
Restart Daemon Manager on S1, and S2.
This ensures that Master has more recent data than the Slaves.
Note
To avoid disturbances to the Master- Slave relationship, and to maintain consistency, it is better to take a back up of all machines at the same time.
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:
•
Restore data from a Standalone machine A to another Standalone machine B:
The provider group name will change accordingly. That is, the provider group CS @A will become CS@B.
•
Restore data from a Standalone machine A to a Master M:
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.
•
Restore data from a Standalone machine A to a Slave S:
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
Copy the new license file to the CiscoWorks Server, with read permission for casuser/casusers.
Step 2
Select Common Services > Server> Admin > Licensing.
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
Click Update.
Step 4
Enter the path to the new license file in the License field, or click Browse to locate the new file.
Step 5
Click OK.
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
Go to the CiscoWorks home page and select Common Services > Server > Admin > Licensing.
The License Information page displays the license name, license version, status of the license, and the expiration date of the license.
Step 2
Click Update.
Step 3
Enter the path to the new license file in the License field, or click Browse to locate the new file.
Step 4
Click OK.
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:
•
Status of Common Services grouping server. The status of the grouping server may be running or not running.
•
List of groups created in the Common Services grouping server.
•
Content of the registry and properties files associated with Common Services.
•
Status of grouping server of other applications if they are installed on the same CiscoWorks
Server. The status of the grouping server may be running or not running.
•
List of groups created in the Common Services grouping server.
•
Content of the properties files associated with other applications.
•
Error encountered if the grouping servers are not running or if they are not reachable.
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
Go to the CiscoWorks home page and select Common Services > Server > Admin > Collect Server Information.
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
Click Create to collect the current server information.
The Collect Server Information popup dialog box appears a list of options. The available options are:
•
System Information — Displays the server type, operating system version, installation date of operating system and other system information.
•
Event Logs — Displays the logs of event in the CiscoWorks Server.
•
CiscoWorks Registry — Displays the registry entries of CiscoWorks components installed in the server.
•
Tomcat Log Files — Displays the log files corresponding to the application server.
•
Grouping Service — Displays the information of grouping servers and the groups created in the grouping server.
•
Application Registry Details — Displays the information of applications registered with CiscoWorks home page.
•
Device Credentials Admin Information — Displays the details of DCR mode, status of DCR Master, number of devices in DCR and the contents of DCR configuration files.
•
ODBC Configuration — Displays the information about the configuration of database connection in the CiscoWorks Server.
•
Product Log Files — Displays the contents of log files of all CiscoWorks components.
•
Environment Variables — Displays the list of environmental variables set up in the CiscoWorks Server.
•
Process Status — Displays the name of processes, current state of the process, process ID, start and finish time of the process, and other information.
•
Network Configuration — Displays the information about the various configurations in a network.
•
Memory and Harddrive Status — Displays the details of free space and total space of memory and hard disk drives in the CiscoWorks Server.
•
JRE Registry — Displays the information about the Java Runtime Environment registry files.
Step 3
Select the check boxes corresponding to the options you need.
You can use the All checkbox to select or deselect all the available options.
By default all the check boxes are selected.
Step 4
Click OK.
The server information for the selected components is collected.
To view the collected information:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Admin > Collect Server Information.
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
Click Server Information at the date time link to view the collected server information.
The popup window displays the server information collected.
Step 3
View server information by clicking the corresponding link in the Table of Contents.
To delete the collected server information:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Admin > Collect Server Information.
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
Select the corresponding check box of the server information you want to delete.
Step 3
Click Delete.
Collecting Server Information Using CLI
You can also generate the collect server information using CLI.
Enter the following command:
•
NMSROOT\bin\perl NMSROOT\bin\collect.info (on Windows)
or
•
NMSROOT/bin/perl NMSROOT/bin/collect.info (on Solaris)
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
Select Common Services > Server > Admin > Selftest.
Step 2
Click Create to perform a self test and view the report.
Step 3
Click the Self Test Information at date time link.
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
Select Common Services > Server > Admin > Notify Users.
The Logged in Users dialog box lists all the users currently logged in.
Step 2
Enter the message in the Message field and click Send.
The Status field displays the status of the message.
Note
If you are using Microsoft Internet Explorer, make sure your browser is set to check for updates on every visit to the page.
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
When you are using the ACS login module, the System Identity User you configure should have all the Job management related tasks enabled. The job_browser, job_stop, and, job_delete tasks should be enabled.
To view the list of jobs:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Admin > Job Browser.
The Job Browser page appears with the following details:
Item
|
Description
|
Job ID
|
Unique number assigned to this task at creation time. This number is never reused. There are two formats:
• Job ID:
Identifies the task. This does not maintain a history. For Example:1001
• JobID.Instance ID:
Here, in addition to the task, the instance of the task can also be identified. For example:
|
Type
|
String that identifies the job type (SWIM, Config, etc) and job subtypes. For example, SWIM:update.
|
Run Status
|
Job states including:
• Running
• Removed
• Waiting for approval
• Scheduled (pending)
• Rescheduled
• Completed succeeded
• Failed
• Crashed
• Cancelled
• Rejected
• ERROR.
The start time, and end time of the task are also shown.
|
Sched Type
|
Frequency of the job. This can be:
• Run immediately.
• Run once.
• Run on a calendar basis (periodic).
• Run on a time-start basis.
• Run on a time-stop basis.
For time zone abbreviations and GMT offsets, see the Release Notes.
|
Description
|
Text string that describes the job.
|
Run Sched
|
Schedule details of the job.
|
Status
|
Current status of the job.
|
Owner
|
Name of the user who scheduled the job.
|
Scheduled At
|
Date and time the job was scheduled.
|
Completed At
|
Date and time the job was completed.
|
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
Go to the CiscoWorks home page and select Common Services > Server > Admin > Job Browser.
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
Select a job and click the link provided for Job ID.
The Job Details popup displays the job details.
To stop a Job:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Admin > Job Browser.
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
Select the check box corresponding to the Job you want to stop.
Step 3
Click Stop.
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
When you are using the ACS login module, the System Identity user must configure all the Resource management related tasks. The resource_browser and free_resource tasks should be enabled.
To view Resource details:
Step 1
Go to the CiscoWorks home page and select Common Services > Server > Admin > Resource Browser.
The Resource Browser page displays the following details:
Item
|
Description
|
Resource
|
Name of the resource currently locked.
|
Job ID / Owner
|
Number assigned to this task at creation time. Identifies all related locked resources, and user who locked the resource.
|
Time Locked
|
Time this lock was established.
|
Expire Time
|
Lock expiration time.
|
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
Go to the CiscoWorks home page and select Common Services > Server > Admin > Resource Browser.
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
Check the check box corresponding to the Job ID.
Step 3
Click Free Resources.
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:
•
Daemon Manager
•
Web server log files
Most log files are located in directories in the following locations:
•