Securing CA NSM

Securing CA NSM

This section contains the following topics:

Role-based Security

Securing the MDB

Component-Level Security

Integrating with eTrust Access Control

Data Scoping

Communication Protocol Security

Role-based Security

CA NSM was developed with detailed security and now uses a role-based approach so that the management station is not a point of concern for today's security-conscious IT environments.

CA NSM and its options are unique in providing a security methodology that protects corporate assets and also makes the system easier to manage because CA NSM security lets you segregate security according to a user's role within the organization.

CA NSM can be secured at the following levels:

• Database security (MDB)
• CA NSM component-level security, such as securing WorldView tables, Agent Technology security, Enterprise Management security
• General product security for the primary communications protocols

Note: For information about using the Security Management component to secure CA NSM objects such as calendar and event, see the chapter "Securing CA NSM Objects."

Securing the MDB

The Management Database (MDB) maintains information about all objects in your enterprise, including their properties and relationships to other objects. You must ensure the integrity and availability of this information.

The Management Database (MDB) creates a hierarchy that you must understand so that you can access it correctly from CA NSM and its components. The CA NSM database security model uses one of the following ways to connect to the MDB, depending on which database you are using:

• For Ingres databases, private VNODES instead of an installation password.

  All connections to the MDB require a valid operating system user ID and password. That user ID must also be defined to Ingres.

• For Microsoft SQL Server databases, Microsoft SQL Server authentication or Windows authentication.

  All connections to the MDB require either a valid operating system ID or Microsoft SQL Server user ID. Different applications require each method of authentication.

This section defines the preferred way of connecting to and accessing database objects in the MDB. Topics covered include the following:

• MDB User Groups (Ingres)
• MDB User Roles (Microsoft SQL Server)
• MDB Users
• Operating System Users
• Virtual Node Names (VNODEs) (Ingres)

MDB Users (Microsoft SQL Server Databases)

For a CA NSM user to connect to the MDB, that user must be one of the following types of users:

• A valid Microsoft SQL Server user that has a default group assigned to a CA NSM Microsoft SQL Server role, such as uniadmin or uniuser at the product level or wvadmin, wvuser, emadmin, or emuser at the component level.
• A valid operating system user on the Microsoft SQL Server computer that is Windows-authenticated to Microsoft SQL Server.

A Microsoft SQL Server user can be set up with a password, or a Windows-authenticated user can be set up by a Microsoft SQL Server user who has the system administrator database role.

MDB User Groups (Ingres Databases)

User group identifiers enable the database administrator (or user that has the security privilege) to grant identical privileges to a group of users, which simplifies the task of user ID administration. A group can contain any number of users.

As part of the MDB definition, the following user groups are defined for CA NSM:

• An administrator group called uniadmin at the product level and wvadmin and emadmin at the component level.
  • Table privileges: Insert, Update, Delete, Select
  • Users assigned to these groups have the Security privilege that allows uniadmin to "impersonate" user mdbadmin, which allows WorldView and Enterprise Management tables to be owned by user mdbadmin and to grant access to other users accordingly. This security privilege is required for creating and updating WorldView classes and Enterprise Management data.
• A read-only user group called uniuser at the product level and wvuser and emuser at the component level.
  • Table privileges: Select
• For each CA NSM component, a user group could be created with grants for the tables within that subcomponent.
  • For an administrator group
  • For a read-only user group

  By default, no users are defined for these groups. These groups are available if you want to protect tables at the component level.

• Other component groups are defined for other components of CA NSM.

Note: For detailed information about administering Enterprise Management Database privileges in Ingres on UNIX and Linux operating systems, see the Inside Event Management and Alert Management guide.

MDB Users (Ingres Databases)

For a CA NSM user to connect to the MDB, that user must be one of the following types of users:

• A valid Ingres user that has a default group assigned to a CA NSM Ingres group, such as uniadmin or uniuser at the product level or wvadmin, wvuser, emadmin, or emuser at the component level.
• A valid operating system user on the Ingres server computer.

Ingres users are defined without Ingres passwords. Ingres verifies the operating system user before checking whether the user is defined to Ingres.

