OneClick. Administration Guide. Document 5166

Transcription

1

2 Notice Copyright Notice Copyright 2004-present by Aprisma Management Technologies, Inc. All rights reserved worldwide. Use, duplication, or disclosure by the United States government is subject to the restrictions set forth in DFARS (c)(1)(ii) and FAR Liability Disclaimer Aprisma Management Technologies, Inc. ( Aprisma ) reserves the right to make changes in specifications and other information contained in this document without prior notice. In all cases, the reader should contact Aprisma to inquire if any changes have been made. The hardware, firmware, or software described in this manual is subject to change without notice. IN NO EVENT SHALL APRISMA, ITS EMPLOYEES, OFFICERS, DIRECTORS, AGENTS, OR AFFILIATES BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS) ARISING OUT OF OR RELATED TO THIS MANUAL OR THE INFORMATION CONTAINED IN IT, EVEN IF APRISMA HAS BEEN ADVISED OF, HAS KNOWN, OR SHOULD HAVE KNOWN, THE POSSIBILITY OF SUCH DAMAGES. Trademark, Service Mark, and Logo Information SPECTRUM, IMT, and the SPECTRUM IMT/VNM logo are registered trademarks of Aprisma Management Technologies, Inc., or its affiliates. APRISMA, APRISMA MANAGEMENT TECHNOLOGIES, the APRISMA MANAGEMENT TECHNOLOGIES logo, MANAGE WHAT MATTERS, DCM, VNM, SpectroGRAPH, SpectroSERVER, Inductive Modeling Technology, Device Communications Manager, SPECTRUM Security Manager, and Virtual Network Machine are unregistered trademarks of Aprisma Management Technologies, Inc., or its affiliates. For a complete list of Aprisma trademarks, service marks, and trade names, go to: All referenced trademarks, service marks, and trade names identified in this document, whether registered or unregistered, are the intellectual property of their respective owners. No rights are granted by Aprisma Management Technologies, Inc., to use such marks, whether by implication, estoppel, or otherwise. If you have comments or concerns about trademark or copyright references, please send an to spectrum-docs@aprisma.com; we will do our best to help. Restricted Rights Notice (Applicable to licenses to the United States government only.) This software and/or user documentation is/are provided with RESTRICTED AND LIMITED RIGHTS. Use, duplication, or disclosure by the government is subject to restrictions as set forth in FAR (June 1987) Alternate III(g)(3) (June 1987), FAR (June 1987), or DFARS (c)(1)(ii) (June 1988), and/or in similar or successor clauses in the FAR or DFARS, or in the DOD or NASA FAR Supplement, as applicable. Contractor/manufacturer is Aprisma Management Technologies, Inc. In the event the government seeks to obtain the software pursuant to standard commercial practice, this software agreement, instead of the noted regulatory clauses, shall control the terms of the government's license. Virus Disclaimer Aprisma makes no representations or warranties to the effect that the licensed software is virus-free. Aprisma has tested its software with current virus-checking technologies. However, because no antivirus system is 100-percent effective, we strongly recommend that you write protect the licensed software and verify (with an antivirus system with which you have confidence) that the licensed software, prior to installation, is virus-free. Contact Information Aprisma Management Technologies, Inc., 273 Corporate Drive, Portsmouth, NH USA Phone: U.S. toll-free: Web site: Page 2

3 Contents Notice... 2 Preface... 6 What is in this book... 6 Text Conventions... 7 SPECTRUM Documentation Set... 8 Document Feedback... 9 Contacting Concord Communications... 9 Chapter 1: Welcome to the Commonly-used SPECTRUM terms...11 Chapter 2: SPECTRUM Web Server Administration Configuring and Secure Sockets Layer...12 Request an SSL Certificate...13 Import the Signed SSL Certificate...14 Configure the Web Server...14 Configuring to Communicate through a Web Proxy Server...15 Configuring Web Server to Communicate with SpectroSERVER(s) in Firewall Environments...17 Web Server Fault Tolerance...18 Fault Tolerant Environment Assumptions...19 Installation and Configuration Considerations...19 Router/Load Balancer...21 Tested Environment and Failure Scenarios...23 SRM and Crystal Reports...24 SRM Fail-Over Architecture...27 SRM Manual Fail-Over Configuration and Procedure...27 Script Descriptions...28 Caveats...29 Service Manager...30 Page 3

4 Stopping and Starting the Web Server...30 Supporting Over 100 Users per Server...31 Launching Clients with Context...31 Adjusting Client Memory Settings...32 Chapter 3: SPECTRUM Security and User Management in. 34 What is Security in SPECTRUM?...34 How is Security Implemented in?...35 SPECTRUM Security Terminology...35 Understanding SPECTRUM Security Concepts...36 Understanding User Management in...36 What are Licenses?...36 What are Access Groups?...37 What are Roles?...38 What are Security Strings?...39 Understanding Legacy SPECTRUM Security in...39 Getting Started with Security...39 Planning Security in...39 Accessing Security and User Management Features...40 Users Tab...42 Contents: Users List Tab...43 Contents: Access Tab...46 Configuring SPECTRUM Security in...48 Managing Licenses by Limiting Concurrent User Logins...48 Managing Users in...53 Create a New User...53 Edit an Existing User...55 Managing User Groups in...56 Creating User Groups in...56 Creating A User Within a Group...62 Add an Existing User (Move) to a User Group...64 Remove a User from a User Group...65 Page 4

5 Editing and Deleting Users and User Groups...66 Creating and Assigning Roles to Users or User Groups...69 Granting All Privileges to an Existing User with Super User...71 Using Security Strings to Secure Modeled Elements...73 Setting Preferences for Users and Groups...79 Appendix A: Troubleshooting Web Server Issues Export Fails Due to Java Memory Resources Setting...86 Troubleshooting in Fault Tolerant Environments...86 Appendix B: System Customizations Server.xml Customization Parameters...88 Web.xml Customization Parameters...89 Index Page 5

6 Preface This guide is intended for Administrators responsible for managing Web server(s) and users. It provides administration information in a task-based format that can be employed as a personal reference guide or as part of a training materials package. In This Section What is in this book [page 6] Text Conventions [page 7] SPECTRUM Documentation Set [page 8] Document Feedback [page 9] Contacting Concord Communications [page 9] What is in this book This guide contains the following chapters: Chapter 2: SPECTRUM Web Server Administration [page 12] Chapter 3: SPECTRUM Security and User Management in [page 34] Appendix A: Troubleshooting Web Server Issues [page 86] Appendix B: System Customizations [page 88] Page 6

7 Text Conventions The following text conventions are used in this document: Element Convention Used Example Variables (The user supplies a value for the variable.) The directory where you installed SPECTRUM (The user supplies a value for the variable.) Courier and Italic in angle brackets (<>) <$SPECROOT> Type the following: DISPLAY=<workstation name>:0.0 export display Navigate to: <$SPECROOT>/app-defaults Solaris and Windows directory paths Unless otherwise noted, directory paths are common to both operating systems, with the exception that slashes (/) should be used in Solaris paths, and backslashes (\) should be used in Windows paths. <$SPECROOT>/app-defaults on Solaris is equivalent to <$SPECROOT>\app-defaults on Windows. On-screen text Courier The following line displays: path= /audit User-typed text Courier Type the following path name: C:\ABC\lib\db Cross-references References to SPECTRUM documents (title and number) Underlined and hypertextblue Italic See Document Feedback [page 9]. Console User Guide (5130) Page 7

8 SPECTRUM Documentation Set The SPECTRUM documentation set is available online at: Use this site to download the latest documentation updates and additions. To login into the Documentation site, you must supply your contract number and license number. The following tables outline the books you can expect to find in the SPECTRUM documentation set: SPECTRUM core documentation Title Description Installation Guide (5142) This guide walks you through the steps for installing and setting up SPECTRUM SpectroSERVERs. (5166) Console User Guide Modeling Your IT Infrastructure This guide includes information about Security, User administration, Security string concepts and how to configure SPECTRUM to work with Web Proxy Servers and firewell environments. This guide introduces you to the basic features provided in the SPECTRUM working environment. This guide describes ways in which you can define and maintain models of your infrastructure in the environment. It covers Discovery, manual modeling, and modeling tools used to enhance models. SPECTRUM add-on functionality documentation iagent User Guide MPLS Manager User Guide Multicast Manager User Guide Report Manager User Guide Report Gateway User Guide Service Manager User Guide Service Performance Manager User Guide Page 8

9 SPECTRUM add-on functionality documentation SPECTRUM Alarm Notification Manager User Guide SPECTRUM Configuration Manager User Guide SPECTRUM SNMPv3 User Guide QOS Manager User Guide VLAN Manager User Guide SPECTRUM Customization User Guide SPECTRUM add-on module documentation ATM Circuit Manager User Guide Frame Relay Manager User Guide VPN Management User Guide Other device management user guides Document Feedback Please send feedback regarding SPECTRUM documents to the following address: Thank you for helping us improve our documentation. Contacting Concord Communications Contact information for Concord Communications is available at: Contact information for Concord SPECTRUM Business Unit is available at: Page 9

