C H A P T E R 3 |
Security Access Setup |
This chapter describes how to set up user privileges to perform Sun Management Center administrative tasks on Sun Fire high-end systems. After the Sun Management Center software is installed and set up, you must set up users in two different software administrative groups according to the tasks they will perform:
To use a Sun Management Center tool or module that requires membership in a System Management Services administrative group, your user ID must be listed as a member of that group in the group definition accessed by each of the two software packages. In other words, both the Sun Management Center and the System Management Services software must find your user ID as a member of the appropriate administrative group.
There are two ways to ensure that both Sun Management Center and System Management Services identify your user ID as a member of the appropriate System Management Services administrative group:
Obviously, maintaining a single file on a centralized name server host is more convenient and less prone to error than maintaining two separate files with identical information on two different machines. But security considerations might affect the method you choose and how you implement it.
Both the Sun Management Center and SMS environments provide different administrative groups, so that you can assign different administrative privileges to different users. This system assumes that the power to add or remove users from these groups is tightly controlled. However, anyone with superuser privileges on the machine where group membership is defined has the power to create or delete groups and add or remove group members. Clearly, if unauthorized users have superuser privileges, they gain the ability to add themselves (or others) to administrative groups and that undercuts the purpose of having such groups.
Therefore, a key security consideration is how many people (and which people) have superuser privileges on either the central name server or the combination of Sun Management Center server host and system controller for Sun Fire high-end systems. While it is assumed that superuser privileges on the system controller are tightly controlled, in some environments, superuser privileges on the Sun Management Center server host are held by many people. At other sites, these superuser privileges are tightly restricted. In some environments, many people are granted superuser privileges on the name server. In others, superuser access to the name server is strictly limited.
The group setting in the name service switch file (/etc/nsswitch.conf) on both the Sun Management Center server host and the system controller for Sun Fire high-end systems affects group membership security. By default, most switch files are set up so that if an application does not find the group information it needs in one source (such as the /etc/group file), it looks in another source such as an NIS name server; or vice versa. Therefore, if security is a consideration, you must edit the group setting in the name service switch file to specify only a single source.
If you have more than one Sun Fire high-end system and you maintain group definitions on a central NIS name server, you might want to rename the System Management Services administrative groups from their default values. If group membership is maintained on a central name server, and two or more Sun Fire high-end systems use the same name for an SMS administrative group, then members of that group have administrative privileges on both machines.
For example, the default name for the Domain B administrative group is dmnbadmn. If more than one machine uses that name, then members of that group have administrative privileges over each machine's Domain B. You can restrict administrative privileges to a single machine by renaming the administrative groups on each machine to have unique values such as dmnbadmn1 and dmnbadmn2.
TABLE 3-1 describes the default Sun Management Center administrative groups.
To Add Users Into Sun Management Center User Groups |
Add the user IDs of all Sun Management Center users in the /var/opt/SUNWsymon/cfg/esusers file on the Sun Management Center server host.
The user IDs must be valid UNIX user IDs.
The following example is a typical partial listing in the /var/opt/SUNWsymon/cfg/esusers file for all Sun Management Center users:
TABLE 3-2 describes the default SMS administrative groups.
Has all platform administrative privileges, including controlling boards and components power and assigning system boards to Sun Fire high-end systems domains. Does not have platform service privileges. Can assign a board to a domain if the board is free (unassigned). Can delete (unassign) a board from a domain if the board is not connected. Cannot connect, configure, unconfigure, or disconnect a board from a domain. |
||
Has a subset of platadmn privileges. Can view platform status. |
||
dmnxadmn[1] |
Can access the Sun Fire high-end systems domain's console and perform Sun Fire high-end systems domain control, status, and access control tasks. Can connect, configure, unconfigure, and disconnect system boards from the domain. Can assign boards to the domain if they are listed in the domain's Access Control List (ACL) and have not been assigned to some other domain. |
|
dmnxrcfg[2] |
Has a subset of dmnxadmn privileges. Can reconfigure and control power to system boards in the Sun Fire high-end systems domain. |
You must add user IDs to SMS groups whose capabilities you want the user to have, using one of the following:
To Add Users Into SMS Groups Using the smsconfig Command |
1. On the system controllers, use the smsconfig(1M) command with the -a option to add user IDs one at a time to the /etc/group file.
Note - The group IDs are automatically created in the /etc/group file during SMS installation on the system controllers. |
Refer to the System Management Services (SMS) Reference Manual for more information about using the smsconfig(1M) command.
2. On the Sun Management Center server, add the lines of SMS Administration group IDs and user ID in the /etc/group file in the exact manner they appear in the system controllers' /etc/group files.
For example, this is a typical partial listing in the /etc/group file of groups and user IDs for access to various Sun Management Center tasks:
Administrative group requirements for using Sun Fire high-end systems modules are summarized in TABLE 3-3.
Depends on operation (see "SMS Groups Required for PDSM Operations") |
||
For more information about setting up or changing service administrative groups, refer to System Management Services (SMS) Administrator Guide. For more information about setting up, changing, or further access privileges of Sun Management Center groups, refer to Sun Management Center User's Guide.
To perform Sun Fire high-end systems Platform/Domain State Management (PDSM) operations, you must be a member of the appropriate SMS group for that operation:
The platform view is readable only by the platform administrator (platadmn) and platform operator (platoper). TABLE 3-4 describes the management operations available in the platform view and the access privileges required for each operation.
The 18 Sun Fire E25K/15K domains (a through r) and 9 Sun Fire E20K/12K domains are readable only by their respective Sun Fire high-end systems domain administrator (dmnxadmn) and Sun Fire high-end systems domain reconfigurer (dmnxrcfg), and for some tasks performed by the platform administrator (platadmn) and platform operator (platoper). TABLE 3-5 describes the management operations available in the Sun Fire high-end systems domain view and the access privileges required for each operation.
Caution - Any single user ID can have up to 16 group IDs associated with it; any group ID after the 16th one is ignored, which causes access problems for the user ID. In other words, a user might appear to belong to a group, but if the 16-group limit is exceeded, the user might not have the access privileges of that group. For more information about how the system reacts when a user has more than 16 group IDs, see Possible Reasons for DR Operation Attempts Failing. |
Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.