An Ingres user can be set up with a password, at the time the user is created or by an Ingres user who has the maintain_users privilege. This password has no connection with the operating system user's password. Ingres users with privileges can change their own passwords using the ALTER USER SQL command by specifying the old and new passwords. Only an Ingres user with the correct privileges can change another user's password. Ingres user passwords are not currently used to connect to the MDB.

Important! CA NSM components may not be able to connect if the Ingres user has been assigned a password.

An Ingres user can be set up with an expiration date. Once that date is past, the Ingres user cannot connect to Ingres until the expiration date is reset. Only an Ingres user with the correct privileges can reset the expiration date.

Note: Ingres user expiration dates are not currently used to connect to the MDB.

For security reasons, the Ingres user mdbadmin owns all database objects, does not have a corresponding operating system user ID, and should not be used by any application.

Operating System Users

CA NSM prompts you to create a CA NSM administrator account with a password (Ingres databases) or a Microsoft SQL Server account with a password (Microsoft SQL Server databases). The default is nsmadmin.

Note: The WorldView Manager component must be installed on the MDB server computer.

How You Create Additional CA NSM Administrators (Microsoft SQL Server Databases)

When you install the CA NSM Server component, you are prompted to create a CA NSM Microsoft SQL Server account with a password. You can create another user who will have CA NSM administrator privileges for the MDB.

1. Create a Microsoft SQL Server user with a password.
2. Assign the user to a default user role for the tablespace for which that user needs access.

For example:

sp_adduser 'nsmadmin', 'uniadmin'

How You Create Additional CA NSM Administrators (Ingres Databases)

When you install the CA NSM Server component, you are prompted to create a CA NSM administrator account with a password. You can create another user who will have CA NSM administrator privileges for the MDB.

1. Create an operating system user with a password.
2. Create an Ingres user using the same name.
3. Assign the user to a default user group for the tablespace for which that user needs access.

For example:

CREATE USER nsm_admin_user WITH group = uniadmin

Note: You can create an operating system user with a password expiration date, which may be a requirement for your organization. The Ingres VNODE entry on the client will not be able to connect to the server until the password entry for the VNODE is reset.

Important! For security reasons, do not create an operating system user called mdbadmin.

More information:

Ingres Virtual Node Names (VNODES)

Ingres Virtual Node Names (VNODES)

Remote connections to the MDB using Ingres use an Ingres VNODE.

During the CA NSM installation on UNIX and Linux operating systems, a VNODE called nsm_servername is created to provide connectivity to the MDB by daemons and other utilities running as root. Only processes running under the root ID have access to this VNODE.

WorldView

For WorldView on Windows, the following naming standard applies:

WV_servername

Each logical repository name in WorldView, which is created by running the Define Logical Repository utility, has a VNODE created with the same name.

When WorldView attempts to connect to the MDB, a connection dialog appears, which prompts for a server name to connect to.

The WorldView registry is scanned to look for a valid VNODE for the server and user combination. If one is found, WorldView connects with that VNODE.

If the connection fails, the connection dialog prompts for a user ID and password, and from this information the VNODE is updated and the connection is attempted again. If the connection fails again, this cycle is repeated until the connection succeeds, or the user clicks Cancel. If the connection succeeds, the VNODE is saved for subsequent connections to WorldView.

When you are using the WorldView Classic GUI (Windows), the user ID and password you provide on the Repository Sign On dialog is saved and stored in the VNODE. When you start any additional WorldView component, such as Object Browser or Severity Browser, you are not prompted again for MDB credentials because the credentials saved in the VNODE are used.

For WorldView on UNIX and Linux, most WorldView components have input parameters that let you specify the server to connect to and the user name and password to use. Components that are run without specifying the server use the DefaultRepository registry entry, which is set at installation, to determine the server.

More information:

How You Create Additional CA NSM Administrators (Ingres Databases)

Component-Level Security

Security at the product level helps keep unauthorized users from causing problems with key infrastructure components. Component level security focuses on improving the following two aspects of security:

• Unintentional problems caused by users having more access or authority than required to do their jobs
• Efficiencies that can be gained by having users presented only with the information required to do their jobs properly

