apm 9.5 security guide

Security Guide Release 9.5

CA Application Performance Management

This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation) is for your informational purposes only and is subject to change or withdrawal by CA at any time.

This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This Documentation is confidential and proprietary information of CA and may not be disclosed by you or used for any purpose other than as may be permitted in (i) a separate agreement between you and CA governing your use of the CA software to which the Documentation relates; or (ii) a separate confidentiality agreement between you and CA.

Notwithstanding the foregoing, if you are a licensed user of the software product(s) addressed in the Documentation, you may print or otherwise make available a reasonable number of copies of the Documentation for internal use by you and your employees in connection with that software, provided that all CA copyright notices and legends are affixed to each reproduced copy.

The right to print or otherwise make available copies of the Documentation is limited to the period during which the applicable license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed.

TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION AS IS WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE.

The use of any software product referenced in the Documentation is governed by the applicable license agreement and such license agreement is not modified in any way by the terms of this notice.

The manufacturer of this Documentation is CA.

Provided with Restricted Rights. Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-7014(b)(3), as applicable, or their successors.

Copyright 2013 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

CA Technologies Product References

This document references the following CA Technologies products and features:

CA Application Performance Management (CA APM)

CA Application Performance Management ChangeDetector (CA APM ChangeDetector)

CA Application Performance Management ErrorDetector (CA APM ErrorDetector)

CA Application Performance Management for CA Database Performance (CA APM for CA Database Performance)

CA Application Performance Management for CA SiteMinder (CA APM for CA SiteMinder)

CA Application Performance Management for CA SiteMinder Application Server Agents (CA APM for CA SiteMinder ASA)

CA Application Performance Management for IBM CICS Transaction Gateway (CA APM for IBM CICS Transaction Gateway)

CA Application Performance Management for IBM WebSphere Application Server (CA APM for IBM WebSphere Application Server)

CA Application Performance Management for IBM WebSphere Distributed Environments (CA APM for IBM WebSphere Distributed Environments)

CA Application Performance Management for IBM WebSphere MQ (CA APM for IBM WebSphere MQ)

CA Application Performance Management for IBM WebSphere Portal (CA APM for IBM WebSphere Portal)

CA Application Performance Management for IBM WebSphere Process Server (CA APM for IBM WebSphere Process Server)

CA Application Performance Management for IBM z/OS (CA APM for IBM z/OS)

CA Application Performance Management for Microsoft SharePoint (CA APM for Microsoft SharePoint)

CA Application Performance Management for Oracle Databases (CA APM for Oracle Databases)

CA Application Performance Management for Oracle Service Bus (CA APM for Oracle Service Bus)

CA Application Performance Management for Oracle WebLogic Portal (CA APM for Oracle WebLogic Portal)

CA Application Performance Management for Oracle WebLogic Server (CA APM for Oracle WebLogic Server)

CA Application Performance Management for SOA (CA APM for SOA)

CA Application Performance Management for TIBCO BusinessWorks (CA APM for TIBCO BusinessWorks)

CA Application Performance Management for TIBCO Enterprise Message Service (CA APM for TIBCO Enterprise Message Service)

CA Application Performance Management for Web Servers (CA APM for Web Servers)

CA Application Performance Management for webMethods Broker (CA APM for webMethods Broker)

CA Application Performance Management for webMethods Integration Server (CA APM for webMethods Integration Server)

CA Application Performance Management Integration for CA CMDB (CA APM Integration for CA CMDB)

CA Application Performance Management Integration for CA NSM (CA APM Integration for CA NSM)

CA Application Performance Management LeakHunter (CA APM LeakHunter)

CA Application Performance Management Transaction Generator (CA APM TG)

CA Cross-Enterprise Application Performance Management

CA Customer Experience Manager (CA CEM)

CA Embedded Entitlements Manager (CA EEM)

CA eHealth Performance Manager (CA eHealth)

CA Insight Database Performance Monitor for DB2 for z/OS

CA Introscope

CA SiteMinder

CA Spectrum Infrastructure Manager (CA Spectrum)

CA SYSVIEW Performance Management (CA SYSVIEW)

Contact CA Technologies

Contact CA Support

For your convenience, CA Technologies provides one site where you can access the information that you need for your Home Office, Small Business, and Enterprise CA Technologies products. At http://ca.com/support, you can access the following resources:

Online and telephone contact information for technical assistance and customer services

Information about user communities and forums

Product and documentation downloads

CA Support policies and guidelines

Other helpful resources appropriate for your product

Providing Feedback About Product Documentation

If you have comments or questions about CA Technologies product documentation, you can send a message to [email protected].

To provide feedback about CA Technologies product documentation, complete our short customer survey which is available on the CA Support website at http://ca.com/docs.

Contents 7

Contents

Chapter 1: CA APM Security Overview 11

CA APM security summary ......................................................................................................................................... 11

CA APM security and permissions overview .............................................................................................................. 13

About user authentication .................................................................................................................................. 13

About user authorization .................................................................................................................................... 14

About security realms ......................................................................................................................................... 14

Benefits of securing CA APM using CA EEM ........................................................................................................ 18

Chapter 2: Defining and configuring Introscope domains 21

Defining and configuring Introscope domains ........................................................................................................... 21

Domain types ...................................................................................................................................................... 21

Rules for defining domains ................................................................................................................................. 22

Use Identical domains.xml Within and Across Clusters ...................................................................................... 22

Defining and Mapping Agents to a Domain ........................................................................................................ 23

Associating management modules with domains .............................................................................................. 24

Adding sample management modules to newly defined domains ..................................................................... 25

Changing the domain mapping of an agent ........................................................................................................ 26

Deleting a domain ............................................................................................................................................... 26

Merging two domains ......................................................................................................................................... 26

Cloning domains between different Introscope installations ............................................................................. 27

Moving a domain between non-cloned installations .......................................................................................... 27

Agent failover and user/domain configuration ................................................................................................... 28

Configuring public and private keys for secure authentication ................................................................................. 28

About the default Collector private key .............................................................................................................. 28

Generating a new public and private key set ...................................................................................................... 29

Chapter 3: Securing Introscope 31

Introscope security and permissions overview .......................................................................................................... 31

About Introscope domains and security ............................................................................................................. 31

About configuring Introscope permissions ......................................................................................................... 32

Domain permissions and the Investigator tree ................................................................................................... 32

Introscopes default security configuration ........................................................................................................ 32

How Introscope checks security ................................................................................................................................. 33

Securing Introscope using Local security ................................................................................................................... 34

About configuring Local authentication .............................................................................................................. 34

Configuring Local authentication in realms.xml .................................................................................................. 35

8 Security Guide

About using multiple files for security realms .................................................................................................... 36

Configuring CA APM users and groups in users.xml ........................................................................................... 37

Configuring CA Introscope Domain Permissions in domains.xml ..................................................................... 40

