C H A P T E R 3 - Security Access Setup

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:

Sun Management Center user groups - refer to Chapter 18, "Sun Management Center Security," in the Sun Management Center User's Guide for more information about general Sun Management Center security.

System Management Services (SMS) user groups - because SMS software manages system controller for Sun Fire high-end systems, you must set up user privileges in SMS groups, as well as Sun Management Center groups, to manage the Sun Fire high-end systems platform and domains from the system controller. Refer to Chapter 2, "SMS Security Options and Administrative Privileges," in the System Management Services (SMS) Administrator Guide for more information about general SMS security.

Security Considerations for Defining Groups

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:

Define and maintain the groups in a centralized network name service such as Network Information Service (NIS) that both the Sun Management Center and System Management Services software access.

Define and maintain the groups locally in separate /etc/group files on the Sun Management Center server host and the system controller for Sun Fire high-end systems, and make sure that the System Management Services group definition on the Sun Management Center server host is identical to (or a subset of) the definition on the system controller for Sun Fire high-end systems. In other words, user IDs listed as members of System Management Services administrative groups on the Sun Management Center server host must also be identified as members of those groups on the system controller for Sun Fire high-end systems.

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.

Superuser Access

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.

Name Service Switch

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.

To specify that the only source for group membership is the NIS server, edit the group line in the /etc/nsswitch.conf file on both the Sun Management Center server and the system controller for Sun Fire high-end systems to read:

group nis

To specify that the only source for group membership is the local /etc/group file, edit the group line in /etc/nsswitch.conf file on both the Sun Management Center server and the system controller for Sun Fire high-end systems to read:

group files

Network Name Service

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.

Sun Management Center Groups

TABLE 3-1 describes the default Sun Management Center administrative groups.

TABLE 3-1 Default Sun Management Center Administrative Groups
Group Name	Group	Description
`esadm`	Administrator group	Can perform all administrative tasks including loading and unloading modules, maintaining access control for users and groups, and working with administrative domains, hosts, and modules.
`esops`	Operator group	Has a subset of `esadm` privileges. Can enable and disable modules but cannot load and unload them. Can perform monitoring tasks. Can acknowledge, delete, or fix events.
`esdomadm`	Domain group	Has a Sun Management Center domain-specific subset of `esadm` privileges. Can create administrative domains, create groups within administrative domains, add objects to groups or administrative domains.
`ANYGROUP`	General user group	By default, anyone listed in the `esusers` file is considered to be a member of the `ANYGROUP` group. Can view administrative domains, hosts, modules, events; graph data; and trigger manual refreshes. Can also run ad-hoc commands.

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:

esmaster

espublic

root

user1

user2

user3

user4

user5

....

....

Note - The Sun Management Center user ID esmaster is comparable to being a superuser or root in UNIX; it provides administrative privileges. The Sun Management Center user ID espublic is comparable to logging into a UNIX system as guest; it provides general access privileges. These two user IDs are added to the Sun Management Center esusers file when the software is installed on the server and cannot be changed. To use these user IDs to perform management operations on a Sun Fire high-end systems platform or domain, add these IDs to the appropriate SMS group.

System Management Services Groups

TABLE 3-2 describes the default SMS administrative groups.

TABLE 3-2 Default SMS Administrative Groups
Group Name	Group	Description
`platadmn`	Platform administrator group	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.
`platoper`	Platform operator group	Has a subset of `platadmn` privileges. Can view platform status.
`dmn`x`admn`^[1]	Domain administrator group	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]}	Domain reconfiguration group	Has a subset of `dmn`x`admn` 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:

Central name service such as Network Information Service (NIS), which both the Sun Management Center server and the Sun Fire high-end systems can access. Refer to NIS documentation for more information.

/etc/group file on the Sun Management Center server host and the system controller for Sun Fire high-end systems. This method is described in the procedure that follows.

Note - The user IDs must be valid UNIX user IDs.

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:

root::0:root

other::1:

bin::2:root,bin,daemon

sys::3:root,bin,sys,adm

adm::4:root,adm,daemon

uucp::5:root,uucp

mail::6:root

tty::7:root,tty,adm

lp::8:root,lp,adm

nuucp::9:root,nuucp

staff::10:

daemon::12:root,daemon

sysadmin::14:

nobody::60001:

noaccess::60002:

nogroup::65534:

esadm::1000:root,guest,user1,user2

esdomadm::1001:root,guest,user3

esops::1002:guest,user4

platadmn::118:root,guest,user1,user2

platoper::119:root,guest,user4

dmnaadmn::121:user1, user3

dmnarcfg::122:user3

dmnbadmn::123:user1, user5

dmnbrcfg::124:user5

....

....

....

dmnradmn::155:

dmnrrcfg::156:

Using Sun Fire High-End Systems Modules

Administrative group requirements for using Sun Fire high-end systems modules are summarized in TABLE 3-3.

TABLE 3-3 Sun Fire High-End Systems Modules and Administrative Groups
Module Name	Sun Management Center Groups	System Management Services Groups
Platform Config Reader	`esadm`	`platadmn`, `platoper`
Platform/Domain State Management (PDSM)	`esadm`	Depends on operation (see "SMS Groups Required for PDSM Operations")
Domain Config Reader	`esadm`	`dmn`x`adm`
Dynamic Reconfiguration	`esadm`	`dmn`x`adm` or `dmn`x`rcfg`
SC Config Reader	`esadm`	No requirement
SC Monitoring	`esadm`	No requirement
SC Status	`esadm`	No requirement

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.

SMS Groups Required for PDSM Operations

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:

Platform View (TABLE 3-4)

Domain View (TABLE 3-5)

Platform View Access Permissions

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.

TABLE 3-4 Sun Fire High-End Systems Platform View Management Operations and Access
Platform View Operation	Access
System controller power	`platadmn`, `platoper`
Power supply power	`platadmn`, `platoper`
Fan tray speed	`platadmn`, `platoper`
Slot 0 and slot 1 board power	`platadmn`, `platoper`
Addboard for slot 0 and 1 boards and empty slots	`platadmn`
Deleteboard for slot 0 and 1 boards and empty slots	`platadmn`
Moveboard for slot 0 and 1 boards and empty slots	`platadmn`
Show status	`platadmn`, `platoper`

Domain View Access Permissions

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.

TABLE 3-5 Sun Fire High-End Systems Domain View Management Operations and Access
Domain View Operation	Access
Domain tag	`platadmn`
Keyswitch	`dmn`x`admn`
Domain ACL	`platadmn`
Reset	`dmn`x`admn`
Slot 0 and slot 1 board power	`dmn`x`admn`, `dmn`x`rcfg`, `platadmn`, `platoper`
Slot 0 and slot 1 board test	`dmn`x`admn`
Addboard for slot 0 and slot 1 boards and empty slots	`dmn`x`admn`, `dmn`x`rcfg`, `platadmn`
Deleteboard for slot 0 and 1 boards and empty slots	`dmn`x`admn`, `dmn`x`rcfg`, `platadmn`
Moveboard for slot 0 and 1 boards and empty slots	`dmn`x`admn`, `dmn`x`rcfg`, `platadmn`
Show status	`dmn`x`admn`, `dmn`x`rcfg`, `platadmn`, `platoper`

Limit of 16 Group IDs for a User ID

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.

^{1 (TableFootnote) Where x is a letter from a through r indicating a specific Sun Fire high-end systems domain. For example 1, dmnbadmn is the administrative group for domain B.}

^{2 (TableFootnote) Where x is a letter from a through r indicating a specific Sun Fire high-end systems domain. For example 2, dmnqrcfg is the reconfiguration group for domain Q.}