Solstice AdminSuite 2.3 Administration Guide

Security Information

Solstice AdminSuite uses the distributed system administration daemon (sadmind) to carry out security tasks when you perform administrative tasks across the network. The sadmind daemon executes the request on the server on behalf of the client process and controls who can access Solstice AdminSuite.

Administering security involves authentication of the user and authorization of permissions.

Authentication means that the sadmind daemon must verify the identity of the user making the request.

Authorization means that sadmind verifies that the authenticated user has permission to execute Solstice AdminSuite on the server. After the user identity is verified, sadmind uses the user identity to perform authorization checks.

If you have permission to use Solstice AdminSuite, you also need to have create, delete, or modify permission before you can change an NIS+ map. See NIS+ and DNS Setup and Configuration Guide for a description of NIS+ security.

User and group identities are used for authorization checking as follows:

Root identity - The root identity has privileges (to access and update data) only on the local system. If the server is the local system (in other words, if the user has logged in as root on the server), the user will be allowed to perform Solstice AdminSuite functions on the server under the root identity.

User who is a member of sysadmin group (group 14) - Solstice AdminSuite permissions are granted to users who are members of the sysadmin group (group 14). This means that a user modifying administration data must be a member of the sysadmin group on the system where the task is being executed.

Security Levels

Each request to change administration data contains a set of credentials with a UID and a set of GIDs to which the user belongs. The server uses these credentials to perform identity and permission checks. Three levels of authentication security are available.

The security levels are described in Table 3-1.

Table 3-1 Solstice AdminSuite Security Levels


Level	Level Name	Description
0	NONE	No identity checking is done by the server. All UIDs are set to the `nobody` identity. This level is used mostly for testing.
1	SYS	The server accepts the original user and group identities from the client system and uses them as the identities for the authorization checks. There is no checking to be sure that the UID of the user represents the same user on the server system. That is, it is assumed the administrator has made the UIDs and GIDs consistent on all systems in the network. Checks are made to see if the user has permission to execute the request.
2	DES	Credentials are validated using DES authentication, and checks are made to be sure that the user has permission to execute the request. The user and group identities are obtained from files on the server system by mapping the user's DES network identity to a local UID and set of GIDs. The file used depends on which name service is selected on the server system. This level provides the most secure environment for performing administrative tasks and requires that a `publickey` entry exists for all server systems where the `sadmind` daemon is running, and for all users accessing the tools.

Note -

Level 1 is the default security used by sadmind.

Changing the Security Level

You can change the security level from Level 1 to Level 2 by editing the /etc/inetd.conf file on each system, and adding the -S 2 option to the sadmind entry. If you do this, make sure that the servers in the domain are set up to use DES security.

You do not need to maintain the same level of security on all systems in the network. You can run some systems, such as file servers requiring strict security, at security Level 2, while running other systems at the default Level 1 security.

See the description of how to set up security for NIS+ in NIS+ and FNS Administration Guide.

Name Service Information

The sadmind daemon uses information held by the name service. The three sources of information are:

Files in the /etc directory such as passwd, group, and shadow, referred to as the keyword files

The NIS name service referred to as the keyword nis

The NIS+ name service referred to as the keyword nisplus

On each system, the /etc/nsswitch.conf file lists several administrative files, followed by a list of one or more keywords that represent the name services to be searched for information. If more than one keyword is listed, they are searched in the order given. For example, the entry

group:	files nisplus

indicates that the security mechanism looks first in the local /etc/group file for an entry. If the entry exists, the security mechanism uses the information in this entry. If the entry doesn't exist, the NIS+ group file is searched.

By default, systems running the Solaris 2.4 and higher OS release have an entry for group 14 in the local /etc/group file. If you want to set up your system to use network-wide information, do not add members to the sysadmin group on the local system. Instead, update the group14 entry found in the group table stored in the name service.

When running under Level 2 security, the security mechanisms use the public/private key information. Make sure that the entry for publickey is followed by either nis or nisplus (depending on which name service you are using), and remove the files designation. See NIS+ and FNS Administration Guide for more information about the nsswitch.conf file.