Configuring Enterprise Manager server permissions in server.xml .................................................................... 44

Securing Introscope using LDAP ................................................................................................................................. 45

About LDAP authentication ................................................................................................................................. 47

Configuring LDAP authentication in realms.xml ................................................................................................. 47

Securing Introscope using CA EEM ............................................................................................................................. 57

Installing CA EEM ................................................................................................................................................ 60

(Optional) Configuring logging of CA EEM-related messages ............................................................................. 61

Configuring CA EEM authentication in realms.xml ............................................................................................. 61

Configuring CA EEM authentication using LDAP ................................................................................................. 64

Configuring CA EEM authentication using CA SiteMinder .................................................................................. 65

Configuring CA EEM authorization ...................................................................................................................... 66

About CA EEM access policies ............................................................................................................................. 88

Setting up CA EEM in a cluster ............................................................................................................................ 99

Migrating from Local to CA EEM security ......................................................................................................... 100

Migrating from LDAP to CA EEM security ......................................................................................................... 100

Configuring CA EEM to use Local authorization ................................................................................................ 101

About Introscope single sign-on (SSO) ..................................................................................................................... 102

About SiteMinder SSO and Introscope security ................................................................................................ 102

Securing the application triage map ........................................................................................................................ 103

SuperDomain security overrides application triage map security .................................................................... 105

Troubleshooting Introscope security ....................................................................................................................... 105

Introscope security mechanisms .............................................................................................................................. 107

Chapter 4: Securing CA CEM 109

CA CEM security mechanisms .................................................................................................................................. 110

How to configure web protection for TIM ............................................................................................................... 111

About CA CEM authentication ................................................................................................................................. 112

Managing CA CEM passwords .................................................................................................................................. 112

About CA CEM authorization ................................................................................................................................... 113

About CA CEM security user groups ......................................................................................................................... 114

Additional CA CEM authentication and authorization solutions .............................................................................. 115

Menu items and privileges associated with the default CA CEM security user groups ........................................... 115

CA EEM authentication and authorization for CA CEM ............................................................................................ 117

Managing CA CEM users and groups in CA EEM ............................................................................................... 117

About CA CEM resource classes in CA EEM ...................................................................................................... 119

About Introscope-specific resource classes ...................................................................................................... 120

About CA CEM resources in CA EEM ................................................................................................................. 120

Default CA EEM CEM access policies ................................................................................................................ 120

Contents 9

About CA CEM default business service access policies ................................................................................... 123

Updating CA CEM access policies in CA EEM ........................................................................................................... 124

Adding new CA CEM access policies in CA EEM ....................................................................................................... 124

Giving CA EEM Introscope users access to the CEM console ................................................................................... 124

Local authentication and authorization for CA CEM ................................................................................................ 125

Local users and groups and CA CEM ................................................................................................................. 125

Giving Local Introscope users access to the CEM console ................................................................................ 126

Additional CA CEM security tasks ............................................................................................................................. 126

CA CEM Security Link ........................................................................................................................................ 127

Defining private parameters ............................................................................................................................. 127

Protecting HTTP requests and responses on defects ........................................................................................ 129

FIPS 140-2 compliant encryption ...................................................................................................................... 136

Configuring TIM communication via HTTPS ...................................................................................................... 139

Restricting Enterprise Manager access via HTTPS only ..................................................................................... 139

About CA APM Transaction Generator (CA APM TG) security ................................................................................. 140

Chapter 5: Using nCipher with CA CEM 141

Using nCipher with CA CEM ..................................................................................................................................... 141

Environment ...................................................................................................................................................... 142

Prerequisites ..................................................................................................................................................... 142

Setting up CA CEM to support nCipher .................................................................................................................... 143

Installing nCipher hardware in the TIM ............................................................................................................ 143

Installing the nCipher software on the TIM ...................................................................................................... 144

Building a Kernel Driver..................................................................................................................................... 144

Verifying the nCipher installations on the TIM ................................................................................................. 145

Enrolling the TIM HSM in the nCipher security world ....................................................................................... 146

Uploading the web servers nCipher private key to CA CEM ............................................................................ 149

Configuring the nCipher HSM on the TIM ......................................................................................................... 150

Verifying the nCipher-secured web traffic ........................................................................................................ 152

Working with nCipher keys and operator cards ....................................................................................................... 153

Retargeting the web server private key ............................................................................................................ 153

Removing the pass phrase from an operator card............................................................................................ 155

Creating a new operator card set ..................................................................................................................... 156

Consolidating operator card sets ...................................................................................................................... 156

Updating private keys and operator cards ............................................................................................................... 158

Troubleshooting nCipher with CA CEM .................................................................................................................... 158

Chapter 6: Using Smart Card Authentication with CA APM 161

About using smart cards with CA APM ..................................................................................................................... 161

Smart card verification options ......................................................................................................................... 162

Smart card authentication components ........................................................................................................... 162

10 Security Guide

Understanding SCARVES ................................................................................................................................... 163

How CA APM authenticates using smart card data .......................................................................................... 164

Setting up CA APM for smart card authentication ................................................................................................... 165

Smart card authentication requirements ......................................................................................................... 166

Extracting and installing SCARVES components on Windows ........................................................................... 167

Loading certificates ........................................................................................................................................... 168

Encrypting certificate passwords for keystores ................................................................................................ 170

(Optional) Loading CRL files .............................................................................................................................. 171

Configuring the Enterprise Manager to use SCARVES ...................................................................................... 171

Configuring the SCARVES wrapper .................................................................................................................... 172

Configuring SCARVES......................................................................................................................................... 172

Starting and stopping SCARVES ......................................................................................................................... 181

Verifying smart card installation ....................................................................................................................... 182

Troubleshooting CA APM smart card authentication .............................................................................................. 183

SCARVES fails to start ........................................................................................................................................ 183

OCSP validation fails .......................................................................................................................................... 185

CRL validation fails ............................................................................................................................................ 185

OCSP server is not responding .......................................................................................................................... 186

LDAP server is not responding .......................................................................................................................... 186

Received CRL errors .......................................................................................................................................... 187

Received user not in LDAP error ....................................................................................................................... 188

Received connection refused error ................................................................................................................... 188

Received LDAP not configured error ................................................................................................................. 189

A handshake exception is occurring in the Enterprise Manager....................................................................... 189

Index 191


Chapter 1: CA APM Security Overview

This chapter defines terms used when discussing security as well as CA Technologies Application Performance Management (CA APM) security options.

This section contains the following topics:

CA APM security summary (see page 11) CA APM security and permissions overview (see page 13)

CA APM security summary

CA APM uses these security mechanisms to secure CA Introscope and CA CEM:

user- and group-based authentication and authorization access to Introscope and CA CEM:

file-based Local security using a users.xml file.

For more information, see Securing Introscope using Local security (see page 34) and Local authentication and authorization for CA CEM (see page 125).