CA NSM security provides about 100 rules, 9 roles (also known as user groups), and about 100 assettypes. CA NSM provides embedded security, which is a DENY mode security engine that, by default, is turned on. The following components use CA NSM embedded security:

• Calendar Management
• Embedded Security (protects itself)
• Job Management Option
• Alert Management
• Notifications Services
• Agent dashboards
• Web Reporting Service
• Unicenter Configuration Manager
• Event Management
• Management interfaces, which include Management Command Center, Unicenter Management Portal, Unicenter Browser Interface, and Unicenter for Pocket PC (logon only)

  Note: Security is not installed by default, nor is it a selectable option. If you select any of the components that use security, the installation asks if you would like to enable security, and installs security if you answer "yes.” For Windows, the question appears only when you are installing CA NSM in non-Express mode.

Without specific "permit" security rules for a given role or user, access to a component is denied. Default permit rules are created and activated for each of the components that uses embedded security for the following roles and types of access:

• Systems administrators (SYSADMIN) have full access to most components. By default, these users include only "administrator," "root," and the installing user.
• Network administrators (NETADMIN) have full access to most components. By default, these users include only "administrator" and "root."
• Operators (OPERATOR) have read access to most components. By default, these users include a "dummy" user for place-marker purposes.
• Application administrators (APPADMIN), database administrators (DBADMIN), mail administrators (MAILADMIN), web administrators (WEBADMIN), and business users (USER) have no users assigned and no access to most components. By default, these users include a "dummy" user for place-marker purposes.
• General users (PUBLIC) have no users assigned.

Exceptions to the above rules are as follows:

• The embedded security component allows full access for only systems administrators.
• Unicenter Management Portal access varies by role. For example, application administrators may have access that systems administrators do not.
• Logon access for most user interfaces, such as Unicenter Management Portal, Unicenter Configuration Manager, Unicenter Browser Interface, Management Command Center, and Unicenter for Pocket PC, is available for all roles. By default these roles include "administrator," "root," and the installing user.
• Windows embedded security does not provide granularity for some components, such as Calendar Management, Event Management, Security Management, and the Job Management Option. These components have access that is all or nothing, and therefore, systems administrator, network administrator, and operator roles have identical access.

What is Security Management

Security Management provides a policy‑based security system that protects against unauthorized access to vital CA NSM components and products.

To protect your management systems, you must augment physical security with software that can do the following:

• Prevent unauthorized individuals from gaining access (logging on) to your systems being managed by CA NSM.
• Ensure that only authorized personnel can access management data and resources.
• Protect against access abuse by users with administrative privileges.
• Provide a way to review and audit the use of data and resources.

Enhanced and simplified Security Management means reduced errors, greater responsiveness, and increased flexibility in meeting the needs of your organization. Most importantly, it means you can implement thorough and effective security policies without disrupting your work environment.

Note: The CA NSM Security Management components no longer provide file access authorization. If you need this type of additional security, you may want to evaluate eTrust Access Control. For more information, see Integration with eTrust Access Control.

Administrators or Power Users Group

Certain CA NSM components and applications update configuration information. To run such components or applications, a user must be a member of the Windows Administrators or Power Users group, or root on UNIX/Linux. These components include the following:

• Classic Discovery (dscvrbe)

  Note: On UNIX and Linux, members of the Power Users group that have update, delete, insert, and select privileges can also run dscvrbe.

• 2D Map (catng2d)
• Repository Import/Export Utility (trix)
• Define Logical Repository utility (iirepdef)
• Most WorldView Classic GUI user interfaces

How You Change the CA NSM Administrator Password On Windows

When CA NSM is installed on Windows, a prompt appears that lets you create a CA NSM operating system user ID and password.

To change the operating system password for this account, follow these steps:

1. Stop all the services on the WorldView server (the MDB server) and the remote server where Unicenter Services are running.
2. Change the Unicenter Administrator Password on the WorldView server by running the modp command.
3. Run the modp command on all servers that contain CA NSM services that connect to the WorldView tables in the MDB on the server where you changed the password.

