Chapter 3 Configuration Considerations

This chapter discusses items that can adversely affect your Sun Management Center installation or upgrade. This chapter provides the following topics:

• Security Recommendations

• Management Strategies

Security Recommendations

This section provides security recommendations for Sun Management Center access, server and agent components, and security keys.

Users, Groups, and Roles Overview

Before you set up Sun Management Center users and user groups, you should understand the types of management operations that are possible so you can assign these operations to the appropriate user classes. Careful planning of user groups and roles helps ensure proper configuration management, and data integrity and security of management information and system resources.

No user may gain access to Sun Management Center without first being explicitly identified in the master access file /var/opt/SUNWsymon/cfg/esusers. To grant access to Sun Management Center, the user name must be added to /var/opt/SUNWsymon/cfg/esusers. The user may then log into Sun Management Center using the user name and password.

When a user logs in, Sun Management Center uses PAM based authentication to authenticate users. Sun Management Center controls access and defines the user privileges based on the following functional roles:

• Domain Administrators – This role is the highest-level role, which permits members to create top-level domains in a server context and to assign privileges for other Sun Management Center users within these domains. The domain administrator can create customized configurations for specific topology environments by creating specific domains and assigning user privileges for those domains. Users are considered domain administrators if the users are members of the esdomadm UNIX user group.

• Administrators – This role is the administration role for all operations outside the topology system. Administrators can perform privileged operations, including the loading of modules and the configuration of managed objects and data properties. Administrators can also specify access control at the agent and module level. This control makes this role instrumental in the establishment and maintenance of entitlement policies. Users are considered administrators if the users are members of the esadm UNIX user group.

• Operators – This role allows system users to configure their own domains and topology containers. The operator role also allows the users to configure managed objects with respect to their data acquisition and alarms, and to view management information. Although operators may enable or disable management modules, operators cannot, by default, load modules or alter access control privileges. Operators therefore represent a class of user that can effectively use the product and fine-tune its operation but who cannot affect major configuration or architectural changes. Users are considered operators if the users are members of the esops UNIX user group.

• General Users – This role is for users who are not explicitly members of the above three groups. General users are not granted extensive privileges and can by default only view management information and acknowledge alarms. The general user role is well suited for first-level support, in which problem identification, re-mediation, and escalation are the primary goals.

In large organizations, the Sun Management Center security roles are likely to map directly onto existing systems administration and support functions. For others, the process could be more involved, as the mapping between a corporate function and a product role could be less clear. In some cases, assignment of all logical roles to a single user could be warranted.

---

Note –

Specification of privileges is flexible and does not need to be confined to the four Sun Management Center security roles.

---

Sun Management Center privileges can be explicitly specified at the domain, topology container, agent, and module levels. The privileges specification can reference any arbitrary UNIX user or group, with the groups named above being used only by convention. The Sun Management Center privileges groups allow the use of existing account configurations when assigning functional roles. Although naming explicit users when assigning privileges is not recommended, the use of UNIX groups can be convenient in environments where such UNIX groups are already established.

For further information on security roles, groups, and users, see Setting Up Users andChapter 18, Sun Management Center Security, in Sun Management Center 3.6.1 User’s Guide.

Sun Management Center Internal Security

This section describes the security process that is used between Sun Management Center components.

Server-to-Agent Security

Communication between the Sun Management Center server and its managed nodes is primarily performed using the industry standard Simple Network Management Protocol version 2, employing the User Security model SNMP v2usec. The SNMPv2 mechanism is well suited to mapping the user credentials from the server layer to agent-side operations. SNMPv2 is the primary mechanism for ensuring that access control policies cannot be circumvented.

Sun Management Center also supports SNMP v1 and v2 with community-based security. Although not as robust from a security standpoint, support for SNMP v1 and v2 is important for integration with other devices and other management platforms. In environments where the use of these mechanisms is undesirable, the access control specification mechanism can be used to restrict or forbid access to processes using the SNMP v1 and v2 protocols. The Sun Management Center agent can also understand and respond to SNMPv3 queries from third-party applications.

For customized operations where data streaming could be a requirement, a probe mechanism is also employed. The probe mechanism is initiated by SNMP operations. When initiated, probe operations use a streaming TCP connection to implement bidirectional, potentially interactive services on the managed node, for example, log file viewing. Since the probe mechanism uses SNMP communication, no encryption of the packet payload is performed.