LDAP.

For more information, see Securing Introscope using LDAP (see page 45).

CA EEM.

For more information, see Securing Introscope using CA EEM (see page 57) and CA EEM authentication and authorization for CA CEM (see page 117).

Note: CA APM provides the EEM 8.4 SP4 SDK, and is certified with EEM server versions 8.4 SP4 and later.

Also see these CA EEM guides, which are included with the CA EEM application for download from the CA Support site:

CA Embedded Entitlements Manager Getting Started Guide

CA Embedded Entitlements Manager Release Notes

CA APM security summary

12 Security Guide

Enterprise Manager security:

public and private keys for secure authenticating between the Manager of Managers (MOM) and Collectors. For more information, see Configuring public and private keys for secure authentication (see page 28).

user authorization required for securing a connection to the Enterprise Manager.

For more information, see How Introscope checks security (see page 33).

communication between the Collectors and MOM is obfuscated.

configuration properties for secure communications between Enterprise Managers and browsers.

For more information, see Restricting Enterprise Manager access via HTTPS only (see page 139) and Configuring the Enterprise Manager web server in the CA APM Configuration and Administration Guide.

configuration properties for secure communications between an agent and an Enterprise Manager.

For more information, see the CA APM Java Agent Implementation Guide or the CA APM .NET Agent Implementation Guide.

configuration properties to allow specific users to see specific Introscope domains.

For more information, see Defining and configuring Introscope domains (see page 21) and About Introscope domains and security (see page 31).

configuration properties to allow specific users to shut down specific Enterprise Managers.

For more information, see Configuring Enterprise Manager server permissions (see page 44).

configuration properties to allow specific users to see specific business services and frontends on the application triage map.

For more information, see Securing the application triage map (see page 103).

configuration properties to allow specific users to perform dynamic instrumentation.

For more information, see Configuring Introscope domain permissions in domains.xml (see page 40).

configuration properties to allow specific users to perform thread dumps.

For more information, see Configuring Introscope domain permissions in domains.xml (see page 40).

CA APM security and permissions overview


CA CEM security:

root password protection for the Windows or Linux machine on which the TIM is installed.

For more information, see the topic Installing the Operating System for a new TIM in the CA APM Installation and Upgrade Guide.

configuration properties to secure communications between the Enterprise Managers and TIMs.

For more information, see Configuring TIM communication via HTTPS (see page 139).

CA CEM data in the APM database is encrypted and meets FIPS compliance. For more information, see FIPS 140-2 compliant encryption (see page 136).

APM database security:

password protection for the APM database.

For more information, see the topic Changing the PostgreSQL database passwords in the CA APM Installation and Upgrade Guide.

secure a connection to the Enterprise Manager.

For more information, see information about setting an encrypted password in the tess-db-cfg.xml file in the CA APM Installation and Upgrade Guide.

CA Introscope and CA CEM applications monitoring:

user authorization is required for business service based security. For more information, see Default CA EEM CEM access policies (see page 120) and the CA APM Configuration and Administration Guide.


CA APM security, which consists of authentication and authorization, allows individual users and user groups (groups), which are specified sets of users (such as Application Administrators, System Administrators, or Analysts), to securely log into Introscope and CA CEM. Permissions allow users and groups to perform specific Introscope tasks.

About user authentication

Authentication is the mechanism that securely identifies users. Authentication provides Introscope and CA CEM with answers to questions such as:

Who is this user?

Is this user really who they are representing themselves to be?


14 Security Guide

Authentication systems depend on a unique bit of information known only to the individual being authenticated and the authentication system. In order to verify a users identity, the authenticating system typically challenges the user to provide the unique information. If the authenticating system can verify that the information presented is correct, the user is considered authenticated.

About user authorization

Authorization is the mechanism by which a system determines the level of access a particular authenticated user should have to secured resources (such as applications, pages, and data) controlled by that system. In other words, authorization is the process of checking if a user has permission to perform an action on a resource.

An access policy grants permission to specific users or groups to perform an action on a set of resources of a given type.

For example, a database management system might be designed to provide certain individuals with the ability to retrieve information from a database but not change data stored in the database, while giving other individuals the ability to change data. Authorization systems grant these permissions by providing answers to questions such as:

Is user X authorized to access resource R?

Is user X authorized to perform operation P?

Is user X authorized to perform operation P on resource R?

About security realms

A security realm defines a source of users, user groups, and access policies that is responsible for authenticating, authorizing, or authenticating and authorizing users.



You configure one or more security realms for CA APM security in the realms.xml file. Introscope and CA CEM use the security realms configured in realms.xml to decide how to authenticate and authorize users. When a user logs in to either Introscope or CA CEM the application being logged in to checks each security realm in the order defined in realms.xml. The application checks to see whether a user with the given ID exists. The authentication succeeds If the user password supplied matches the value that is provided for the specific security realm. If one of these conditions is in effect, authentication fails:

No user of that name exists in any of the defined realms.

The user exists in a realm but the password is wrong.

For information about configuring realms in realms.xml, see these topics:

Configuring Local authentication in realms.xml (see page 35)

Configuring LDAP authentication in realms.xml (see page 47)

Configuring CA EEM authentication in realms.xml (see page 61)

You can deploy Introscope security using one or any supported combination of these three security realms:

Local XML files (Local): Local security consists of Local authentication and authorization using XML files stored in the Enterprise Manager in the /config directory.

For Local authentication, an XML file is used to store the username and password information locally on each Enterprise Manager. The default filename is users.xml. At runtime, Introscope checks the Local file (users.xml) to authenticate CA APM users.

For Local authorization, Introscope stores two XML files locally on each Enterprise Manager. Introscope uses domains.xml for domain permissions and server.xml for server permissions. At runtime, Introscope checks the Local files (domains.xml and server.xml) to authorize CA APM users.

Introscope provides Local security (see page 34) as the default.

Important: Changing the default CA APM login to Enterprise Managers from the Workstation, WebView, Web Start Workstation, or CEM console is a best practice. If this best practice is not followed and only Introscope local security is used, there is an increased chance of identity theft. For this reason CA EEM is the recommended security mechanism (see page 18).

Lightweight Directory Access Protocol (LDAP): An application protocol for querying and modifying directory services running over TCP/IP.

You can use the LDAP security realm only to authenticate CA APM users if you use Local XML files for authorization. For more information, see Securing Introscope using LDAP (see page 45).


16 Security Guide

CA Embedded Entitlements Manager (CA EEM): A CA Technologies application that allows other applications to share common access policy management, authentication, and authorization services.

Note: CA EEM security is optional for Introscope, however, CA Technologies recommends CA EEM for Introscope security for several reasons. CA EEM provides an industry standard solution, a user interface for managing users, and centralized storage that allows fine-grained permissions for authorization. If you want to secure the Introscope application triage map, deploy CA EEM.