10 Chapter 1: Welcome to the The SPECTRUM product suite designed by Concord Communications is an entirely new framework that houses and integrates all SPECTRUM network management features (core and add-on management). The SPECTRUM identifies server and client administration concepts and procedures. These administration topics are presented in the following chapters: SPECTRUM Web Server Administration. This chapter is most helpful following the installation of SPECTRUM. It discusses tasks the administrator can perform to optimize and configure server. These tasks include configuring SPECTRUM with Secure Sockets Layer, web proxy servers, and fire-walled environments. Other server and client-related maintenance and configuration issues are also addressed. For more information see Chapter 2: SPECTRUM Web Server Administration [page 12]. SPECTRUM Security and User Management in. This chapter instructs administrators how to implement SPECTRUM security in the environment. This includes a discussion of basic SPECTRUM security concepts as well as the more advanced tasks that must be performed to implement user and network security. For more information see Chapter 3: SPECTRUM Security and User Management in [page 34]. Troubleshooting Web Server Issues. Appendix A identifies problems and error messages that may be generated during the operation of the web server and includes corrective action where feasible. For more information see Appendix A: Troubleshooting Web Server Issues [page 86]. System Customizations. Appendix B discusses parameters to edit in certain XML configuration files on the web server to customize the server and client environment. For more information see Appendix B: System Customizations [page 88]. Page 10

11 Commonly-used SPECTRUM terms The following table identifies commonly-used SPECTRUM terms that you should be familiar with prior to reading the chapters in this guide. Table 1: Commonly-used SPECTRUM terms Landscape SpectroSERVER Distributed SpectroSERVER (DSS) Environment web server client licenses The Landscape is the network domain managed by a single SpectroSERVER. The SpectroSERVER is the server responsible for providing network management services such as polling, trap management, notification, data collection, fault management, etc. Also referred to as the Virtual Network Machine (VNM). A Distributed SpectroSERVER (DSS) environment consists of more than one SpectroSERVER. This environment enables management of a large-scale infrastructure. The SpectroSERVERs in this environment may be located within a single physical location or multiple physical locations. The web server is the server responsible for moving data between the SpectroSERVER(s) and clients. The client is a Java JNLP application which provides network operators with a view into the details and health of the network. A pool of licenses (based on the actual number of administrator, operator, etc. licenses) available to assign to users. Licenses are allocated when clients are launched. Licenses determine which privileges are available. Page 11

12 Chapter 2: SPECTRUM Web Server Administration This section identifies administrative tasks. Other maintenance and optional configuration issues are also addressed. In This Section Configuring and Secure Sockets Layer [page 12] Configuring to Communicate through a Web Proxy Server [page 15] Configuring Web Server to Communicate with SpectroSERVER(s) in Firewall Environments [page 17] Web Server Fault Tolerance [page 18] Stopping and Starting the Web Server [page 30] Supporting Over 100 Users per Server [page 31] Launching Clients with Context [page 31] Adjusting Client Memory Settings [page 32] Configuring and Secure Sockets Layer SPECTRUM supports the use of Secure Sockets Layer (SSL) to encrypt communications between the Web Server and client(s). This lets clients access information securely across unsecured networks such as the Internet. In addition to encryption, SSL uses certificates for authentication. Authentication protects users from downloading and running applications from suspicious or un-trusted sources. Note: Previous SPECTRUM web-based applications (Web Operator) allowed self-signed certificates. However, the application base that was built upon does not support self-signed certificates. As a Java Network Launch Protocol (JNLP) application, Console currently requires that a certificate be generated and signed by a Page 12

