This chapter discusses security features, users and groups, and their privileges. The chapter describes the following topics:
Security in Sun Management Center software is based on JavaTM security classes and SNMPv2usec (SNMP version 2, user-based security model) security standards.
The software offers the following layers of security:
Only valid Sun Management Center users can operate the software.
The software enables you to set security permissions or access control list (ACL) categories. The security features provide control at the administrative domain, group, host, and module levels.
The software authenticates users and access control for individual managed properties.
The software offers the following ACL categories:
Admin, like the superuser (root) in UNIX
Operator, as an operator who runs and monitors the system
General, like guest access with read-only viewing privileges
To understand ACL categories, you first need to understand Sun Management Center software users and groups. The following sections explain users and groups.
Sun Management Centerusers are valid UNIX users on the server host. As such, the system administrator has to add valid users into the file /var/opt/SUNWsymon/cfg/esusers. If a user's name is not in this file, that user cannot log into the Sun Management Center software.
The administrator has to add the list of user IDs for all users who need to log into Sun Management Center software. All users in this file have general access privileges, by default, unless the users are given additional privileges using the procedures described in To Grant a User esadm, esops, or esdomadm Privileges.
Any user who is part of the esusers file is known as a general user. Sun Management Center general users can, by default, perform the following functions:
Log into the software
View the administrative domains, hosts, and modules that are created
View events
Trigger manual refreshes
Run ad hoc commands
Graph data
The Sun Management Center superuser automatically belongs to all the groups that are described in the following sections. The Sun Management Center superuser has administrator privileges as described in Sun Management Center Administrators or esadm.
The following groups are created by default on the server host during the Sun Management Center server setup:
In addition, all the Sun Management Center users belong to a hypothetical group, called ANYGROUP.
The listed groups must be defined on the machine where the Sun Management Center server layer is running. These groups do not need to be defined on other machines. These groups are described in greater detail in the sections that follow.
The listed groups are defined in the /etc/group file.
Sun Management Center software users that belong to the group esops are usually operator users. These operators run, monitor, and to some extent, configure parameters on the managed systems. esops can perform operations, including some operations that are allowed for general users:
Disable or enable modules
Set alarm limits
Set rule parameters
Run alarm actions
Run ad hoc commands
Set the refresh interval
Acknowledge, delete, or fix events
Enable or disable history logging
Set logging history parameters
Software users that belong to the group esadm can perform administrator operations. Administrator operations are a superset of the operations that can be performed by operator users as described in Sun Management Center Operators or esops. In addition to all the operations that operator users (esops) can perform, these administrator users (esadm) can perform the following operations:
Load or unload modules
Set ACL users and groups
View administrative domains, hosts, or modules
The users that belong to the group esdomadm can perform the following domain administrator operations:
Create administrative domains
Create groups within administrative domains
Add objects to groups or administrative domains
View administrative domains, hosts, or modules
Other than the privileges listed above, a user that belongs to esdomadm is just a general user, unless configured otherwise.
The following table lists the different types of functions that users can do by default. A mark in a given cell indicates that the specified user can perform the listed function.
This table applies to all modules. Individual modules can also have specific restrictions, which are under the control of the module.
Table 18–1 Domain Admin, Admin, Operator, and General Functions
Function |
Domain Admin |
Admin |
Operator |
General |
---|---|---|---|---|
Load modules |
|
x |
|
|
Unload modules |
|
x |
|
|
Create administrative domains |
x |
|
|
|
Create groups within administrative domains |
x |
|
|
|
Add objects to groups or administrative domains |
x |
|
|
|
View administrative domains, hosts or modules |
x |
x |
x |
x |
Set ACL users or groups |
|
x |
|
|
Disable or enable modules |
|
x |
x |
|
Set module active time window |
|
x |
x |
|
Set alarm limits |
|
x |
x |
|
Set rule parameters |
|
x |
x |
|
Run alarm actions |
|
x |
x |
|
Run ad hoc commands |
|
x |
x |
|
Set the refresh interval |
|
x |
x |
|
Manually trigger a refresh |
x |
x |
x |
x |
Enable or disable history logging |
|
x |
x |
|
Set logging history parameters |
|
x |
x |
|
Acknowledge, delete, or fix events |
|
x |
x |
|
View events |
x |
x |
x |
x |
In Sun Management Center software, the above categories maintain inclusive relationships. This means that a user who has esadm privileges can do anything that a user who has esops privileges can do. An administrator can change the default permissions so that a user who has esops privileges can do more than a esadm user. Inclusive relationships mean that there is nothing in the software that makes one of esops, esadm, or esdomadm more powerful than either of the others.
For more information about how to override default privileges, see To Override Default Agent Privileges.
Administrative domains are manipulated by the Topology manager. This section describes the default privileges for the Topology manager, for other agents, and for other modules.
The default privileges for Topology manager, where administrative domains are maintained, are listed in the following table.
Table 18–2 Default Privileges for Topology Manager
Topology Manager |
Default Privileges |
---|---|
List of Admin Users |
|
List of Operator Users |
|
List of General Users |
|
List of Admin SNMP Communities |
|
List of Operator SNMP Communities |
|
List of General SNMP Communities |
public |
List of Admin Groups |
esdomadm |
List of Operator Groups |
esops |
List of General Groups |
ANYGROUP |
The default privileges for components and modules not in the Topology manager are listed in the following table.
Table 18–3 Sun Management Center Component and Module Default Privileges
Components and Modules |
Default Privileges |
---|---|
List of Admin Users |
|
List of Operator Users |
|
List of General Users |
|
List of Admin Groups |
esadm |
List of Operator Groups |
esops |
List of General Groups |
ANYGROUP |
List of Admin SNMP Communities |
|
List of Operator SNMP Communities |
|
List of General SNMP Communities |
public |
The keyword ANYGROUP is not a true UNIX group, but is a special keyword that means that any user who can log into Sun Management Center software is given general access to the objects.
The esadm group can specify ACL features for users and groups for the following components:
Administrative domains
Groups within administrative domains
Hosts
Modules
An ACL specification consists of establishing or defining one or more of the following parameters:
Administrator users and administrator groups – A list of users and groups who can perform administrator operations. By default, these users are esadm or esdomadm, wherever applicable.
Operator users and operator groups – A list of users and groups who can perform operator operations. By default, these users are esops.
General users and general groups – A list of users and groups who can perform general operations. By default, this category is a hypothetical group that is called ANYGROUP.
Communities for administrators (SNMP) – A list of SNMP communities that can perform administrator operations that use SNMP.
Communities for operators (SNMP) – A list of SNMP communities that can perform operator operations that use SNMP.
Communities for general (SNMP) – A list of SNMP communities that can perform general operations that use SNMP.
Users can access and view data from sessions that are running on remote Sun Management Center servers. When a user tries to gain access to such information, that user is provided access as a general user with read-only privileges. The behavior of Sun Management Center sessions that are running on different servers is defined in terms of each session's server context. See Sun Management Center Server Context and Security for more information.
As a user, you can access and set up a different server context for a variety of reasons:
To enable each server context to have different users and different administrators, and yet remain accessible to each other
To allow for physical separation between elements, as in the context of a wide area network (WAN)
To increase performance by enabling many hosts to be handled by one set of central components
By linking to a different server context, you can view the top level status of the objects in the other server context.
A server context is a collection of Sun Management Center agents and the particular server layer to which the agents are connected. The agents and hosts within a server context share a single set of the following central components:
Sun Management Center server
Topology manager
Event manager
Trap handler
Configuration manager
Every Sun Management Center component or agent is configured at installation to know the location of its trap handlers and event managers. Sun Management Center software identifies the trap handlers and the event managers by their IP and port addresses. To determine whether you are within your server context, you need to know the respective IP and port addresses of the servers that you access. Different server contexts have different port numbers.
A remote server context refers to a collection of remote agents and a particular server layer with which the remote agents are associated.
An agent receives security configuration from the server layer. This information enables the agent to authenticate the management request that is sent to the agent. Then, the agent can perform access control on the requested operation as part of the management request.
Some security restrictions apply when a user tries to communicate across server contexts.
In the current Sun Management Center environment, you can access information from another server with a few limitations:
If you try to access a remote server context, the server give you general user access. Thus, you can access data but cannot modify or use the objects within the different server. You are restricted to viewing only the remote server objects.
You can view data in another context as a general user, but you cannot perform control actions, such as setting alarm thresholds and other similar functions.
Edit functions work differently in a remote server. For example, you can copy and paste between contexts. You cannot cut and paste between contexts.
In the console, the fact that you are accessing a different server context might not be obvious. To identify whether you are accessing a different server, check the server's IP port number or address in the Info tab of the Details window.
The following sections describe how to perform the following key access control functions:
Become superuser on the Sun Management Center server host.
% su - |
Edit the file /var/opt/SUNWsymon/cfg/esusers.
Add the user name on a new line.
Make sure that the user name is the user name of a valid UNIX user.
Save the file and exit the editor.
Users that are added to the users list have default privileges. See Default Privileges and To Override Default Agent Privileges for more information.
Access the Attribute Editor in either of the following ways:
Press mouse button 3 on the selected object, and choose Attribute Editor from the pop-up menu.
Choose Attribute Editor from the Tools menu in the main console window.
The Attribute Editor is displayed. The buttons at the bottom of the window are inactive, with the exception of the Cancel and Help buttons. The remaining buttons become active when you modify any field in the window.
Select the Security tab in the Attribute Editor window.
Change the values as required.
The following list explains the data in each field and provides sample values.
A list of users. jim is a user who can perform administrator operations.
A list of operators. john and others are users who can perform operator operations. Note that their entries are separated by one or more spaces.
A list of general users. nick and richie are users who can perform general operations.
All the users that belong to administrator groups can perform administrator operations. By default, the users are esadm or esdomadm, as applicable.
All users that belong to esops can perform operator operations.
ANYGROUP is a hypothetical group that can perform general operations. All Sun Management Center users belong to this hypothetical group.
This field is empty, denoting that there is no SNMP community that can perform administrator operations that use SNMP.
This field is empty, denoting that there is no SNMP community that can perform operator operations that use SNMP.
By default, public is an SNMP community that can perform general operations that use SNMP.
Use spaces or commas between multiple entries as illustrated in the entries for “Operator” under “Users.”
For more information about security privileges, see Access Control Categories.
Become superuser on the Sun Management Center server host.
Use the groupadd command to create a group.
# /usr/sbin/groupadd groupname |
Add users to the newly created group.
Add the new group to the ACL.
See To Control Access to a Module for more information.
Become superuser on the Sun Management Center server host.
If needed, add the user name to the /var/opt/SUNWsymon/cfg/esusers file.
In the /etc/group file, add the user to one of the following lines as applicable: esadm, esops, or esdomadm.
Save the file and exit the editor.
Become superuser on the Sun Management Center server host.
In the file /var/opt/SUNWsymon/cfg/esusers, delete the line corresponding to the user name you want to delete.
Save the file and exit the editor.
Delete the user names from Sun Management Center groups.
After a user is deleted from the list of Sun Management Center users, the user can no longer log into the Sun Management Center server. Make sure to delete that user from all the ACLs.
In Sun Management Center software, only administrators can override default privileges using the Attribute Editor to modify the ACL lists for that particular object.
Access the Attribute Editor for the specific managed object on which you need to change the privileges.
To view and change security information, click the Security tab in the Attribute Editor window.
Change the information as needed.
To apply the security changes and close the Attribute Editor window, click OK.
To leave the Attribute Editor window open and apply the security changes, click Apply.
Sun Management Center supports encryption of SNMP communications between server and agent components of Sun Management Center. SNMP encryption support uses the CBC-DES symmetric encryption algorithm.
You can enable SNMP encryption on Sun Management Center servers using the es-config script. By using this script, you can turn on or off the auto-negotiate feature. For details, see Enabling SNMP Encryption.
For systems running Solaris 9 or earlier, encryption is based on the package SUNWcry.
Note the following conditions for systems that run Solaris 9:
SNMP encryption on both the Sun Management Center server and agent hosts depends on the SUNWcry package, which contains the /usr/lib/libcrypt_d.so encryption library. You must install this package separately.
SNMP encryption is not supported on Sun Management Center 3.5 and earlier servers and agents even if SUNWcry is installed.
SNMP encryption support is automatically configured during agent or server setup if the SUNWcry package is detected.
For systems running Solaris 10, encryption is based on Public Key Cryptographic Standard (PKCS#11).
PKCS#11 specifies an API, called Cryptoki, to devices which hold cryptographic information and perform cryptographic functions. For more information on the RSA defined PKCS#11, see http://www.rsasecurity.com/rsalabs.
Note the following conditions for systems that run Solaris 10:
SNMP encryption on both the Sun Management Center server and agent hosts depends on the SUNWcsl package, which contains the /usr/lib/libpkcs11.so encryption library. This package is installed by default.
SNMP encryption is not supported on Sun Management Center 3.5 and earlier servers and agents even if SUNWcsl is installed.
SNMP encryption support is automatically configured during agent or server setup if the SUNWcsl package is detected.
For systems running Linux, encryption is based on Public Key Cryptographic Standard (PKCS#11).
SNMP encryption depends on the PKCS11_API.so encryption library. This library is not installed by default. You must provide this library in /usr/lib/pkcs11 and enable the pkcs_slot daemon to enable encryption.
Sun Management Center 3.6.1 servers that support encryption can be set up to support agents dynamically regardless of whether those agents support encryption. This feature is called auto-negotiate and can be set to on or off.
When you set the auto-negotiate feature to off, you ensure that the server always uses encryption when initiating communication with agents. Environments with strict security policies might prefer this set up. If you set auto-negotiate to off:
If the agent supports encryption, the agent understands the encrypted SNMP messages.
If the agent does not support encryption, the agent does not understand the encrypted message. Thus, a timeout occurs and a console message states, “Agent is not responding.” The timeout is recorded in the agent log.
When you set the auto-negotiate feature to on, the server encrypts its SNMP communication with an agent only if the agent supports encryption. As a result, one of the following events occurs:
If the agent supports encryption, the agent understands the encrypted SNMP messages.
If the agent does not support encryption, the SNMP messages are only authenticated and not encrypted.
To find the current state of SNMP encryption, run the es-config command with no arguments.
Check whether the package is installed.
(For systems running Solaris 9 or earlier) Make sure the SUNWcry package, which contains the /usr/lib/libcrypt_d.so encryption library, is installed on the system by typing:
% pkginfo | grep SUNWcry |
If the package is installed, the system shows:
application SUNWcry |
The SUNWcry package is part of the Solaris Encryption Kit. To obtain the Solaris Encryption Kit, see your Sun sales representative. For important information about administering secure systems, see your Solaris system administration documentation.
(For systems running Solaris 10) Make sure the SUNWcsl package, which contains the /usr/lib/libpkcs11.so encryption library, is installed on the system by typing:
% pkginfo | grep SUNWcsl |
If the package is installed, the system shows:
application SUNWcsl |
(For systems running Linux) Make sure you provide the PKCS11_API.so encryption library in /usr/lib/pkcs11 and enable the pkcs_slot daemon.
Type the following command as superuser from the server host:
# es-config -r |
The system detects the presence of the appropriate package and automatically stops all Sun Management Center components. The script then asks for the security seed.
Type the security seed.
The script asks for the SNMPv1 community string.
When asked whether you want to initiate encrypted communication, type y to initiate encrypted communication or n to decline.
When asked whether you want to enable the auto-negotiate feature, type y to enable or n to decline.
For details on the auto-negotiate feature, see Auto-Negotiate Feature.
Sun Management Center agents can communicate with the server using SNMPv1, SNMPv2c, and SNMPv2usec. These communications are enabled by default. You can disable the SNMPv1 and SNMPv2c communications by editing the domain-config.x file. However, you cannot disable the SNMPv2usec communication.
Become superuser on the Sun Management Center agent.
% su -
Open the file /var/opt/SUNWsymon/cfg/domain-config.x.
Add the following lines to the file.
agent = { agentServer = "agentHostName" snmpPort = "161" SNMPv1 = off } |
Where agentHostName is the host name where the agent is installed.
Become superuser on the Sun Management Center agent.
% su -
Open the file /var/opt/SUNWsymon/cfg/domain-config.x.
Add the following lines to the file.
agent = { agentServer = "agentHostName" snmpPort = "161" SNMPv2c = off } |
Where agentHostName is the host name where the agent is installed.
SNMPv3 is an industry-standard protocol that was introduced to overcome the limitations of SNMPv2usec. SNMP messages that are generated by SNMP version 3, user security model (SNMPv3 usm) are more structured than the messages generated by SNMPv2usec.
Sun Management Center 3.6.1 software supports SNMPv3. SNMPv3 enables Sun Management Center agents to communicate with third-party management applications securely.