You can deploy CA EEM to authenticate and authorize CA APM users.

You can also configure CA EEM to use LDAP for authentication and CA EEM for authorization. For more information, see Configuring CA EEM authentication using LDAP (see page 64).

This table lists the major features that Introscope security realms support.

Supported features by security realm CA EEM LDAP Local

Centralized security server shared by multiple Enterprise Managers

Yes Yes No

Security realm is always available No No Yes

Runs in the Enterprise Manager, so it's always available.

Supports failover Yes Yes Not applicable

Integrated with SiteMinder Yes No No

Supports fine-grained permissions? Supports these fine-grained permission types:

Application triage map permissions.

Business-service-based security

Flexible CA CEM permissions

Yes Not applicable No

Industry standard solution Yes Yes No

Allows for auditing Yes Yes No

Includes a user interface for managing users Yes Yes No

Includes a user interface for managing access policies Yes Not applicable No



You can deploy CA CEM security using one or any supported combination of these two security realms:

Local XML files (Local): Local security consists of Local authentication and authorization using XML files stored in the Enterprise Manager in the /config directory.

For Local authentication and authorization, an XML file is used to store the username and password information locally on each Enterprise Manager. Four default CEM security groups and the users belonging to these groups are also defined here. The default filename is users.xml. The authorization check is based on the membership that is defined for four default security groups. At runtime, the Local file (users.xml) is used for authentication and authorization of CA CEM users.

Introscope provides Local security as the default.

CA Embedded Entitlements Manager (CA EEM): A CA Technologies application that allows other applications to share common access policy management, authentication, and authorization services.

Note: CA Technologies recommends CA EEM for CA APM security for several reasons. CA EEM provides an industry standard solution, a user interface for managing users, and centralized storage that allows fine-grained permissions for authorization.

You can deploy CA EEM to authenticate and authorize CA APM users.

Configure CA EEM authentication using CA SiteMinder (see page 65) and CA EEM for authorization.

Configure CA EEM for authentication only, and Local XML files for authorization (see page 101).

For more information about CA EEM, see Securing Introscope using CA EEM (see page 57).

CA APM provides single login capability. Users who are permitted to access both CA CEM and Introscope can navigate between these two applications without being prompted to log in again. Upon CA CEM or Introscope user authentication, CA APM gets the user identity and the name of the realm that authenticated the user. Introscope uses this information to obtain the groups to which the user belongs. Then CA APM uses one of these methods to authorize the user:

For CA EEM, the user access policy.

For Local security, membership in one or more CA CEM security user groups.


18 Security Guide

In setting up CA APM security, your organization must determine which single or hybrid security realm to deploy. To allow CA APM users to access Introscope, deploy either the Local or CA EEM realm.

Note: CA Technologies recommends that you deploy both CA EEM authentication and authorization. For more information, see Benefits of securing CA APM using CA EEM (see page 18).

Benefits of securing CA APM using CA EEM

CA Technologies recommends that you deploy CA EEM for CA APM security because CA EEM provides these features:

a common, shared approach to manage user identities and access policies

Centralized CA APM security

Because CA EEM authentication allows multiple Enterprise Managers to share the same CA EEM server, you can deploy centralized CA APM security.

Effective access and entitlements access management

Business service based security in which you can use access policies to control which CA CEM security groups have access to a business service and its associated data.

Application security cannot be limited to who can access what application. To be effective, security policies must also enforce the specific actions each user can perform on which resources within the application after they have gained access. CA EEM provides a standard means for organizations to implement flexible and granular authorization policies in their business application portfolios.

In-process authorization checks entitlement policies are securely cached in the Embedded Entitlements Client portion of the application, then evaluated and executed locally within the application. This enables the enforcement of access policies for offline applications.

Separation of application-specific policies CA EEM segregates application-specific policy data in its central repository to ensure separation of policies and administrative controls while enabling application management flexibility.

Single Identity Repository

CA EEM includes a repository that can be used as the single authoritative source of user identities. As an alternative, this single source can be an external directory such as Microsoft Active Directory, Novell eDirectory, or SunONE Directory.



Enterprise integration

You can deploy CA EEM along with other CA security solutions to achieve consistent Identity and Access Management (IAM) across a complex suite of business applications. This requires security tools like CA EEM that are adaptable, flexible, manageable, and available in the current development environments.

CA SiteMinder integration

Native integration allows Embedded Entitlements Client applications to access user and group information from the user stores CA SiteMinder is configured to use, authenticate using CA SiteMinder credentials, and support single sign-on with CA SiteMinder web applications.

SDK in C#, C++ and Java

CA EEM supports development environments in C#, C++ and Java. It is fully documented with C#, C++ and Java references for its authentication, authorization, event management and administrative APIs. It includes sample code and XML scripts plus tutorials on how to embed its security functions into applications.

Administration web UI

CA EEM minimizes the cost of establishing and maintaining application security policies, user stores and audit rules by providing a single, web-based management interface. By externalizing security policy administration from the application itself, you can maintain consistent security levels as your business requirements evolve without re-developing application code.

Shared web UI

CA EEM provides an out-of-the-box web UI that is shared among all applications for managing users and groups and for defining and managing access policies. Alternatively, you can use the CA EEM SDK to embed administrative UI components into custom web pages.

Administrative scoping

You can limit administrator permissions to viewing or working on only certain applications, users, resources, or policies.

Permission checking

You can test security policies and view detailed policy debug information to ensure they have the desired outcome before making them live.


Chapter 2: Defining and configuring Introscope domains

This chapter contains information about defining and configuring Introscope domains before you set up Introscope security. There is also information about setting public and private keys for secure authentication between the MOM, Collectors, and Workstations.


Defining and configuring Introscope domains (see page 21) Configuring public and private keys for secure authentication (see page 28)

Defining and configuring Introscope domains

Introscope uses domains to partition agents and monitoring logic to define which CA APM users can see what information. You map Introscope agents to a domain using a Perl5 regular expression in the domains.xml file, which is located in the /config directory. You use domains.xml to define your domains regardless of which security realm you are using.

In addition to configuring domains, youll also configure domain permissions when setting up Introscope security. For Local security, youll configure domain permissions in the domains.xml file. For more information, see Configuring Introscope domain permissions in domains.xml (see page 40). If you deploy CA EEM for Introscope security, the Enterprise Manager ignores domain permissions in domains.xml, and you configure them instead in CA EEM. For more information, see Creating and deleting CA EEM APM domain resource access policies (see page 89).

Domain types

There are two types of domains in Introscope:

SuperDomainThe SuperDomain is the superset domain that contains all user-defined domains in the system. All agents are visible in the SuperDomain, but may also appear in user-defined domains. The default Introscope configuration contains only the SuperDomain. If you dont configure any other domains, all agents are mapped to the SuperDomain.