13 Certificate Authority (CA) such as Verisign or Thawte. Such a certificate must be installed for use by the Web Server in order to use SSL. WARNING! If a signed certificate is not installed for use by the Web Server, selecting Start Console after launching using <hostname>/spectrum will result in the Java application being downloaded and the certificate acknowledgement being presented, but the application will fail to launch with this error: Fatal Error. Unable to open page <hostname>/spectrum/ You can go to or to obtain a secure certificate. Instructions are available at each company s web site. Request an SSL Certificate [page 13] Import the Signed SSL Certificate [page 14] Configure the Web Server [page 14] Request an SSL Certificate You will need a Certificate Signing Request (CSR) from the system that will be running the Web Server. JDK 1.4.1, included with, provides a keytool utility you can use to generate the key. Procedure 1. Generate a private key with the following command specifying the path to your Java installation area: $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA -keystore /path/to/domainname.kdb You will be prompted for a password. Tomcat uses a default password of changeit. If you use a different password, you will need to specify a custom password in the server.xml (<Install Area>/WebApps/ tomcat/conf/) configuration file. The next field that you will be prompted for is "What is your first and last name?" at this prompt, you must specify the common name (FQDN) of your web site (e.g. You will then be prompted for your organizational unit, organization, etc. 2. Generate the Certificate Signing Request (CSR) with the following command specifying the path to your java installation area: Page 13

14 $JAVA_HOME/bin/keytool -certreq -alias tomcat -keystore /path/to/keystore.kdb -file filename.csr You will not be prompted for the common name, organization, etc. information; the keytool will use the values that you specify when generating the private key. Import the Signed SSL Certificate Now that you have your Certificate you can import it into your local keystore. First you must import a Chain Certificate or Root Certificate into your keystore. After that you can proceed with importing your Certificate. Procedure 1. Download a Chain Certificate from the Certificate Authority you obtained the Certificate from. For Verisign.com go to: For Trustcenter.de go to: For Thawte.com go to: 2. Import the Chain Certificate into your keystore with the following command: $JAVA_HOME/bin/keytool -import -alias root -keystore <your_keystore_filename> -trustcacerts -file <filename_of_the_chain_certificate> 3. Finally, import your new Certificate with the following command: $JAVA_HOME/bin/keytool -import -alias tomcat -keystore <your_keystore_filename> -trustcacerts -file <your_certificate_filename> Configure the Web Server The final step is to configure your secure socket in the <Install Area>/ WebApps/tomcat/conf/server.xml file. An example <Connector> element for an SSL connector is included in the default server.xml file installed with Tomcat. It will look like this: <-- Define an SSL HTTP/1.1 Connector on port > Page 14

15 <!-- <Connector classname="org.apache.catalina.connector.http.httpconnector" port="8443" minprocessors="5" maxprocessors="75" enablelookups="true" acceptcount="10" debug="0" scheme="https" secure="true"> <Factory classname="org.apache.catalina.net.sslserversocketfactory" clientauth="false" protocol="tls" keystorefile="<path_to_your_keystore_filename>" keystorepass="<password>"/> </Connector>--> By default the <Connector> element is commented out. In this section you will need to remove the comments around the Connector definition ("<!--" in the beginning and at the end after </Connector> "-->"). In addition you may want to change port="8443" to port 443 which is the default connector port for HTTPS. Users will then not have to include the specific port number in the URL (i.e. when launching. You will need to stop and then restart the web server (see Stopping and Starting the Web Server [page 30]. Additional details on the above steps and documentation for additional configuration parameters are available on the web server at Configuring to Communicate through a Web Proxy Server If you use a Web proxy server that relays HTTP and HTTPS requests (such as the iplanet and Microsoft proxy servers), honors the proxy settings used by Java WebStart and supports both HTTP and HTTPS proxies as well as proxy authentication. An administrator must configure the Web server to communicate through a proxy server. Page 15

16 Important: All clients connecting through a proxy must configure the proxy settings in the Java WebStart preference console. See the Installation Guide (5142) for details about the Java WebStart proxy settings. Setting this may be the only change required if you are connecting through an HTTP 1.1 proxy. To configure the Web server for HTTP 1.0 proxy support, follow this procedure: Note: The following changes are not necessary to connect to a proxy that supports HTTP Open the following file for edit: <Install Area>/SPECTRUM/WebApps/tomcat/conf/server.xml 2. Find the attribute maxkeepaliverequests="-1" and change it to maxkeepaliverequests="1" Setting this to 1 turns off keep-alive. Note: Directions to do this also appear in the server.xml file itself. 3. Save the server.xml file changes. 4. Open the following file for edit: <Install Area>/SPECTRUM/WebApps/tomcat/webapps/spectrum/ oneclick.jnlp 5. Find the following three lines and remove the lines containing <!-- and -->: <!-- <property name="reuseconnections" value="false"/> --> Uncommenting the <property name="reuseconnections" value="false"/> line in this file turns off the reuse of connections. 6. Stop and restart the Web server (see Stopping and Starting the Web Server [page 30]). Troubleshooting Proxy Issues: A failed attempt to launch a client with a proxy results in the normal conditions described in step 1 and step 2 and the failure in step 3 (below): Page 16

17 1. A Web browser can access the Web server and load the main page at (through the proxy). 2. Java WebStart can access the Web server and download the needed files. 3. The client cannot access the Web server and fails with a Can't connect to... error. Note: See the Installation Guide (5142) for information about disabling Web proxies if the procedures in Configuring to Communicate through a Web Proxy Server [page 15] do not allow to communicate through the particular proxy server in your environment. Configuring Web Server to Communicate with SpectroSERVER(s) in Firewall Environments Some users have been unable to establish communication between the Web Server and the SpectroSERVER(s) when a firewall is between the systems and that firewall has been configured to only allow access to TCP ports as described in the Distributed SpectroSERVER Guide. This occurs due to the fact that the SpectroSERVER will open up additional TCP connections to the Web Server in order to deliver informational updates to. Those TCP connections may use any available TCP port above 1024 (non-privileged ports). When starting the Console, the SpectroSERVER will be visible in the Navigation Panel, but the Connection Status will have a state of Incomplete (Orange). When opening the Connection Status window you will see the following error message: "The web server was able to establish a connection to the server, but the server could not connect back to the web server host. Some data retrieval may have failed and the server will not be able to send updates to the web server. Some possible causes are: 1) There are multiple network interfaces on the web server host. 2) A firewall is blocking connections to the web server host. After the problem is rectified, restart the web server." Page 17

18 Solution For Spectrum version 7.0 and higher, you can set the callback port on the Web Server to be a specific, fixed port and then open only that port through the firewall. The configuration is as follows: 1. On the Web Server host system, edit the $ONECLICK/ WebApps/tomcat/conf/server.xml file. Search for the orbargs parameter and add an entry for the specific callback port: <parameter> <name>orbargs</name> <value>oaport=14007 ORBgcTimeout=300 ORBconnectionMaxIdle=0 </value> </parameter> Note: The OAport=14007 text must be added to whatever the existing <value> </value> section contains. Aprisma recommends the use of port to be consistent with the pattern of the currently defined ports ( ). Aprisma is currently reserving port for future use. 2. In addition to allowing communications to ports , configure the firewall to also allow connections from the SpectroSERVER host to port (TCP) on the Web Server host. This configuration must allow for bi-directional communication back to the SpectroSERVER over the established connection. 3. Restart the web server (see Stopping and Starting the Web Server [page 30]). Web Server Fault Tolerance This section describes both basic fault tolerance as well as considerations for SPECTRUM Report Manager (SRM) and Service Level Manager (SLM). It includes the procedures necessary to configure the environment as well as any caveats. To achieve session Fault Tolerance, Aprisma recommends that a router/ load balancer be placed in front of the two web servers to direct traffic to the primary server first, then re-direct the traffic to the secondary server in the event of a primary sever failure. Page 18

19 Note: This is not true 'Round Robin' load balancing of the servers; rather, the load balancer is used in a primary-with-backup mode to provide fail-over capabilities. A load balancing network device may be required to achieve load balancing, if desired. These examples used a Riverstone RS-3000 device. Fault Tolerant Environment Assumptions [page 19] Installation and Configuration Considerations [page 19] Router/Load Balancer [page 21] Tested Environment and Failure Scenarios [page 23] SRM and Crystal Reports [page 24] SRM Fail-Over Architecture [page 27] SRM Manual Fail-Over Configuration and Procedure [page 27] Script Descriptions [page 28] Caveats [page 29] Service Manager [page 30] Fault Tolerant Environment Assumptions SPECTRUM Fault Tolerance requires at least one fault tolerant pair of SpectroSERVERs to be running. The SpectroSERVER pair(s) do not necessarily reside in the same LAN as the Web servers. The Web servers have been installed with Crystal Reports (required for SRM) and optionally, SLM has been installed. Note: SRM does not currently support the Solaris platform and thus any install running SRM must be on a Windows server. Furthermore, SLM historical reporting is not currently supported in Fault Tolerant mode, although it is possible to view realtime Service Alerts via the fail-over console. Installation and Configuration Considerations 1. Complete the installation of with SRM on two Windows servers (Primary and Secondary ). Page 19

20 During the install of, you will be prompted to specify both a primary and backup location server. During each instance of the install, you must always specify the primary SpectroSERVER first. For a Fault Tolerant pair, this is just the one entry because the secondary takes over as the primary location server, thus advertising as a single server. 2. Create agentaddr files on both Web servers in the fault tolerant environment as well as on all SpectroSERVERs to which they will connect. It is recommended that the order in which IP addresses are listed in the agentaddr files represent the order in which the server will communicate with them. For example, list the primary location server, then the backup location server, etc. For more information about the agentaddr file, see the Configuring SPECTRUM CORBA Services section of the SPECTRUM Installation Guide. Important: SPECTRUM components such as SRM and the Events tab depend on being able to contact the SPECTRUM Archive Manager. Fault Tolerant SpectroSERVER environments share an Archive Manager which must be specified by the agentaddr file for fail-over to work properly. a. Solaris: This file must be created in the <$SPECROOT>/bin/VBOA/ directory (this is not necessary for SRM servers as these will be on Windows machines). b. Windows: Aprisma recommends placing the file in the following directory: C:/win32app/SPECTRUM/webApps/tomcat/conf c. To ensure that the server is able to point to the file, you must edit the C:/win32app/SPECTRUM/webApps/tomcat/conf/ server.xml file as follows: - Search for the string orbargs - This will take you to <name>orbargs</name> - Add the path where the agentaddr file exists under <value> on the same line as the other configuration parameters, i.e. <value>orbgctimeout=300 ORBconnectionMaxIdle=0 ORBagentAddrFile=C:/win32app/SPECTRUM/webApps/tomcat /conf </value> If you have placed the agentaddr file elsewhere on your system, ensure that the value of ORBagentAddrFile= reflects the correct path. Page 20

21 This will ensure that the server is able to talk to the next available Location Server in the agentaddr list in the event of a primary server failure. d. Ensure that the.hostrc file on each SpectroSERVER is configured to allow both of the Web servers to connect. See the Host Resource Configuration File (.hostrc) section of the Distributed SpectroSERVER (2770) guide for more information. Summary of Access Files Required - Each SpectroSERVER (primaries and secondaries) in the Fault Tolerant environment must specify all other SpectroSERVERs it needs to reach in its agentaddr file. - Each SpectroSERVER (primaries and secondaries) in the Fault Tolerant environment must specify all other SpectroSERVERs and both the primary and secondary Web servers it needs to reach in its.hostrc file. - Both Web servers (primary and secondary) in the Fault Tolerant environment must specify all the SpectroSERVERs it needs to reach in its agentaddr file. Router/Load Balancer 1. Configure a virtual IP address to represent an inbound default route to both the Web servers. 2. Fail-over requires that the router be configured to primarily direct IP traffic to the primary server, then direct to the virtual address and to the secondary in the event of failure. This is the configuration from the Riverstone 3000 router running software v used in our example: load-balance create group-name persistence-level tcp virtual-ip virtual-port 80 protocol tcp load-balance add host-to-group group-name port 80 load-balance add host-to-group group-name port 80 status backup load-balance set aging-for-src-maps aging-time 1 // load-balance allow access-to-servers client-ip group-name Page 21

22 // load-balance allow access-to-servers client-ip group-name! Note: Notice the persistence-level tcp and status backup settings in the example configuration file above. The persistence-level tcp setting provides session persistence for clients. The status backup setting must be used to designate the secondary Web server. Page 22

23 Tested Environment and Failure Scenarios The following scenarios have been tested and shown to provide client availability. Figure 1: Tested Environment Virtual IP Group Traffic to primary Web server Traffic to secondary after fail-over Complete Server Failure 1. Start a session from your browser ensuring that the resolved name for the virtual address is used as opposed to either the primary or secondary server names, as follows: a. Primary server name: lb1 ( ) b. Secondary server name: lb2 ( ) c. Virtual Address: ( ) Page 23

24 2. Enter Web Sever>/spectrum/index.jsp in your browser. This will start an actual session on lb1. 3. Take down the primary server lb1 and observe your screen. Connectivity will temporarily be lost but will almost instantaneously become active as the router (Riverstone RS-3000 in Figure 1) redirects the traffic to the secondary server lb2. Tomcat Server Failure 1. Ensure all devices and services are active. 2. Start a session as in step 2 above ( Web Sever>/spectrum/index.jsp). 3. Stop the Tomcat Server. 4. The traffic re-direction process will occur as it did in step 3 in the previous scenario. SRM and Crystal Reports Important: In environments in which SPECTRUM Report Manager is configured, only a cold standby solution for fault tolerance is currently available. This is primarily because of restrictions imposed by the Crystal Reports Database, as described below. Database Background There are two databases utilized within the SRM solution. The first is the Crystal Management Server (CMS) database which maintains the Crystal user accounts and any scheduled or customized reports created by users. This is configured as a Microsoft SQL database. It also holds links to any previously generated Asset or Availability reports; however these are stored as files on the server. The second is a data repository, also a Microsoft SQL Database, which contains the event/alarm information for availability metrics as well as Asset information pulled from the SpectroSERVER(s). Workflow When the Web Server is first started after installation, SRM will go to the SpectroSERVER's Model catalog and obtain all of the device information (only selected info such as Device Type, IP Address, etc. and not the full model database) and populate the SQL repository. After that, polling occurs to look for changes in the topology (e.g. firmware revisions, interface changes etc.) over a 24 hour period. This polling is staggered in Page 24

25 order to reduce the load on the SpectroSERVER and Web servers respectively. Any updates to the Model catalog on the SpectroSERVER such as 'Destroys' or 'Creates' will also be pushed to the SRM SQL repository. For Event/Alarm information, the Repository database listens for updates from the Archive Manager database on the SpectroSERVER. These will be generated when Archive Manager has 'interesting' events such as 'Contact Lost' or 'Maintenance Mode' for example. The primary and secondary Repository databases will listen for event/ alarm updates independently and simultaneously, thus replicating the data. In the event of a primary server failure, the secondary will therefore continue to listen for this information from the SpectroSERVER. In the case of either the primary or secondary Web servers being restarted, they will each go to the Archive Manager and read in all the event data since the last time that they went down and as a result will update their own SQL database to reflect this. The primary when it restarts will only read new models created since it was last active by comparing its own database and the Model Handles on the SPECTROSERVER. This ensures that the SQL databases never lose any availability/outage information, along with keeping a complete record of all asset changes within the defined topology. Important: The load on the SpectroSERVER generated by the SQL database polling is literally doubled in this scenario. SpectroSERVER Fail-Over When a server communicates with a Fault Tolerant SpectroSERVER pair, it connects to a single Landscape. If a SpectroSERVER fail-over occurs, the Archive manager will not be available to either of the Web servers due to the nature of that process (see the Fault Tolerance section of the Distributed SpectroSERVER guide) and will therefore not receive any Event information. This will occur until the primary SpectroSERVER comes back up and has read in all the cached Event and statistical data that has been cached on the secondary SpectroSERVER. The asset information however will still be available to the SRM process as it communicates with one Landscape only and will still be available for polling. Issue In the fault tolerant environment defined here (see SRM Fail-Over Architecture [page 27]), any changes to the CMS database (user accounts, Page 25

26 newly scheduled reports, etc.) will only be updated on the primary server when both Web servers are up and running because the virtual address will always direct traffic to the primary server. To resolve this, both CMS's would have to be synchronized. As previously stated, in the event of a primary failure, the secondary server will continue to gather event and asset information and will be able to generate reports based on this data. However, given the fact that the CMS's are not in sync, the secondary server may not hold a user account or a scheduled report that was previously created on the primary and will therefore not be able to perform the required function. Solution Crystal offers a solution whereby it is possible to create CMS clusters across several machines (two in our scenario). However, the caveat to this is that each server in the cluster MUST be in the same LAN/Subnet and consequently they cannot be configured with a router separating the LAN's. This is an issue if the Web servers are in separate subnets and during tests it was found that this method was not suitable to our purposes. As a result, a cold standby solution was created which requires manual intervention in the event of a primary server failure. Note: This is only required for Report Manager installations and not for session Fault Tolerance. Page 26

27 SRM Fail-Over Architecture Figure 2: SRM Fail-Over Architecture Server lb1 Server lb2 SRM Manual Fail-Over Configuration and Procedure This solution creates a back up of the CMS database on the primary and copies it across to the secondary on a regular basis. If the primary server becomes unavailable, the manual startup of the services required for the Crystal Database has been automated using a script. This startup script will restore the database and start the Crystal processes in the correct order to ensure that reporting is available. Page 27

28 Configuration 1. On the primary (lb1 in our example), share C:\Program Files\ Crystal Decisions\Enterprise 10 as Enterprise 10 (Use NT authentication to restrict this if required). 2. Copy the four script files available in FT_Failover_Scripts.zip to C:\Program Files\Crystal Decisions\Enterprise 10 on the secondary server (See Script Descriptions [page 28] for full descriptions of script functionality). 3. On the secondary (lb2) run "DeactivateSecondary.bat lb1" (DeactivateSecondary <primary server name>). This schedules CopyCrystal.bat to run hourly and modifies the crystal services to manual start (so they do not automatically restart at reboot). The servers are now ready and in the correct fault tolerant mode, i.e. the secondary Crystal Processes have been shut down and the CMS database and files are being copied on a regular basis from the primary to the secondary. Primary Failure 1. When the primary fails, run the ActivateSecondary.bat [page 29] script on the secondary server as follows: ActivateSecondary.bat <primary server name> <secondary server name> <crystal administrator user name> <crystal administrator password>. 2. After this script completes, reports can be run against the secondary. Primary Restored 1. When the primary server is back up, run "DeactivateSecondary.bat lb1" (DeactivateSecondary.bat<primary server name>) on the secondary server to set the server as a fail-over. Script Descriptions CopyCrystal.bat This is the batch script to copy the Crystal CMS. It requires a single argument of the primary server from which to copy the CMS database and assumes that the primary has the directory C:\Program Files\Crystal Decisions\Enterprise 10 shared as "Enterprise 10" (the default share name). This file assumes that the Microsoft SQL Server administrator username/password is sa/sa. This should be modified to reflect the actual Page 28

29 password chosen during the Crystal install. This batch file will be scheduled to transfer hourly via the DeactivateSecondary.bat DeactivateSecondary.bat This script stops all Crystal services and sets them to manual start so that if the machine is rebooted the Crystal services do not restart. It then schedules the CopyCrystal.bat file to transfer the CMS database to the secondary hourly. It takes as an argument the name of the primary server. This should be run after the secondary is installed and every time the primary becomes active. It must be run as a user who has permission to write to the "Enterprise 10" share on the primary. The user must supply the Windows Administrator password when prompted by the system (when CopyCrystal.bat is scheduled). ActivateSecondary.bat This script takes as arguments the name of the primary and secondary crystal server machines and the crystal administrator name (should be Administrator) and password. This batch file starts the CMS and copies the CMS database backed up from the primary over the CMS database on the secondary. The DisableServers java app is then used to disable the primary in the CMS, the CMS is restarted, and all other crystal services are started. The DisableServers java app is then used to enable all services on the secondary and all services are restarted. This batch file should be run when the primary is unavailable. When the primary becomes available, DeactivateSecondary.bat above should be run. Caveats It is important to bear in mind that any reports created on the primary since the last successful copy and restore onto the secondary, could potentially be lost in the event of a fail-over. This is because the secondary will only be able to restore from the last saved database. It is therefore recommended to perform this backup on a regular basis, dependant on the size of the database and the time it takes to copy the data. Any scheduled reports that were created on the secondary server while the primary was down will not be reflected in the primary's database when it is restarted. These would have to be re-created. Page 29

30 Service Manager Database Background When Service Manager is configured on the Web servers, it also writes service availability information to the aforementioned SQL Repository Database. That said, the data is written to a different table and is not currently referenced by the SRM tool. Workflow All Service Manager Configurations reside within the SpectroSERVER but are accessed via the server. Service outages etc. are presented only from the console and can also be seen in real-time from the Service Dashboard. As these proprietary service alarms occur, they are pushed out of Archive Manager and are logged into the SQL database for historical reporting. Issue While both Web servers are listening for service alerts from the SpectroSERVER and the primary fails, the secondary will continue to log the data. When the primary is restarted however, there is no current way to update it with the historical service alarm data that the secondary has collected in the meantime. In this scenario, no suitable Fault Tolerant solution is currently available. Stopping and Starting the Web Server Solaris As root: 1. shell> /etc/init.d/wotomcat stop 2. shell> /etc/init.d/wotomcat start Windows 1. C:\> net stop spectrumtomcat 2. C:\> net start spectrumtomcat Page 30

31 Supporting Over 100 Users per Server Solaris To support a large number of users on a single Solaris server, increase the hard limit on the number of file descriptors. Aprisma recommends that you do this to support more than 100 users. Procedure 1. Make a backup of your /etc/system file. 2. Add this line to your /etc/system file: set rlim_fd_max=4096 Launching Clients with Context You may want to launch clients within the context of a certain topology or model. This can be done by passing contextual parameters and values with the URL that launches. The URL can include parameters in the following form: The available parameters and examples of their use are described below. topology The value of the topology parameter can be a model handle or an IP address. Using this parameter in a URL launches a client or reuses an existing one, selects the Explorer tab if not already selected, expands the tree to show the model, selects the Topology tab if not already selected, and selects in the Topology panel the model specified by the topology parameter in the URL. Examples: explorer The value of the explorer parameter can be a model handle or an IP address. Using this parameter in a URL launches a client or reuses an existing one, selects the Explorer tab if not already selected, and expands the tree to show the model. The currently selected tab in the Contents panel will reflect the new model. Page 31

32 Examples: alarm The value of the alarm parameter can be either the integer alarm ID (to facilitate integration with legacy applications), the complete global alarm ID (in the form 3f983d3d b-000bdb5a1c31), or <model ID>. Using this parameter in a URL launches a client or reuses an existing one, selects the Explorer tab if not already selected, expands the tree to show the model, selects the Alarms tab if not already selected, and selects the alarm. Examples: where 0x d@7710 is <modelhandle>@<alarm ID>. where 7710 is the integer <alarm ID>. If passing the integer alarm ID, it is best to also pass the model handle because the integer alarm ID is not guaranteed to be unique across SpectroSERVERs. The full global alarm ID is preferable as it is unique across SpectroSERVERs but it may not be available to the application launching. Note: When launching in context, a new instance of will not be launched if an instance is already running on the host machine. The context will be changed in the current instance of. Adjusting Client Memory Settings By default, the initial memory foot print of clients is 64 megabytes, with a maximum size of 128 megabytes. The memory footprint can be increased by doing the following. Note: This change will apply to all clients. Consideration should be given to any client machines that do not have sufficient resources to fulfill the initial-heap-size value. Page 32

33 1. Find the following line in the <$SPECROOT>/WebApps/tomcat/webapps/ spectrum/oneclick.jnlp file: <j2se version="1.4.2+" href=" autodl/j2se" /> Change the line above to read as follows: <j2se version="1.4.2+" href=" autodl/j2se" initial-heap-size="128m" max-heap-size="256m" /> 128 and 256 megabytes are the recommended increases for minimum and maximum respectively but can be set higher if necessary. For example, to set minimum and maximum memory to 256MB and 512MB respectively, the settings are: initial-heap-size="256m" max-heap-size="512m" /> Important: Any changes to the oneclick.jnlp file will be overwritten during the next upgrade. You must save the changed oneclick.jnlp file and put back the changes after the upgrade. 2. Restart any running clients for the changes to take effect. Page 33

34 Chapter 3: SPECTRUM Security and User Management in The purpose of this section is to discuss SPECTRUM security in from the perspective of the administrator. This will include a discussion of SPECTRUM security basics as well as security in user/network management tasks. In This Section What is Security in SPECTRUM? [page 34] How is Security Implemented in? [page 35] SPECTRUM Security Terminology [page 35] Understanding SPECTRUM Security Concepts [page 36] Getting Started with Security [page 39] Accessing Security and User Management Features [page 40] Configuring SPECTRUM Security in [page 48] What is Security in SPECTRUM? SPECTRUM security lets you designate functional areas of your network model and then grant or deny user access to those areas as well as other SPECTRUM features and functionality. This includes granting or denying users access to modeled network entities, alarms, and user management features. Essentially, SPECTRUM security determines Who (which users and user group members) can do What (view, edit, nothing) Where (at which SPECTRUM models and attributes). Page 34

35 How is Security Implemented in? User security in begins by managing and assigning user licenses each time a user launches a client. A license in SPECTRUM determines the pool of privileges available to a user assigned that license. manages individual licensed privileges using access groups and roles. Access groups provide or deny access to named security communities and also manage privileges. An access group s security community name(s) map to security strings set at the model level in. Privileges are the individual components of user access such as the ability to perform alarm management and roles are collections of privileges. Privileges are based on access groups. Assigned privileges are distinct for each access group a user has and can be assigned individually or in groups using roles. SPECTRUM Security Terminology Table 2: Security Terms Term Access Groups Security String Licenses Roles Legacy User Community String Description Access Groups provide access to security communities and manage user privileges. Security strings can be set on modeled elements in to define additional security communities. A pool of licenses (based on the actual number of administrator, operator, etc. licenses) available to assign to users. Licenses are used as clients are launched. Licenses determine the user privileges available to be granted to holders of the license. Roles are groups of user privileges that can be assigned to the access group(s) of users and user groups. The SPECTRUM legacy user community string has been replaced in by access groups and privilege roles. The legacy community string can still be viewed and edited in under the Details tab for a selected user in the Users tab. Page 35

36 Understanding SPECTRUM Security Concepts A simplified potential workflow to manage users and security in a new installation of follows: 1. Create user group(s) in while logged in as the SPECTRUM administrator user. 2. Assign role(s) based on the tasks you want users to perform to the default access group of the user group(s). 3. Create users within the user group(s). 4. Optionally, you can set the security string on modeled elements in to create security communities. Add the security names to the access group(s) of users you want to be a part of those security communities. Understanding User Management in The following concepts are defined: What are Licenses? [page 36] What are Access Groups? [page 37] What are Roles? [page 38] What are Security Strings? [page 39] What are Licenses? User management in begins with the concept of licenses. A pool of licenses is available to assign to users. This pool is the same as the number of purchased licenses. Types of available licenses are Administrator, Operator, and Service Manger. licenses determine the privileges available to be assigned to users with a given license. For example, the user administration privileges are only potentially available to users who have an Administrator license. Licenses also control how many users can log in with which privileges at one time. For example, you might have 100 operator licenses, five administrator licenses and a single Service Manager licence. In this example, multiple users can be assigned the Service Manager license but only one user can log in and use the single Service Manager license and its associated privileges at one time. The example in Figure 3 shows a user group West that has both the Administrator and Operator licenses but not the Service Manager license. Page 36

37 Any users created in this West user group will inherit this licensing scheme from the group level. Figure 3: Licenses for a User Group What are Access Groups? Access groups in provide a mechanism to determine user access to network models. Access groups are assigned to users and user groups to provide access to specific security communities. Security communities in SPECTRUM define areas of access. Users must be members of a given security community in order to view or edit other members of that community. The security community name(s) of a given access group assigned to a user must correspond with any security strings set at the model level in to provide access to those models. Access groups also manage user privileges. Privileges are the individual components of user access such as the ability to perform alarm management and roles are collections of privileges. Privileges are based on access groups. Users must be given access to security communities using access groups so they can access members (models) of that community. Access group(s) can be viewed and edited in the Access tab (Contents: Access Tab [page 46]). The table in the Access tab shows a list of security communities or groups of security communities which have specific associated privileges. This gives the power to grant certain privileges to a user at specific security communities. Users can have multiple access groups. Access groups can be determined at either or both the user and user group level. Page 37

38 Each table row in the Access tab for a given user or user group represents an access group. The ADMIN access group is the default access group for new users and user groups and represents the entire SPECTRUM environment, though you can change this during the Create User and Create Group dialog boxes. Access groups are assigned a default role which provides privileges. The default role is determined by the license. For example, the default role for a new user with the Administrator license and the default ADMIN access group is AdministratorRW. Table 3 shows the components of example access groups at user/user group creation. Table 3: Example Access Groups License Security Community (Set of Accessible Models) Access Privilege Role Administrator ADMIN Read/Write AdministratorRW and OperatorRW Administrator ADMIN Read only AdministratorRO and OperatorRO Operator ADMIN Read/Write OperatorRW Operator ADMIN Read only OperatorRO Operator Test Read/Write OperatorRW Operator Test Read only OperatorRO In the first example in Table 3, a user is assigned Administrator license and given access to the security community ADMIN. This user can access models in the ADMIN security community and the Administrator license determines that this user is assigned by default the AdministratorRW and OperatorRW roles. What are Roles? Roles define a subset of privileges. Roles depend on licenses and each role is comprised of privileges that are based on a single license. For example, the AdministratorRW role provides privileges that require an Administrator license. Roles are assigned to access groups for users and user groups. Roles apply only to the selected access group. A given role is only available to a user if she also has the license required by the role. Page 38

39 What are Security Strings? Security strings establish membership in a given security community and let you secure models such that they cannot be viewed or edited by other users. When set on a model (including user models and models of other network entities), security strings determine who can see and edit that model. Security strings can be set on user models in and can be used to restrict which administrator users can administer which users. See Using Security Strings to Secure Modeled Elements [page 73]. Understanding Legacy SPECTRUM Security in The SPECTRUM legacy user community string has been replaced with access groups and privilege roles in (see What are Access Groups? [page 37]). Access groups include individual users or user groups that have assigned roles to determine their access privileges. Note: See the Security and User Maintenance (2602) guide for more information about community names and security strings. Getting Started with Security Planning Security in This section will discuss how to formulate a plan to implement security in. Things to consider in a security plan include: Review the following items to prepare to establish or make changes to your existing SPECTRUM security configuration: How many users will there be? Which users and user groups need what level of access (read/write, read only) to which SPECTRUM models? In cases where servers or models require restricted access, models in SPECTRUM should only be made available to certain users Once modeling is set up in, examine topology views to determine appropriate user access to modeled elements. Some examples of planning results are: You want to establish view-only access for all SPECTRUM users to all SPECTRUM models. You also want to limit edit privileges to only the SPECTRUM Network Administrator. Page 39

40 You want to establish view-only access for some SPECTRUM users to a restricted group of SPECTRUM models. Other SPECTRUM models will not be accessible to these users. Certain SPECTRUM users may or may not have edit privileges in their restricted group of SPECTRUM models. You want to configure security such that network administrators in one office have read/write privileges to their local office s network in. They must also have read-only access to the remote network. The inverse must also be true for the remote office network administrators. This example is described in detail in Using Security Strings to Secure Modeled Elements [page 73]. You want users to have access to everything in except the ability to perform tasks available with the add-on Service Manager. This can be accomplished with a custom privilege role that includes all privileges except those required by Service Manager. This example is described in detail in Managing User Groups in [page 56]. Accessing Security and User Management Features The administrator must first meet these prerequisites to perform user management: - Launch and log in as a user with administrative read/write privileges (such as the initial user that installed SPECTRUM) - This user must also have an Administrator license and user management privileges in order to have access to the user management tools in the Users tab Procedure - Accessing User Management Tools 1. In the navigation panel, click the Users tab. Figure 4 shows the Users tab for a selected user in the West user group. Page 40

41 Figure 4: Accessing Users Tab for User Management Page 41

42 Users Tab The Users tab in the navigation panel (see Figure 5) displays a hierarchical list of users and user groups. Users and user groups appear under a top-level group (the Users group) which contains all users and groups. Only the users you have permission to view will appear in the hierarchy. Figure 5: User Management Options in the User Tab Create user, create user group, and delete selected user/ user group buttons Users tab Top-level Users group contains all users and groups User group User Page 42

43 Contents: Users List Tab Selecting the top-level Users group in the Users tab populates the Users List tab of the Contents panel (Figure 6) with a table of all users not in their own group. Selecting a given user not in its own group in the Users tab populates the table with the list of all users that are not in a user group with that user selected. Selecting a user group or a user within a user group will list only the users in that group (see Figure 6). Figure 6: Users List Tab Deletes selected user(s)/user group(s) Exports users list as table Details for selected user appear in Details tab of Component Detail panel Page 43

44 Component Detail: Details Figure 7 displays the Details tab in the Component Detail view for a selected user (the admin-west user, in this case) in the User List tab. Values for certain user attributes for this user such as contact information can be set in the Details tab by clicking a set link and entering a new value. Figure 7: Component Detail: Details Page 44

45 Component Detail: Licenses Figure 8 displays the Licenses tab in the Component Detail view for the admin-west user. This tab displays licenses in the Name column with check marks in the Member Of column for each license granted to this user. For example, the admin-west user has Administrator and Operator licenses but not a Service Manager license. You can edit a user s license membership by clicking the Add/Remove button in the Licenses tab. Figure 8: Component Detail: Licenses Component Detail: Landscapes Figure 9 displays the Landscapes tab in the Component Detail view for the admin-west user. This tab displays the state and name of each known SPECTRUM landscape with check marks in the Member Of column for each landscape this user is present in. You can edit a user s membership in SPECTRUM landscapes by clicking the Add/Remove button in the Landscapes tab. You cannot add or remove landscapes that are in the down state. Figure 9: Component Detail: Landscapes Page 45

46 Contents: Access Tab Figure 10 displays the Access tab in the Contents view. This tab displays the access group(s) of the user or user group selected in the Users tab of the Navigation panel. Access groups let you control user access to other users and network entities in and determine read/write privileges (who can do what where). Users can have multiple access groups. You can edit access groups membership using the Add, Edit, and Remove buttons in the Access tab. Figure 10: Access Tab You can add additional access groups for users and user groups selected in the Navigation panel by clicking Add. Edit enables you to edit the selected access group. Remove enables you to delete the selected access group. Each table entry in the Access tab (WEST,NORTH and EAST here) is an Access Group. The two access groups in this example provide privileges using roles to their respective communities. For example, this user has the AdministratorRW role at the EAST access group and the OperatorRW role at the WEST,NORTH access group. This provides different sets of privileges at different sets of models. In this example, the WEST,NORTH and EAST access groups are set at the user level (User is shown in the From column for both) rather than at the user group level and therefore can be edited or removed here. Page 46

47 Component Detail: Privileges Tab Figure 11 displays the Privileges tab in the Component Detail view for the selected ADMIN access group for a user. This tab displays the privileges granted by the selected access group. This example component detail label shows that these privileges are associated with the selected ADMIN access group and are inherited from the user level. The From Role column shows that all of these privileges are being granted by the OperatorRW role. Clicking Add/Remove lets you enable and disable privileges for this user at the selected ADMIN access group. You cannot use Add/Remove at the user level to manage privileges for an access group that is inherited from a user group. Component detail label Privileges tab Figure 11: Privileges Tab Click Add/Remove to enable and disable privileges for this user for the ADMIN access group. A check mark appears in the Enabled column for each privilege granted to this user. Page 47

48 Component Detail: Roles Tab Figure 12 displays the Roles tab in the Component Detail view for the selected WEST,NORTH access group for the admin-west user. This tab displays the roles granted by the selected access group. The component detail label shows that these roles are associated with the WEST,NORTH access group and are inherited from the user level (the Component Detail label displays WEST,NORTH from User). Use the New and Edit buttons to create and change roles respectively. Edit is disabled here because a default role is selected. You cannot edit default SPECTRUM roles, only roles that you create. Figure 12: Roles Tab Roles listed in this table are for the WEST,NORTH access group (selected in the Access tab). The New button creates a role that can be used by this and other users. Once you ve created a new role, you can use Add/Remove to associated it with a user. Check marks in the Member Of column indicate the privilege role(s) this user has relative to the WEST,NORTH access group. Configuring SPECTRUM Security in This section provides procedural information about the tasks you must perform to implement security and manage users and user groups in. Managing Licenses by Limiting Concurrent User Logins Each client login consumes one instance each of any licenses assigned to that user from the pool of all available Page 48

49 licenses. By default, Console users can launch unlimited clients with a single set of login credentials. In this case, it is possible for a single user to consume all of the available licenses by launching clients again and again without exiting the previously logged-in clients. For example, if a operator user with an Operator license launched five clients in an environment with only 5 Operator licenses total, no other users could launch any clients. Client Details The Client Details web page displays License Summary and Client(s) Logged On (Figure 13) tables. This web page can only be accessed by administrator users. Figure 13: Client Details The license summary provides the following information: Total concurrent licenses by type Number of licenses currently in use by connected clients Which logged in users have which license(s) Page 49

50 To view the Client Details web page: 1. Navigate to 2. Click the Client Details link To send a message to logged-in client(s) from the Client Details web page: 1. Select the check box(es) next to the User Name of the client(s) you want to send a message to and click Send Message (Figure 13). 2. Enter a message in the Enter Message dialog box and click Send. To log off logged-in client(s) from the Client Details web page: 1. Select the check box(es) next to the User Name of the client(s) you want to log off and click Log off Clients (Figure 13). 2. Click OK in the dialog box. The client(s) are logged off and receive a message indicating the administrator user who logged them off. Limiting Concurrent Logins Administrators can restrict the number of concurrent licenses which a single user may use with the same set of login credentials. This feature can be used to distribute the available licenses among users. Additionally, the maximum number of logins may be set to zero to effectively lock out a user without destroying the user model and all of its settings. Procedure Note: Maximum logins must be set at the user level and cannot be set at the user group level. To change a user s maximum logins: 1. Navigate to the Details tab of the Component detail panel for a given user in the Users tab (Figure 14). Page 50

51 Figure 14: Maximum Logins Set Maximum Logins To restrict this user to a single concurrent license: a. Click the set link for Maximum Logins (Figure 14). b. Enter 1 and click the Save link (Figure 15). Figure 15: Setting Maximum Logins Page 51

52 To restrict this user from launching any clients: a. Click the set link for Maximum Logins. b. Enter 0 and click the Save link. To allow this user to launch an unlimited number of clients: a. Click the set link for Maximum Logins. b. Click the Unlimited link. Figure 16 displays a typical error message for a user attempting to open a second client when that user has been restricted to running a single concurrent license. Figure 16: Maximum Logins Exceeded Error Entries for failed login attempts will appear in the Client Log at <hostname>:<portnumber>/spectrum/console/client-log.jsp. Figure 17 [page 53] shows a client log with failed login attempts. The user admin has been prevented from launching any clients, while the user Operator has been restricted from launching a second client. Page 52

53 Figure 17: Client Log - Failed Logins Managing Users in user administration requires the administrator user to have at minimum the Administrator license and user management privileges. Consider creating a user with user management privileges to manage users. This user is in addition to the user that installed (the initial user). This can be helpful because you cannot edit the user you are logged in as. To ensure a administrator user has all possible privileges, set its value for issuperuser to true in the Details tab of the Component Detail panel as described in Granting All Privileges to an Existing User with Super User [page 71]. This prevents any changes made to roles from affecting the user administrator. Create a New User Example: Create a New Operator User As an Administrator at a small enterprise, you want to add an operator user who can see all models and who has all operator privileges: 1. In the Users tab of the Navigation panel, select the top-level Users node and click the Create New User button (Figure 18). Page 53

54 Figure 18: Create User 2. In the Create User tabbed dialog box (Figure 19), enter a name for this user in the Name field. Figure 19: Create User 3. Enter and confirm a web password for this user in the Web Password and Confirm Web Password fields, respectively. This password is used by to authenticate this user. Page 54

55 4. Ensure that Operator is selected in the Licenses tab (Figure 19). By default, new users receive the Operator license (and the OperatorRW privilege role). 5. Figure 20 shows the access tab for the new user. The user shown in Figure 20 will belong to an access group with read/write access to the ADMIN security community. Note: Access groups are described in detail in What are Access Groups? [page 37]. Figure 20: Create User - Access Tab 6. Click OK. Edit an Existing User See the Editing and Deleting Users and User Groups [page 66] section for complete details. Page 55

56 Managing User Groups in A good way to manage users in is by creating user groups and then creating users within those user groups. All users contained in a given user group inherit certain attributes set at the user group level including security settings. Inheritance Details for Users in User Groups When a user is moved to or created within a group, that user inherits the security string, legacy community string, access group(s), and role(s) from the user group. Any changes to these elements at the group level propagate down to the user level for users contained by a given group. Properties inherited at the group level can only be changed at the group level. The following additional information applies to users contained within a user group: Other user group attributes will be inherited based on any common attributes set in the legacy SPECTRUM User Editor. For more information, see the Setting Up Common Attributes section in the Security & User Maintenance (2602) guide. Landscapes are not inherited by contained users from the user group. Creating User Groups in Creating user groups can be used as a way to provide the same level of access and privileges to many users at once. Say for example you want to allow a group of users all privileges for all models in except for the privileges related to the add-on application Service Manager. This is illustrated in the following example. The example creates a group called NoSvcMgrGroup. Users in this group will receive all privileges except those privileges required to perform Service Manager-releated tasks. Procedure Note: This example assumes that the Service Manager add-on application is present. 1. Click the Create a New Group (Figure 21) button. Page 56

57 Figure 21: Create User Group 2. In the Create Group dialog box, name the new group NoSvcMgrGroup and select the Administrator license (shown in Figure 22). Note: The Service Manager license controls access to the Service Manager Dashboard. The service management privileges discussed here are not related to the Service Manager license. However, you would not want users without service management privileges to have a Service Manager license which would be consumed every time that user logs in. Make sure the Service Manager license (if available) is not selected for this example. Page 57

58 Figure 22: Create Group Page 58

59 3. Figure 23 shows the access tab for the new user. As shown in Figure 23, users in this group will have read/write access to the ADMIN security community by default. Figure 23: Create User Group - Access Tab 4. Click OK. Page 59

60 5. In the Users tab of the Navigation panel, select the NoSvcMgrGroup group. Navigate to the Contents panel > Access tab (the default ADMIN access group will be the only access group) > Component Detail panel > Privileges tab (Figure 24). Figure 24: Privileges Tab Note: When you create a new user or group, it is assigned the Operator license by default and it inherits the OperatorRW privilege role. When you create a new user or group with the Administrator license, it inherits the AdministratorRW role, as well as the Operator license and the OperatorRW role. 6. In the Privileges tab, click the Add/Remove button. Page 60

61 7. In the Add / Remove Privileges dialog box, notice that all privileges are enabled for the NoSvcMgrGroup user group (Figure 25). We want to enable everything except Service Manager privileges for this user group. Figure 25: Add / Remove Privileges Service Management privileges are enabled by default for this group. The From Role column shows where enabled privileges are inherited from. 8. In the Add / Remove Privileges dialog box, clear the Enabled check box for Service Management privileges. Page 61

62 Figure 26: Add / Remove Privileges Service Management privileges will be disabled. The From Role column shows that this user group no longer belongs to the privilege roles in Figure 25. The privilege settings themselves have not changed however. 9. Click OK. Users placed in this group (see Creating A User Within a Group [page 62]) will inherit only the privileges defined above from the NoSvcMgrGroup group. Creating A User Within a Group The following example creates a user within the NoSvcMgrGroup group created in Creating User Groups in [page 56]. As of SPECTRUM 7.1 Service Pack 1, users in user groups can inherit any attribute that has been set at the group level. Certain values in the Create User dialog box are set based on the user group. Common attributes are disabled for Page 62

63 editing. For example, Figure 28 shows the Access tab for the new user is disabled; its values must be changed at the user group level if necessary. Procedure 1. Select the NoSvcMgrGroup user group in the Users tab and click the New User button (shown in Figure 27). Figure 27: Create User in Group Page 63

64 Figure 28: Create a User in a User Group 2. Complete the information in the Create User dialog box and click OK (See Create a New User [page 53] for complete details). 3. This new user will automatically be placed under the NoSvcMgrGroup user group in the Users tab and inherit its privileges. Add an Existing User (Move) to a User Group Important: Any landscapes that the destination user group is not in should be removed from the user you want to move before moving the user. To do this (for a selected user in the Users List tab in the Contents panel), click the Add/Remove... button in the Landscapes tab in the Component Detail panel. Page 64

65 Procedure 1. Right-click on a user in the Users tab or the Users List tab and select Move To Group... Important: You cannot move the user you are currently logged in as to a different group while logged in. 2. Select the destination group in the Select User Group dialog box and click OK (Figure 29). Figure 29: Select User Group Remove a User from a User Group Removing users from groups will cause them to lose any access groups and privileges they had inherited from the group level. After removing a user from a group, make sure the user has the access groups and privileges you expect it to. Procedure 1. Right-click on a user in the Users tab or the Users List tab and select Remove From Group. 2. Removing a user from a user group places the user under the toplevel Users group. Page 65

66 Editing and Deleting Users and User Groups This section describes common tasks and procedures for editing existing users and user groups. Deleting users and groups is also described (Delete a User or User Group [page 68]). Edit an Existing User or User Group 1. Select the user or user group for edit in the Users tab of the Navigation panel. 2. Navigate to the Details tab of the Component Detail panel for that user/group. The user/group is also selected in the Users List tab of the Contents panel. 3. To change the details of a user or group: a. Click the Details tab of the Component Detail panel. b. Use the blue set links to edit attributes such as the password and security string of an existing user or group. 4. To change the licenses assigned to a user or group: a. Click the Licenses tab of the Component Detail panel. b. Click the Add/Remove button to select which licenses this user or group is a member of. 5. To change the landscapes this user or group is present in: a. Click the Landscapes tab of the Component Detail panel. b. Click the Add/Remove button c. Choose the landscapes you want this user or group to exist in. 6. To edit existing access group(s) for this user or group: a. Navigate to the Access tab of the Contents panel for the selected user. b. Select the access group you want to add a new security community to. c. Click the Edit button. d. Enter an additional security community in the Edit dialog box and click Add to add it. To add multiple security communities to the access group, enter the security communities one at a time in the Page 66

67 Edit dialog box and click Add after each one. When you are finished, click OK. For any new security communities you add here, this user or group will have the same privileges as those granted by the existing access group you are adding them to. 7. To create new access group(s) for this user or group: a. Navigate to the Access tab of the Contents panel for the selected user. b. Click the Add button in the Access tab of the Contents panel to create additional access group(s). c. In the Edit dialog box, enter any additional security communities you want this user to have access to and click OK. This security community will have the same privileges as the other. Use Add to grant new privileges which you must do at that time. 8. To remove access group(s) for this user or group: a. Navigate to the Access tab of the Contents panel for the selected user. b. Select the access group you want to remove. c. Click the Remove button. 9. To add or remove privilege roles for an access group of a user or user group: a. Navigate to the Access tab of the Contents panel for the selected user. b. Select an access group to modify. c. Select the Roles tab of the of the Component Detail panel. d. Click Add/Remove to open the Assign Roles dialog box. e. Move the roles you want this access group to have into the Exists in/create in list. f. Move the roles you do not want this access group to have into the Does not exist in/delete from list. g. Click OK. 10. To change individual privileges for an access group of a user or user group: Page 67

68 a. Navigate to the Access tab of the Contents panel for the selected user. b. Select the access group you want to modify privileges for. c. Navigate to the Privileges tab of the Component Detail panel for the selected access group. d. Click the Add/Remove button. e. Enable or disable the privileges you want for this access group by checking or clearing the Enabled check box, respectively. 11. To change privilege roles for an access group of a user or user group: a. Navigate to the Access tab of the Contents panel for the selected user. b. Select the access group you want to modify roles for. c. Navigate to the Roles tab of the Component Detail panel for the selected access group. d. Click the Add/Remove button to open the Assign Roles dialog box. e. In the Assign Roles dialog box, move any roles you want this user or group to have for this access group to the Exists in/create in left panel. f. In the Assign Roles dialog box, move any roles you do not want this user or group to have for this access group to the Does not exist in/delete from in right panel. Delete a User or User Group Note: When you delete a user group, any users contained in that group are then organized under the toplevel Users node. 1. Select the User or User Group for deletion in the Users tab. The user Administrator is selected for deletion in Figure Click the Delete button. Page 68

69 Figure 30: Delete User or Group Creating and Assigning Roles to Users or User Groups The NoSvcMgrGroup example used in Creating User Groups in [page 56] explains how to individually disable/enable certain privileges for a user group. Another way to assign privileges to a given user or group is to create a reusable, custom privilege role. The following example shows how to create and edit a custom role via the Roles tab and how to associate that role with a user or group. This custom role provides the same privileges using a reusable, assignable role as the NoSvcMgrGroup example did using individual privileges. Procedure Note: The privilege role created in the following procedure represents an example of how you would provide the same access as the privileges manually assigned to the NoSvcMgrGroup group in the Creating User Groups in [page 56] example. 1. Select the Contents panel > Access tab for a user that has an Administrator license and is not a super user (see Granting All Privileges to an Existing User with Super User [page 71] for more information about super users). 2. In the Component Detail panel for this user, select the Roles tab. 3. Click the New button to open the Add Role dialog box. 4. Name the new role NoSvcMgrRole and select Administrator from the License drop-down menu. Note: The license chosen here determines the privileges that can be enabled for this role. Page 69

70 5. Under Privileges in the Add Role dialog box, enable all privileges by selecting the top Privileges node. 6. De-select only the Service Management group of privileges (Figure 31). Figure 31: Add Role Dialog Box 7. Click OK. 8. In the Roles tab, click the Add/Remove button. Using the arrow buttons, move the AdministratorRW role (and the OperatorRW if it is also present in the Exists in/create in column) to the Does not exist in/delete from column and move the nosvcmgr role to Exists in/create in (Figure 31). Page 70

71 Figure 32: Assign Roles Dialog Box 9. Click OK. Note: To assign this role to a user or group, that user or group must have the Administrator license. Granting All Privileges to an Existing User with Super User The administrator can easily grant all available privileges to a given user. To grant all available privileges to a user, you can designate that user as a super user. A super user in SPECTRUM is a user that has all possible SPECTRUM privileges and access in. A user that has been designated a super user is automatically granted all license roles and privileges. Because access groups and privilege roles do not apply to super users, the Access tab is disabled when a user designated as super user is selected in. The initial user created when installing SPECTRUM is created as a super user. This initial user, once created, will remain a super user and must always exist (its existence is verified by SPECTRUM each time the SpectroSERVER starts). The value for initial_user_model_name in the <$SPECROOT>/SS/.vnmrc file stores the setting for the initial SPECTRUM super user. Creating Super Users Users other than the initial user can be made super users by following these steps: Page 71

72 Procedure 1. Select the user you want to grant super user status to from the Users List. 2. In the Details tab click the set link for Is Super User. 3. Select Yes from the drop-down menu (Figure 33). Figure 33: Setting User to Super User Page 72

73 Using Security Strings to Secure Modeled Elements Security strings can be set on modeled elements to set up security communities. For example, the security string of all models of network entities in a remote coast office can be set to remote to create a security community called remote. To understand using security strings to provide security in, a simple example of an end to end implementation of security in follows. In this example, consider an East coast office and a West coast office. Network administrators in the East coast office must have read/ write privileges to the East coast office s network in. They must also have read-only access to the West coast network. The inverse is true for the West coast administrators. The following procedure can be used to create this configuration. Procedure 1. Create two LAN containers in representing the two networks. Name one LAN container WEST and the other EAST. 2. Populate each container with different modeled network assets. 3. Set the security string on each LAN container. In the Information tab of the Component Detail panel for a selected LAN container, set the security string: Page 73

74 a. Set the EAST LAN container s security string to EAST (see Figure 34). This effectively creates a security community named EAST. Figure 34: Setting Security String Click the set link and set the security string to EAST for the EAST LAN container. b. Set the WEST LAN container s security string to WEST. This effectively creates a security community named WEST. These security strings roll down from the LAN container level to its contained models. A security string set at the container level is automatically set for all its contained models. When this is complete, it should look (to the Administrator user) something like Figure 35: Page 74

75 Figure 35: WEST/EAST LAN Containers The WEST and EAST LAN containers are members of the WEST and EAST security communities, respectively. The WEST LAN container contains a model of a router at The EAST LAN container contains a model of a router at Create user groups to correspond with the EAST and WEST network containers: a. Create an EAST user group. In the Create Group dialog box, create an access group with read/write privileges for the EAST security community (Figure 36): Page 75

76 Figure 36: Setting Up Access during Create Group Read/write access to the security community EAST has been added to this user group To add read only access to the WEST security community, enter WEST in this field and click Add. b. Create a WEST user group. In the Create Group dialog box, create an access group with read-only privileges for the EAST security community. 5. Create a user inside the EAST user group and another user inside the WEST user group. Notice in the Access tab that the access groups (security community) are filled in from the User Group level (not editable here at the User level). Page 76

77 6. To test, log in to as the user you created inside the WEST user group in step 5 and navigate to the EAST LAN container (shown in Figure 35). 7. When viewing models inside the EAST LAN container, users in the WEST user group have Administrator read only rights as shown in Figure 37. For example, Figure 37 illustrates the fact that values in SPECTRUM Modeling Information cannot be edited by this user at this model. Figure 37: View of a Model in the EAST LAN for a User in the WEST User Group This user in the WEST user group has administrator read only access to this model in the EAST LAN container and cannot edit its values. Page 77

78 8. Now navigate to the WEST LAN container. Notice that this user in the WEST user group has Administrator read/write privileges for models inside the WEST LAN (shown in Figure 38). For example, Figure 38 shows that values in SPECTRUM Modeling Information can be edited by this user at this model. Figure 38: View of a Model in the WEST LAN for a User in the WEST User Group This user in the WEST user group has administrator read/write access to this model in the WEST LAN container and can edit values here. 9. If you log in to as the user you created inside the EAST user group in step 5 and navigate to the WEST LAN container, the inverse of step 7 will be true (i.e. users in the EAST user group have Administrator read only rights to the models inside the WEST LAN container, and read/write rights to the models in the EAST LAN). Page 78

79 Setting Preferences for Users and Groups In addition to configuring privileges for users and user groups in, you can also set user and user group preferences. Preferences in control the appearance of the Console (for example, the fonts used in tables and the sort order of columns) as well as the behavior of certain aspects of the user interface. The Preferences Editor lets administrators set, lock, and save preferences for multiple users and groups. Important: Selecting View > Preferences from the main menu opens user-level preference editing for the currently logged-on user. The Alarm Filter dialog box once accessed from this menu item can now be launched from a button on the Alarms toolbar. Accessing the Preferences Editor [page 80] About the Preferences Editor [page 81] Setting and Locking Preferences [page 82] Importing and Exporting Preferences [page 84] Setting Alarm Filter Preferences [page 84] Resetting Preferences [page 85] Page 79

80 Accessing the Preferences Editor To access the Preferences Editor to set preferences for a user or user group: 1. In the Users tab, right-click a user or user group for which you want to set preferences. 2. Choose Set Preferences from the menu (Figure 39) to open the About the Preferences Editor [page 81]. Figure 39: Set Preferences To access the preferences editor to set preferences for all users (globally): 1. Right-click the top-level user group (Users) in the Users tab. 2. Choose Set Preferences from the menu (Figure 39) to open the About the Preferences Editor [page 81]. Page 80

81 About the Preferences Editor Figure 40 displays the Preferences Editor. Figure 40: Preferences Editor Navigation Panel Content Panel displays settings for preference(s) selected in the Navigation Panel. The Preferences Editor organizes preferences into groups in the navigation panel. Preferences are grouped by task including: General Alarms Events Locator Table Page 81

82 When the top-level Preferences group is selected in the navigation panel, all available preferences and the tools to edit them are shown in the content panel. Selecting a preference or preference group in navigation panel displays the preference or preference group in the content panel. The left panel of the Preferences Editor also lets you lock preferences for the selected user or user group. See Setting and Locking Preferences [page 82]. When you launch the Preference Editor in the context of setting preferences for users and groups (as described in Accessing the Preferences Editor [page 80]), the Preference Editor displays the name of the user or group being edited at the base of the navigation panel. Figure 40 [page 81] shows preferences for the user group techwrit being edited. Setting and Locking Preferences User preferences can be set and/or locked by the administrator at the global (all users), user group, or user level. Users cannot lock their own preferences. If a preference is set and locked for a user or group, the preference cannot be changed by the user or members of the user group, respectively. Important: A locked preference can only be unlocked and edited at the level it was locked. If a preference is locked at the global or user group level, the preference cannot be unlocked or edited at the user level. If the Preference Editor is launched in the context of a given user and a preference is locked at the global or group level for that user, the administrator will not be able to change the preference. The lock check box will be grayed out in this case. Setting user and group preferences is controlled by administrator privileges: The Set User Preferences privilege grants access to set preferences for particular users and groups. This is controlled by the user/group model's security string. The Set Global Preferences privilege grants access to set preferences at the global level. To set and/or lock user preferences, follow this procedure: Page 82

83 Procedure 1. In the Preferences Editor for a selected user or user group (see Accessing the Preferences Editor [page 80]), navigate to the preference(s) you want to set and lock in the hierarchy in the navigation panel. 2. Make any changes necessary to the preference(s) in the right panel. See Figure 40 [page 81]. 3. Select the check box(es) in the Locked column to lock any corresponding preferences. Locking a preference group also locks all preferences contained by the preference group. The Locked At column shows the level at which the preference is locked (user, user group, or all users). The Locked By column displays the administrator user who locked it. See Figure 41. Note: The Locked, Locked At, and Locked By columns only appear in the Preferences Editor when launched by an administrator in the context of another user or user group. Figure 41 shows the preferences for the alarm count columns in the Explorer tab have been edited to display all alarms for the user group Administration. No user in this group can change this preference because it is locked at the user group level. Locked preferences display a small padlock icon. Figure 41: Setting and Locking Preferences: User Group Page 83