Note: For more information about running modp, see the online CA Reference.

Change the Password for the Severity Propagation Engine User Accounts (Windows)

When CA NSM is installed, the Severity Propagation Service is registered and a SeverityPropagation user account with a strong password is automatically created. A RunAs user account with the same password is also added to the dcomcfg utility. These user IDs are created so that the Severity Propagation Engine can stay connected when the user logs off of the computer.

You may want to change the password for these user accounts for security reasons. To do this, you must deregister the Severity Propagation Service and re-register it with a new password.

Important! Failure to deregister and re-register the Severity Propagation Service correctly will result in a catastrophic failure of many CA NSM subsystems. Any errors that occur during registration and deregistration are written to the application event log in the operating system's event viewer.

To change the password for the SeverityPropagation and RunAs user accounts

1. Stop the Severity Propagation Service (sevprop.exe) using the Windows Service Manager.
2. Run the following command from a command line:

   sevpropcom /unregister
   

   The Severity Propagation Service is removed from the dcomcfg utility and the SeverityPropagation user account is removed.

3. Run the following command from a command line:

   sevpropcom /regserver
   

4. The Severity Propagation Service is re-registered and the SeverityPropagation user account is created with a proprietary password. The password conforms to Microsoft's most rigorous password complexity methodology, using Microsoft's LSA policy to ensure the security of the password.

   Note: You can use the sevpropcom /regserver /password command to register the DCOM server with a user-defined password. You must ensure that all password requirements are met if you enter your own password.

5. Start the Severity Propagation Service (sevprop.exe) using the Windows Service Manager.

More information:

Severity Propagation Service

How You Change File Privileges on Microsoft Windows 2003 Server

Microsoft Windows 2003 Server has strict security controls in place for user accounts other than the user under which a product was installed. If you installed CA NSM while logged on as a particular user, for example, administrator, but want to run CA NSM using another user account, you may need to allow write permissions to the other user account from the administrator account.

1. Log in as the user that installed CA NSM, for example administrator.
2. Use Windows Explorer and navigate to the folder where you installed CA NSM.
3. Right-click the folder and select Properties.
4. Select the Security tab.
5. Click add, enter TNDUsers, and click OK.
6. In the Permissions field at the bottom of the Properties dialog, click the Allow box after the Write permission, and click OK.
7. Log off as administrator and log back in as the user that is a member of the TNDUsers group.

Run Utilities Requiring Administrator Privileges on Windows Vista

By default, Windows Vista gives administrators only standard user privileges through its User Account Control. To install CA NSM and run most CA NSM commands, admin privileges are required; therefore, you may receive an 'Access is Denied' message when trying to run utility commands from a command prompt on Windows Vista even if you are an administrator.

To override User Access Control without disabling it completely and obtain admin level privileges required to run CA NSM utilities, we recommend launching a command prompt with "Run as Administrator" on Windows Vista systems.

To run utilities requiring administrator privileges on Windows Vista

1. Right-click the Command Prompt option in the Start menu and select "Run as administrator".

   The User Account Control dialog opens asking you to confirm the action.

2. Click Continue.

   The command prompt appears with Administrator: Command Prompt in the title.

   You can run all CA NSM utilities requiring administrator privileges in this command prompt.

Create Additional Users with Administrator Privileges to Run Discovery (Microsoft SQL Server Databases)

Only nsmadmin, or the CA NSM administrator that was used to install the Ingres server on the MDB server, can run Discovery after CA NSM is installed. You may want to give other administrative users authority to run Discovery.

To create a user with administrator privileges

1. On the MDB server, create a Microsoft SQL Server user by running the following command:

   addntgroup -a "TNDUsers" -s repository_name -u "userid" -p "password" -b mdb -g uniadmin
   

   The Microsoft SQL Server user is created as a member of the uniadmin role.

2. Run the following command using the nsmadmin user and password:

   modp -r repository_name -u nsmadmin -n nsmadmin_password
   

   Note: You only need to run the modp command if Discovery is run on a new remote MDB, that is, a different MDB than the one used during installation.

   The user ID you created has the authority to run Discovery.