User-defined domainYou define new domains in the domains.xml file, which is located in the /config directory. The domains.xml file provides mappings of domain names to regular expressions.


22 Security Guide

Rules for defining domains

The rules for defining domains in the domains.xml file are:

Domain defining must follow valid XML file rules.

Domain names are case-sensitive.

Any domain must be placed inside the root XML domains element.

You may have multiple agent mappings within a domain or SuperDomain. If a domain is configured to match an agent, then that agent maps to that domain, and is also visible from the SuperDomain.

Note: When initiating a Transaction Trace, such agent will be attached to a user-defined domain in the Transaction Trace window.

An agent always maps to the first domain to which is it is assigned. If no domain is assigned, the agent maps to the SuperDomain. If a user-defined domain is assigned, the agent maps to the user-defined domain.

If you do not alter the current SuperDomain Agent mapping (by default it is configured to match all agents), Introscope places any newly-defined domains before the tags.

Introscope places agents that do not match any mappings (either due to mistakes in the regular expressions in the domains.xml file, or other issues) in the SuperDomain.

Use Identical domains.xml Within and Across Clusters

Understand these important domains.xml rules when deploying a MOM and Collectors within a cluster and optional CDVs in and across clusters.

Important! Do not have differing domains.xml files for the MOM, Collectors, and CDVs within and across CA APM clusters.

The MOM can handle differing domains within the cluster for live agents (agents presently sending data to the cluster). However, having differing domains for historical agents on the MOM and Collectors can cause inconsistency in the MOM view of historical data. In such mixed-domain clusters, historical agents on Collectors are not tracked, so their data does not display in Workstation graphs made through the MOM unless you explicitly mount the historical agents. To avoid this situation, CA Technologies strongly recommends that you place the identical domains.xml file on the MOM and all the Collectors in a cluster. This allows live and historical agent data to be visible at all times from the MOM Workstation without mounting historical agents to view historical data on a Workstation associated with a specific Collector.



If you are deploying a Cross-cluster Data Viewer (CDV), the CDV domains.xml file must contain these domains:

All domains for all the Collectors to which a CDV connects.

All domains across all clusters containing Collectors from which the CDV gathers data.

If a domain exists in a Collector domains.xml file and is missing from the CDV domains.xml file, then the following occur:

CDV does not gather data for the missing Collector domain.

CDV Workstation does not display data from the missing Collector domain.

Defining and Mapping Agents to a Domain

You use the domains.xml file to define domains and map agents to a domain.

Follow these steps:

1. Navigate to the /config directory.

2. Open the domains.xml file.

3. Define a domain using the rules for defining domains (see page 22) and these properties.

name

The name of the domain

The rules for this property are:

Alphanumeric characters only, and _ and -

No spaces are allowed

description

A short description of the domain

Any characters except quotation marks are allowed.

Note: All XML tags are case-sensitive.


24 Security Guide

4. Repeat step 3 for any additional domains.

5. Make sure the SuperDomain mapping is defined at the end of the domains.xml, which allows domains.xml to map agents into specific domains before mapping agents to the SuperDomain.

For example, if the following SuperDomain mapping is placed at the beginning of domains.xml, then all agent are placed under the SuperDomain before the remainder of the XML file is processed.

By placing this SuperDomain mapping at the end of the domains.xml, the SuperDomain catches all unmatched agents.

6. Save and close the domains.xml file.

7. Restart the Enterprise Manager so it can load the new domain or domains.

Note: If there are syntax or other errors in the domains.xml file, the Enterprise Manager does not start.

domains.xml syntax for new domains

The syntax for a domain is:

Associating management modules with domains

When you create new management modules, you can choose the domains that will contain them.

You associate management modules with domains by creating directories that correspond to the names of the domains you defined in domains.xml, then moving the management modules into the new directories.



Follow these steps:

1. In the /config/modules directory, create a directory that corresponds to the domain name you created in the previous section.

For example, if you defined a domain named "PetstoreA," in this step, you would create a directory also named PetstoreA, as in the following example:

/config/modules/PetstoreA

Note: The domain directory must match the name defined in the domains.xml file exactly (spelled correctly and also matching in case) or any management modules that reside in the directory will not be loaded.

2. Move the desired management module from the /config/modules directory into the new directory you just created.

3. Restart the Enterprise Manager so it can load the new domains.

Adding sample management modules to newly defined domains

When you define a new domain, it does not contain any management modules. If you want the newly defined domain to show the default sample dashboards, you need to copy the Sample Management Module into the newly defined domain.

Follow these steps:

1. Navigate to the /config/modules/directory.

2. Copy the SampleManagementModule.jar file to the appropriate modules directory in the newly defined domain.

For example, if you defined a domain called Petstore A, you would copy SampleManagementModule.jar into this directory:

/config/modules/PetstoreA

3. Restart the Enterprise Manager to load the new management module.

Important! The Sample Management Module copied into the new domain is not linked in any way to the original Sample Management Module. Any changes to the original Sample Management Module will not be reflected in any copies of the Sample Management Module in other domains, and vice versa.


26 Security Guide

Changing the domain mapping of an agent

Remapping an agent to a different domain, (either after deleting a domain or merging two domains), has the following ramifications:

If an agent mapped to a deleted domain is not reassigned and is still reporting, it will appear under the SuperDomain.

If an agent has associated SNMP collections, the SNMP MIB will have to be republished.

When an agent is moved into a different domain, all shutoff information within that agent is lost.

Deleting a domain

You might need to delete a domain when you:

assign an agent to a different domain

merge two domains

Follow these steps:

1. Shut down the Enterprise Manager.


3. Delete the domain from the domains.xml file.

4. If necessary, reassign any mapped agents to different domains.

5. Delete the corresponding domain directory from the /config/modules directory.

6. Restart the Enterprise Manager.

Merging two domains

Merging two domains involves merging all agent mapping information into one domain, and moving any associated management modules under one domain.

Follow these steps:

1. Shut down the Enterprise Manager.

2. Open the domains.xml file in the /config directory.

3. Under the source domain (for example, Domain A), copy the agent mapping XML code information.

4. Under the target domain (for example, Domain B), paste the agent mapping XML code information.



5. Delete agent mapping XML code from the source domain (for example, Domain A).

6. Move any management modules from the source domain (for example, Domain A) directory in /config/modules/ to the target domain (for example, Domain B).

Note: If any management modules already exist in the target domain directory with the same name as the ones you are moving over, you will need to rename the management modules from the source domain. If two management modules with the same name exist, the Enterprise Manager will not start.

7. Delete the source domain from domains.xml.


Cloning domains between different Introscope installations

Carry out this procedure if the target installation domain configuration is exactly the same as the source installation. (That is, if all domains defined in the domains.xml file are going to be exactly the same.)

Follow these steps:

1. Copy the /config/domains.xml file in the source installation over to the same directory in the target installation.