Cross-Server Context Security

When Sun Management Center communicates with managed nodes outside the local server context, the security model ensures that operations are performed as the generic public SNMPv2 usec user. Use of public greatly restricts privileges and limits users to the perusal of management data.

Client-to-Server Security

Communication between the Sun Management Center server layer and clients such as consoles and command-line interfaces is performed using Java Technology Remote Method Invocation (RMI) in conjunction with a comprehensive product-specific security model. The security model allows clients to operate in either low, medium or high security modes, which affects the level of message authentication that is performed.

• Low: No message authentication. Only the user password is checked at time of login.

• Medium (default): Console-to-server authentication only, for example, server authentication of incoming console messages.

• High: Both console and server authenticate messages.

Because of the potential performance impact of the higher security levels, you should carefully consider your message authentication requirements.

Module Security

Sun Management Center provides module level security for Service Management Facility(SMF), Module Configuration Propagation (MCP), and Solaris Container Manager modules. Any user will be able to load any module on the Sun Management Center agent. However, for setting/changing actions or values on the module, the user needs to have prior permissions. Module security is provided in two ways: RBAC (Role Based Access Control) and local file access.

RBAC is based on profiles. Users having the required profiles can perform profile-specific tasks. RBAC can be implemented by running Solaris system administration commands.

Local file access is independent of the OS. The users need to have the required permissions to be added to the local access file. Security through local file access can implemented by using the es-config command. For more information refer to Using es-config.

Security Keys and SNMP Community String

When you install and then set up the Sun Management Center agent on a separate machine, you are prompted to provide a password that is used to generate the security key for the agent. The password should be the same password as the password you specified during setup of the Sun Management Center server. The Sun Management Center server and agent cannot communicate with each other if the server and agent have different security keys. For information on how to regenerate security keys, see Regenerating Security Keys.

During setup, you are also prompted to either accept the default SNMP community string (public), or specify a private community string. The SNMP community string is essentially a password for a privileged internal account. As such, this string potentially can be used to mimic the server layer if used with generic SNMPv2 usec tools. Therefore, do not use the default community string. Specify a separate, private community string for each server context.

Treat the security password and the SNMP community string with the same significance as a superuser password.

Management Strategies

This section provides an overview of Sun Management Center management approaches. Understanding the systems under management and their implementation can contribute to the successful deployment and use of Sun Management Center.

Server Contexts

The highest-level building block for the organization of management information is the server context. Each Sun Management Center server provides only one server context. Each server context might have one or more managed systems that report to the server context. A managed system can report to only one server context.

Communication between server contexts is typically restricted, and management events are not forwarded between servers. The use of server contexts should parallel the structure of the groups within the organization using Sun Management Center. Server contexts should also parallel the responsibilities of these groups with respect to systems management. The administrative group that owns the server also owns the management data within the server. This group controls all access to all system and network resources managed by the Sun Management Center server.

Domain Strategies

Domains are the highest-level construct within a server context. Domains provide individual environments within which you can create custom topology configurations. Domains are very generic. You can create a domain to represent information specific to users, environments, or any other logical division. Managed systems may appear in more than one domain, enabling multiple, overlapping domains to exist. You can therefore construct several different representations of the same management information and system resources.

Domains typically contain a hierarchical collection of Sun Management Center groups that you can use to aggregate sets of managed systems, Sun Management Center management modules, or managed objects. This hierarchy defines the visible breakdown of information in the user interface. This hierarchy also defines the rules for aggregating management status and providing this status to high-level summaries. This capability and flexibility makes domains, and the containers within them, a powerful tool for the construction of logical management models of a specific environment.

Organization Strategies

Sun Management Center contains a powerful Discovery Manager, which can be used to automatically and periodically examine the local environment to identify all managed nodes. While instrumental in the configuration of Sun Management Center, the Discovery Manager structures management information along physical, network-based lines.

Depending on the nature of your environment, using the Discovery Manager might not be the most useful way to view management information and aggregate status information. Conversely, using the Discovery Manager is very useful for identifying all managed systems prior to organizing your Sun Management Center environment. For further information about the Discovery Manager, see Chapter 4, Adding Objects to the Topology Database Using the Discovery Manager, in Sun Management Center 3.6.1 User’s Guide.

