2.8 Assessing Your Security Requirements

SQL Server security mode

NetIQ Corporation recommends using Windows authentication on the SQL Server that hosts the QDB. Using Windows authentication simplifies several tasks when setting up permissions for users or groups to access AppManager components and features. If the SQL Server uses mixed mode authentication, users can log in to the QDB using either Windows authentication or SQL Server authentication. Then, you must communicate with users about which login account they should use to access the QDB and also configure access permissions on two separate accounts for each user or group.

For more information about the relationship between SQL Server security and AppManager, see the Administrator Guide for AppManager, available on the AppManager Documentation page. For more information about using security modes, see the Microsoft SQL Server documentation.

For the Operator Console, AppManager user roles and the AppManager-related rights to associate with each role

You use Security Manager to configure security for a QDB and control access to views and tasks in the Operator Console through AppManager roles. Every Operator Console user must be assigned a role. To help you get started, the Operator Console provides the following predefined roles:

Most organizations find it useful to modify the predefined roles or create custom roles before adding any Operator Console users. For more information about using Security Manager to manage Operator Console security, see the Administrator Guide for AppManager, available on the AppManager Documentation page.

For the Control Center console, AppManager user groups and permission sets

You use the Control Center console to manage security for the CCDB. To configure security permissions in Control Center, you must add users and user groups, define permission sets, and then assign the user groups and permission sets to management groups.

The Control Center console includes a set of default user groups you can use, modify, copy, or delete to help implement security for the console. The default user groups include the following:

You cannot copy or delete the Administrator group.

A permission set is a collection of operational and Knowledge Script permissions that defines a group of activities that can be performed and Knowledge Scripts that can be used in the Control Center console. To apply a permission set, you associate the permission set with a user group and a management group. Users belonging to that user group can perform the activities you define in the permission set for the associated management group.

The default permission sets are:

For information about the specific operational permissions granted for each default permission set, see the Administrator Guide for AppManager, available on the AppManager Documentation page.

A global permission set is a permission set associated with a user group that applies to all management groups managed by the Control Center console for the associated user group. Since global permissions apply to all management groups for the associated user group, they do not depend on association with a specific management group to take effect. The Control Center console provides a default set of global permissions:

For more information about managing Control Center security and the interaction between Control Center and Operator Console security, see the Administrator Guide for AppManager, available on the AppManager Documentation page.

Level of security appropriate for the management server and agent computers

Agent installation offers extra security options to encrypt agent-to-management server communications, or to encrypt communications and require agents to authenticate the management server. In most cases, you do not need to use these extra options, which add some overhead to production servers and the management server.

AppManager always encrypts passwords, so even without extra agent security options, only user names are sent as clear text over the network. If you require a password for access to a particular application, like SQL, the password is encrypted in a table. That encrypted password is sent to the agent, which records it locally, still encrypted. Only when a job executes will the password be unencrypted and used to gain access to the application.

To secure communication between the management server and agent computers, choose either Encrypted communications only or Authentication and encrypted communications when you install the QDB and agents. For more information about the secure communication options, see the Administrator Guide for AppManager, available on the AppManager Documentation page.

If you choose Encrypted communications only or Authentication and encrypted communications when you install the QDB and agents, AppManager implements FIPS-compliant algorithms. FIPS compliance does not affect unencrypted communications. For more information about AppManager FIPS compliance, see the Administrator Guide for AppManager, available on the AppManager Documentation page.

Although you manage secure communication separately for Windows agents and UNIX agents, all management servers and agent computers in a management site should use the same level of security. For either platform, you cannot mix security levels. For example, you cannot set some Windows agent computers to use clear text or encryption while other Windows agent computers use authentication and encryption.

Security-related information needed to run Knowledge Scripts (for example, community names, user account, or password information)

For information about security requirements for running Knowledge Scripts, see the management guide for the applicable module. Typically, you need to enter this information when you install the module for an application that requires it. For example, AppManager for Microsoft Exchange Server requires a user account, profile, and mailbox alias name.