2. Copy the /config/shutoff/MetricShutoffConfiguration.xml, if it exists, in the source installation over to the same directory in the target installation.

3. Copy the contents of the /config/modules/ directory from the source installation to the target installation.


Moving a domain between non-cloned installations

Carry out this procedure when you want to move a domain between non-cloned installations if the domain configurations between the old and new installations vary slightly.

Follow these steps:

1. Open the domains.xml file in the /config directory in the source installation.

2. Copy the domain information.

3. Open the domains.xml file in the /config directory in the target installation.

4. Copy the domain information into the domains.xml file.

Configuring public and private keys for secure authentication

28 Security Guide

5. In the target installation, create new management module directories that correspond to those in the source installation in the /config/modules directory.

6. Copy any management modules that belong to the domain you are moving over and paste them into the corresponding domain directories.

7. Delete the domain from the source installation.


Agent failover and user/domain configuration

If you use the agent failover functionality and have users and passwords defined, verify that the domains.xml, server.xml, and users.xml files are in sync across the specified failover Enterprise Managers.

For more information on agent failover, see Configuring Agent Failover in the CA APM Java Agent Implementation Guide or the CA APM .NET Agent Implementation Guide, as appropriate to your environment.


In a clustered environment the communication protocol between the MOM, Collectors, and Workstations use public and private keys for secure authenticating.

Note: The public and private keys are used only to secure passwords when logging-in. To secure all communications requires SSL.

About the default Collector private key

Each Collector uses a private key for decrypting the password that the MOM uses to connect. The public key and private key must be a matched set. The private key for a Collector Enterprise Manager is defined in the introscope.enterprisemanager.clustering.privatekey property in the IntroscopeEnterpriseManager.properties file.

The default value is

config/internal/server/EM.private



You do not need to reconfigure the private key unless you want to generate a new public and private key set for the Collector for added security. For more information about reconfiguring the private key, see Generating a new public and private key set (see page 29). For more information about the introscope.enterprisemanager.clustering.privatekey property, see the CA APM Configuration and Administration Guide.

Note: CA APM public and private keys do not expire.

Generating a new public and private key set

To make your CA APM environment more secure, you can generate a new public and private key for each Collector, place the public keys on the MOM, and update the MOM's Collector properties.

Follow these steps:

1. Navigate to an Introscope installation directory.

2. At a command prompt, type this command:

java -classpath

product\enterprisemanager\plugins\com.wily.introscope.em.client14_9.5.0.jar;l

ib\CLWorkstation.jar;product\enterprisemanager\configuration\org.eclipse.osgi

\bundles\24\1\.cp\lib\WilyBouncyCastle.jar

com.wily.util.encryption.KeyGenerator EM.public EM.private

3. If you generate new keys for a Collector, copy the public key to the location specified in the introscope.enterprisemanager.clustering.login.em1.publicKey property in the MOMs IntroscopeEnterpriseManager.properties file.

Note: This step does not apply if you are generating new keys for a MOM.

4. Copy the public and private keys into the Enterprise Manager installation at \config\internal\server.


Chapter 3: Securing Introscope

This chapter contains information about configuring the authentication and authorization mechanisms that you can deploy to provide Introscope security and permissions. It also describes application triage map security and Introscope SSO.


Introscope security and permissions overview (see page 31) How Introscope checks security (see page 33) Securing Introscope using Local security (see page 34) Securing Introscope using LDAP (see page 45) Securing Introscope using CA EEM (see page 57) About Introscope single sign-on (SSO) (see page 102) Securing the application triage map (see page 103) Troubleshooting Introscope security (see page 105) Introscope security mechanisms (see page 107)

Introscope security and permissions overview

Introscope security, which consists of authentication and authorization, allows individual users and user groups (groups), which are specified sets of users (such as application administrators, system administrators, or analysts), to securely log into Introscope. Permissions allow users and groups to perform specific Introscope tasks.

For background about Introscope security, see CA APM security summary (see page 11).

About Introscope domains and security

Introscope uses domains to partition agents and management logic to define which users can see what information. You map agents to a domain using a Perl5 regular expression in the domains.xml file.

After you map agents to domains, you define and grant domains permissions. During the authorization process, Introscope performs permissions checks.

For information about setting up Introscope domains, see Defining and configuring Introscope domains (see page 21).

Introscope security and permissions overview

32 Security Guide

About configuring Introscope permissions

In Introscope, permissions determine what tasks users or groups can perform including configuring monitoring logic in the Workstation and handling Enterprise Manager administration tasks. You define Introscope permissions for domains and the Enterprise Manager. Then you grant users and groups permissions to either domains or the Enterprise Manager or both.

Domain permissions and the Investigator tree

The Investigator tree looks different to users or groups having different domain permissions:

Users or groups with at least read rights for the SuperDomain permission can view the contents of all defined domains in the Investigator tree.

Users or groups with permissions for multiple domains will see domain information for those domains in the Investigator tree.

Users or groups must have at least read permission for at least one domain, otherwise they will not be able to log into the Workstation or WebView to view the Investigator tree and console.

You configure permissions for Local authorization using domains.xml and server.xml and configure permissions for CA EEM authorization using the Safex tool or the CA EEM user interface. For more information about setting permissions, see these topics:

Configuring Introscope domain permissions in domains.xml (see page 40)

Configuring Enterprise Manager server permissions (see page 44)

Configuring CA EEM authorization (see page 66)

Migrating from Local to CA EEM security (see page 100)

Introscopes default security configuration

Introscope provides a default security configuration in the realms.xml file. Local XML files (located in the in the /config directory), which are used for both authentication and authorization, are Introscopes default security realm. To use the default security configuration, see Securing Introscope using Local security (see page 34).

If Introscopes default security configuration does not meet your requirements, you can configure realms.xml to use CA EEM, LDAP, or an appropriate combination of the supported realms for authentication and authorization.

How Introscope checks security


You may want to configure Introscope security for example by:

Changing the default configuration settings for Local security. For more information, see About configuring Local authentication (see page 34).

Replacing Local security authentication with an LDAP server for authentication. For more information, see Securing Introscope using LDAP (see page 45).

Replacing Local security with CA EEM authentication and authorization. For more information, see Securing Introscope using CA EEM (see page 57).

How Introscope checks security

Introscope starts every security check by determining the security realm that your organization has configured. Once Introscope knows that you have implemented, for example, CA EEM authentication with SiteMinder authorization, or LDAP authentication with Local authorization, Introscope then performs the appropriate security and permissions checks based on your security implementation.

Introscopes general security and permissions check process consists of these steps:

1. Starts authentication by checking realms.xml to determine the security realm and by getting some user information.

2. Finishes authentication by getting users, groups, and user-group mappings locally in the users.xml file, from the LDAP server, or from the CA EEM server.

