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 15K/12K systems. After the Sun Management Center software is installed and set up, you need to 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 there are security considerations that 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 Sun Fire 15K/12K system controller. 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, 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 Sun Fire 15K/12K system controller 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 need to edit the group setting in the name service switch file to specify only a single source.
group nis |
group files |
If you have more than one Sun Fire 15K/12K system and you maintain group definitions on a central NIS name server, you may 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 15K/12K 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.
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:
esmaster espublic root user1 user2 user3 user4 user5 .... .... |
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 15K/12K domains. Does not have platform service privileges. Can assign board to domains 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 15K/12K domain's console and perform Sun Fire 15K/12K 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 ACL and they 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 15K/12K domain. |
You need to add user IDs to SMS groups, whose capabilities you want the user to have, using one of the following:
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) 1.3 Reference Manual for more information about using the smsconfig(1M) command.
2. On the Sun Management Center server, add the 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 15K/12K 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) 1.3 Administrator Guide. For more information about setting up, changing, or further access privileges of Sun Management Center groups, refer to Sun Management Center 3.5 User's Guide.
To perform Sun Fire 15K/12K 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 15K domains (a through r) and 9 Sun Fire 12K domains are readable only by their respective Sun Fire 15K/12K domain administrator (dmnxadmn) and Sun Fire 15K/12K 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 15K/12K 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 over 16 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. |