Other ways to organize the Sun Management Center environment include:

• Physical

• Environmental

• Application

• Service

In each of the Sun Management Center environments, emphasis should be placed on completeness. The breadth of coverage must be sufficient to pro-actively or at least immediately identify system problems. Failures in devices, hosts, services, or processes that are critical to an environment but that are not being monitored by Sun Management Center can cause gaps in the coverage that will affect the overall effectiveness of an implementation. To this end, you should consider customized modules, proxy solutions, and even information from other server contexts when building your Sun Management Center management environments.

Physical Organization

The physical locations of managed systems might not correspond to the networks on which the systems reside. In this case, you might want to create a new domain in which the Sun Management Center groups are structured on physical lines. Cities, sites, buildings, floors, server rooms and even equipment racks can easily be represented. The systems at these locations can be copied and pasted from the domain in which discovery was performed using the Discovery Manager.

To configure a Sun Management Center environment along physical lines requires you to know where the systems are physically located. This organization can become a valuable and easily accessed reference. A physical organization also defines a status roll-up path, enabling problems to be isolated on physical lines and assisting in the identification of common-mode failures. For example, a localized power outage might affect systems that reside on several networks but will only appear in one physical area.

---

Caution –

You must keep the information up-to-date yourself. This information is not automatically updated when discoveries are performed. The discovery process does not automatically track assets that are physically relocated.

---

Environmental Strategies

Your organization might have several logical environments whose locations and resources overlap, but whose logical functions are distinct. Logical environments include corporate groups such as sales versus engineering, functional groups such as retail versus institutional, and even logical software environments such as user acceptance versus production.

In all of these cases, consider producing separate Sun Management Center topology groups that isolate the elements of each group. Separate topology groups prevent problems in one group from raising alarms in another group. This isolation is particularly important when configuring the Sun Management Center environment for systems that include multi-domain servers. The different domains might be performing functions for completely different groups or environments. The inclusion of the different domains in a single topology group could result in misleading information and alarm notifications.

Application Organization

Applications are complex entities in systems management. Determining what constitutes an application from a management perspective can be difficult, particularly when applications are distributed and rely on many external services to operate properly. For this reason, you should organize applications before installing Sun Management Center. Do not defer consideration of the cause and effect relationships until a problem is actually encountered. Some initial analysis contributes to increasing the efficiency with which application-level problems are resolved.

When configuring an application-oriented Sun Management Center environment, the topology containers typically contain a mix of hosts, modules, and specific objects. Some hosts might be completely dedicated to that application, while other hosts might only be partially responsible for the application's proper operation. For example, in the case of an application that makes use of a corporate directory service, the health of the directory service is critical to the operation of the application, but the health of other services on the server are not critical to or needed by the application.

Services Responsibilities

In some circumstances, a group or administrator might be responsible for a specific service but not the underlying resources. For example, a database administrator might be responsible for the database service availability and data integrity, but not responsible for the hardware or operating system administration. A Sun Management Center domain that is created specifically for the database services can assist the database administrator in performing the necessary tasks. General user role privileges can assist the administrator by providing access to general system and network status.

Managing Large Enterprises

Several facilities in Sun Management Center can help you to simplify management of large enterprises. One facility is Reference Domains, which allow groups to share management information across server contexts. Another feature is the Grouping Operations system, which facilitates performing large, highly distributed management operations.

The grouping system enables you to set data property values, and modify data property attributes. You can also load, unload, enable, and disable modules in your Sun Management Center server environment. All of these operations can be applied to a large group of managed systems and nodes. These groups can be defined using existing topology structures or flexible, discovery-style filters. Grouping operations can be saved and performed multiple times. A scheduler is available to automate grouping operations. Grouping operations also include Module Configuration Propagation (MCP), a facility in which a reference node's entire configuration can be cloned by pulling it to the server and then pushing it to all similar nodes.

For further information about Reference Domains, see Monitoring Remote Administrative Domains in Sun Management Center 3.6.1 User’s Guide. For further information about group operations, see Chapter 13, Managing Group-related Jobs, in Sun Management Center 3.6.1 User’s Guide.