Note: If you have set up CA EEM integration with an LDAP server, you can use LDAP for authentication and CA EEM for authorization. For more information, see Configuring CA EEM authentication using LDAP (see page 64).

Note: If you have set up CA EEM integration with SiteMinder, you can use SiteMinder for authentication and CA EEM for authorization. For more information, see Configuring CA EEM authentication using CA SiteMinder (see page 65).

3. Starts authorization by getting passwords either locally on the Enterprise Manager in the users.xml file or in CA EEM.

4. Finishes authorization by getting domain and Enterprise Manager server permissions either locally on the Enterprise Manager from the domains.xml and server.xml files or from CA EEM.

Securing Introscope using Local security

34 Security Guide


Now that you have some background in Introscope security, you are ready to plan your security deployment.

Follow these steps:

1. If needed, configure the Local realm as a security realms in realms.xml.

Note: The Local realm is the Introscope default ream in realms.xml.

2. Set up users and groups with passwords in users.xml.

3. Assign domain permissions in domains.xml.

4. Assign Enterprise Manager server permissions in server.xml.

5. Maintain Introscope security by adding, deleting, editing CA APM groups, users, domains, and servers with their associated permissions as needed.

About configuring Local authentication

Local authentication is used by default in Introscope. If Local authentication is used, CA APM users and passwords are stored in users.xml.

However, user details such as email and phone number are not maintained in the Local realm. In addition, the Local realm cannot maintain two users having the same name and same password, however can maintain two users having the same name but different passwords. If there are two users with the same name and different passwords, the Local realm sees these as separate users.

For more information about these defining users, groups, and generating passwords, see Configuring CA APM users and groups in users.xml (see page 37).

Local authentication changes are dynamic: when a CA APM user attempts to log in, passwords are compared to users.xml file each time an authentication request is made.

If you are migrating Introscope users from a previous Introscope installation, do not change the name or location of the users.xml file until after migration is complete.



Configuring Local authentication in realms.xml

Follow these rules when configuring realms.xml:

Important! The Enterprise Manager will not start if any of these rules are not met.

The value of descriptor= is case-sensitive.

For example, descriptor=Local Users and Groups Realm is different from descriptor=local users and groups realm.

For Local realms, the value of descriptor= must be Local Users and Groups Realm.

In the case of multiple realms, the value of id= in the realms tag has to be unique for each realm. For example:

EiamAdmin


36 Security Guide

3. Set this property as appropriate.

usersFile

The file name relative to the /config directory where users are stored. By default, this is users.xml.

Note: This file also contains group definitions.

Note: For information about using multiple files for security realms, see About using multiple files for security realms (see page 36).

4. Save changes to the realms.xml file, and restart the Enterprise Manager to apply the changes.

realms.xml syntax with Local authentication enabled

Here is example code from a realms.xml file.

users.xml

About using multiple files for security realms

If you have only one file listed in realms.xml file for all your security realms, you can ignore this topic.

You may set up multiple realms if, for example, you want a default realm that gives a user basic permissions and a second realm that gives different permissions. Or your organization may have two LDAP servers, and you want to test security both of them. Or perhaps your organization has been using Local security and you want to keep it in place as you move to CA EEM.

When two files are listed as security realms in realms.xml, the first file is used during the authentication and authorization process. If you have two users named User A that have the same password, realms.xml will use the password it finds in the first file listed. For example, if you have listed users.xml before CEM45.xml, then realms.xml will have authentication performed using the password in users.xml.

In the case of Local realm user details such as email and phone number are not maintained in users.xml and CEM45.xml. In addition, the Local realm cannot maintain two users having the same name and same password. However, the Local realm can maintain two users having the same name but different passwords.



Similarly, if you have two users named User A that belong to different user groups in users.xml and CEM45.xml, then realms.xml will use the user group it finds in the first file listed. For example, lets say you have listed users.xml before CEM45.xml. In users.xml, you have a user named Admin in the CEM System Administrator user group. In the CEM45.xml, you have a user named Admin in the CEM Analyst user group. In this case, then realms.xml will use the users.xml user group, and give the user named Admin privileges associated with the CEM System Administrator user group.

Configuring CA APM users and groups in users.xml

Define a username and password for each user and group.

Note: When creating an admin user, keep in mind users and permissions are case insensitive. If a user logs in using the login name of admin or Admin, the permissions for that user role are applied.

The default CA APM user configuration defines the following users:

Admin with no password

Guest with Guest as the password

Follow these steps:


2. Open the users.xml file.

3. Define a user name using this user and group naming property.


For example, syntaxes for a user and group, see users.xml syntax for users (see page 39) and users.xml syntax for groups (see page 39).

4. Set a password for each user or group using this property.


password

The user password.

These rules apply to this property:

Any characters except quotation marks

By default, passwords are encrypted and not in clear-text or obfuscated (can optionally generate encoded passwords).

Password characters can be legal XML characters.

A password value can be empty.

Best Practice: Follow the password policies for your organization.


38 Security Guide

The passwords in the users.xml file that are used for Local authentication are stored as encrypted. You have the option of generating encrypted passwords using the MD5Encoder utility, or letting Introscope generate them automatically. The MD5 scripts that Introscope provides take input as plain text and output the encrypted form.

Follow the instructions in step 5 (Set an encrypted password manually), when these conditions apply to your situation:

You have already encrypted a number of users in users.xml.

You want to change only one or a few passwords.

Otherwise, change all user passwords back to clear text.

Follow the instructions in step 6 (Set a plain text password), when this condition applies to your situation

You are creating or changing many users and passwords at once.

5. Set an encrypted password manually.

a. Set plaintextPasswords="false" in the users.xml file.

b. Run the appropriate script located in the /tools directory.

For Windows, MD5Encoder.bat

For UNIX, MD5encoder.sh

Note: When running the MD5Encoder.sh script, use a backslash to escape any special characters in your password. For example, if your password is pa$word, place a backslash before the dollar sign ("$") character to make the script run correctly. The correct command line is: ./MD5Encoder.sh pa\$word

c. Copy the generated encrypted password, and paste it into the second line of the users.xml file.

For example,

For a syntax example, see users.xml syntax with encrypted passwords (see page 40).



6. Set a plain text password and let Introscope automatically generate an encrypted password.

a. Set plaintextPasswords="true" to the users.xml file.

Important! When you set plainTextPasswords="true", Introscope encrypts every password. Set all passwords to plain text otherwise Introscope encrypts already encrypted passwords.

b. Set the password of every user to plain text.

For example,

The next time the Enterprise Manager reads the users.xml file (either on start-up or when authenticating a user), it performs these actions:

The Enterprise Manager rewrites users.xml with the plain text passwords encrypted.

The Enterprise Manager resets the plainTextPasswords attribute to false.

7. For more users or groups, repeat step 3 to define a user name and step 4 to set a password for each user.

8. Save and close the users.xml file.

Changes to the contents of the users.xml file do not require an Enterprise Manager restart.

Note: If there are any errors in the users.xml file, the Enterprise Manager does not start.

users.xml syntax for users

users.xml syntax for groups


40 Security Guide

users.xml syntax with encrypted passwords

Configuring CA Introscope Domain Permissions in domains.xml

Permissions are applied when a CA APM user or group logs in. If changes are made while a CA APM user or group are logged in, the changes are not recognized until the next login attempt. This means if permissions are changed during a session, CA Introscope does not terminate the session.

CA Introscope permissions are dynamic; the Enterprise Manager checks the domains.xml and server.xml files whenever a login attempt is made. Thus, permissions changes can be made without restarting the Enterprise Manager.

Users are given permissions on domains in the following order:

All permissions listed in each domain that specify the user.

All permissions listed in each domain for any group to which the user belongs.

Additionally these rules are applied when accessing the domain:

The SuperDomain is treated like any other domain in terms of permissions.

Any permissions granted to a user or group with access to the SuperDomain also allows them to use these privileges in all user-defined domains.

One user or group can have multiple permissions for a single domain.

One user or group can have permissions in multiple domains.



Follow these steps:

1. Using an XML editing program, open the domains.xml file in the /config directory.

2. For each domain, define permissions for a user or group, using these properties.

Note: If a user or group has multiple permissions, use one line for each user/permission pair.

read

Users or groups can view all agents and business logic in the domain.

This permission includes tasks such as:

Viewing Investigator tree (which shows agents in the domain user has access to)

Viewing dashboards in the Workstation Console

Viewing metric and element data in the Investigator Preview pane, including default Top N Filtered Views for certain resources in the Investigator tree

Viewing any Management Module, agent, or element settings

Viewing alert messages

Refreshing historical data in a historical Data Viewer, and zoom in and out

Changing historical date range options for historical Data Viewer

Showing/Hiding metrics in a graph

Moving metrics in a Data Viewer to the back or front

Changing group and user preferences (setting a home dashboard, displaying management module names with dashboard names)

Note: Users or groups with read permission are able to see all commands in the Workstation. However, the commands that they do not have access to are disabled.

write

A user or group with write permission can do everything permitted by read permission can, and can also:

view all agents and business logic in the domain

create and edit dashboards

edit all monitoring logic in a domain

run_tracer

Users or groups can start a Transaction Trace session for an agent.

Note: This permission also requires the assignment of read permission.


42 Security Guide

historical_agent_control

Users or groups can mount and unmount agent/s.


live_agent_control

Users or groups can shut off reporting for metrics, resources, and agents within a domain


dynamic_instrumentation

User or group can perform dynamic instrumentation.

For information about dynamic instrumentation, see the CA APM Java Agent Implementation Guide or CA APM .NET Agent Implementation Guide.

thread_dump

User or group can see and use the Thread Dumps tab.

For information about using and configuring thread dumps, see the CA APM Workstation User Guide and the CA APM Java Agent Implementation Guide.

full

Users or groups have all possible permissions for the domain.


3. Repeat step 2 (For each domain, define) for any additional users or groups.

4. Save and close the domains.xml file.

When a CA APM user logs in, the Enterprise Manager checks the domains.xml file to see if the user has the appropriate domain permissions.

Note: If there are any syntax or other errors in the domains.xml file, the Enterprise Manager does not start.

Default domains.xml syntax for CA APM user and group domain permissions

In the default domain configuration:

the user or group, Admin has full permission in the SuperDomain.

the user or group, Guest has read (view only) permission in the SuperDomain.



Note: SAP user or group permissions vary slightly and are as follows:

the user or group, sapsupport has full permission in the SuperDomain.

the user or group, Admin has read (view only) permission in the SuperDomain.

the user or group, sapsupport is a member of the CEM System Administrator and Admin groups, and is therefore granted permission to access the CEM console.

Here is the syntax for configuring user or group permissions for a domain:

domains.xml Syntax for Optional CA APM Domain Configuration

The following configured domain permissions example gives domain permissions to the following users:

bsmith, full permission in HRApplication domain

fjones, read and run_tracer permissions in HRApplication domain

jlo, write permission in SuperDomain

pdiddy, read permission in SuperDomain

swonder, dynamic_instrumentation permissions

cstevens, thread dump permissions

The domains.xml file would look like the following example:


44 Security Guide

Configuring Enterprise Manager server permissions in server.xml

These server permissions are defined for activities relating to operation of the Enterprise Manager.

shutting down the Enterprise Manager

publishing MIB files

accessing the APM Status console

Follow these steps:

1. Using an XML editing program, open the server.xml file in the /config directory.

2. Define permissions for each CA APM user or group, using these properties as appropriate.


shutdown

Users or groups can shut down the Enterprise Manager.

publish_mib

Users or groups can publish SNMP collection data to an MIB.

To have an MIB to publish, a user must create an SNMP Collection. This task requires write access to the domain to which the SNMP Collection is saved.

a

apm_status_console_control

Users or groups can see the APM Status alert icon, use the APM Status console, and run APM Status console CLW commands.

Note: Users who want to view active clamp metric information in the metric browser tree must have domains.xml SuperDomain permission (see page 40).

full

Users or groups have all possible Enterprise Manager server permissions.

3. Repeat step 2 (Define permissions for each CA APM user) for any additional users.

4. Save and close the server.xml file.

Note: If there are any syntax or other errors in the server.xml file, the Enterprise Manager does not start.

Securing Introscope using LDAP


server.xml syntax for server permission

Here is the syntax for configuring user permissions for a server:

A user or group can have multiple permissions for the Enterprise Manager. To grant a multiple permissions, use one line for each user/permission or group/permission pair.

server.xml syntax for default server configuration

In the default server configuration, the "Admin" user or group has full permission.

server.xml syntax for optional server configuration

This example shows how to give different permissions to different CA APM users:

bsmith, shutdown permission

tjones, publish_mib permission

cstevens, apm_status_console_control permission

The server.xml file looks like this example:


LDAP only supports user authentication. If you deploy Introscope security so that the Enterprise Manager connects directly with the LDAP server for authentication, you must use Local security for authorization. In this case, using Local security for authorization means:

for Introscope, you must create users and groups on the LDAP server and then assign permissions in the domains.xml file.

for CA CEM, you must create users and all four default security groups on the LDAP server. For example, on the LDAP server you create the cemadmin user as well as the CEM System Administrator security group. Then you assign cemadmin as a member of the CEM System Administrator security group, thus providing cemadmin with CEM System Administrator security group permissions. For information on the four CA CEM default security groups see Menu items and privileges associated with the default CA CEM security user groups (see page 115).


46 Security Guide

Note: If you deploy Introscope security using CA

apm 9.5 security guide

Documents

ca software

ca database performance

ca copyright notices

proprietary information

applicable license agreement

software products

available copies

internal use