Chapter 3 Security

An important part of using the Solstice AdminSuite software is understanding its security features and setting up security policies to protect your administrative data.

This is a list of the step-by-step instructions in this chapter.

• "Security Information"

• "Things to Consider When Creating a Security Policy"

• "Creating a Level 2 DES Security System"

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.

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.

Things to Consider When Creating a Security Policy

Consider the following when creating a security policy for using Solstice AdminSuite in a name service environment.

• Determine how much trust is needed.

  If your network is secure and you do not need to use authentication security, you can use Solstice AdminSuite applications with the default Level 1 security.

  If you need to enforce a higher level of security, you can set the security level of sadmind to Level 2.

• Determine which name service will be used.

  The name service determines where the security methods get information about user and group identities. The name services are designated in the /etc/nsswitch.conf file (see "Name Service Information").

• Decide which users have access to Solstice AdminSuite.

  Decide which users will perform administrative functions over the network with Solstice AdminSuite. List these users as members of group 14 accessed by the server system. The group 14 must be accessible from each system where administration data will be updated by Solstice AdminSuite. The group 14 can be established locally on each system or can be used globally within a name service domain, depending upon the policy established by the administrator.

• Determine global and local policies.

  The global policy affects all hosts in the network. For example, you can add members to group 14 in the NIS or NIS+ group file. Members of this group will have permission to perform administrative tasks on all server systems that list the network name service as the primary source of information. The name services are listed in the /etc/nsswitch.conf file. For more information about the nsswitch.conf file, see "Name Service Information".

  A user can establish a local policy that is different from the global policy by creating a group 14 in the local /etc/group file and listing the users who have access to the local system. The members of this group will have permission to manipulate or run Solstice AdminSuite methods on the user's local system.

Setting up a local policy does not disable a global policy. Name service access is determined by the nsswitch.conf file.

• Set up permissions for NIS+ management.

  You need the proper permissions when using Solstice AdminSuite to modify or update the NIS+ files. In addition to the permissions required by Solstice AdminSuite, the NIS+ security mechanisms impose their own set of access permissions. The NIS+ security mechanisms are described in NIS+ and FNS Administration Guide.

• Set up access for NIS management.

  If the NIS master server is running the Solaris 1.x operating system, a user must have a .rhosts entry on the NIS master server to modify the NIS files. If the NIS master server is running the Solaris 2.x operating system and the Name Services Transition Kit 1.2, then no entry is required if AdminSuite is already installed. The NIS updates will be authorized using the standard group 14 mechanism.

Creating a Level 2 DES Security System

Creating a Level 2 DES security system requires a number of steps that depend upon your system configuration. The following sections describe how to set up your system to have level 2 DES security for systems using /etc, NIS, and NIS+ name services.

How to Create Level 2 DES Security for Systems Using /etc Name Service

1. On each system that runs the sadmind daemon, edit the /etc/inetd.conf file.

   Change this line (or one similar to this):

   100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind

   to:

   100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind -S 2

2. On each system that runs the sadmind daemon, set the /etc/nsswitch.conf entry for publickey to files.

   Change this entry (or one similar to this):

   publickey: nis [NOTFOUND=return] files

   to:

   publickey: files

3. Create credentials for all group 14 users and all of the systems that will run sadmind -S 2.

   1. Log in as root to one of the systems that will run sadmin -S 2.

   2. Run the following command for each user that will run AdminSuite.

      # newkey -u username

      ---

      Note -

      You must run this command even for users who are not in group 14. If you are not in group 14 and do not have credentials, you are not a user according to sadmind; you will not be able to run any methods, even those that do not require root. You will have to supply the user's password to the newkey program.

      ---

   3. Run the following command for every host that you have configured to run secure sadmind.

      # newkey -h hostname

      You will have to provide the root password for each of these hosts to the newkey program.

   4. Copy the /etc/publickey file on this system to each of the hosts (put this file in /etc/publickey).

      This file contains all the credentials for each user and each host.

      ---

      Note -

      Do not run newkey on each of the systems. This seems to create a different public/private key pair, and the public key will not be valid across the network. You must create this file on one machine and then copy it to all the others.

      ---

   5. As root, enter the following command on each system to put root's private key in /etc/.rootkey.

      # keylogin -r

      By doing this, you will not have to keylogin as root on every system every time you want to run admintool; this creates an automatic root keylogin at boot time.

4. Create an /etc/netid file for each user and each system; put this file on all of the systems.

   1. For each user in the publickey file, create an entry in /etc/netid that looks like the following:

      unix.uid@domainname uid: uid: gid,gid, ...

   2. List every group that this user is a member of; sadmind -S 2 and files look to netid rather than /etc/group to determine group 14 membership.

   3. For each host in the publickey file, create an entry in /etc/netid that looks like the following:

      unix.hostname@domainname 0:hostname

   4. Copy this file to every system in /etc/netid.

5. Reboot all of the machines.

6. On each system that you want to run the application on, log in and then keylogin. (You must be a member of group 14.)

   After the keylogin, you can safely log out; your key is stored in the keyserv daemon until you explicitly keylogout or the system reboots.

How to Create Level 2 DES Security for Systems Using NIS Name Service

1. On each system that runs the sadmind daemon, edit the /etc/inetd.conf file.

   Change this line (or one similar to this):

   100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind

   to:

   100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind -S 2

2. On each system that runs the sadmind daemon, set the /etc/nsswitch.conf entry for publickey to nis.

   Change this entry (or one similar to this):

   publickey: nis [NOTFOUND=return] files

   to:

   publickey: nis

3. Create credentials for all group 14 users and all of the systems that will run sadmind -S 2.

   1. Log in as root on the NIS server.

   2. Run the following command for each user that will run AdminSuite.

      # newkey -u username -s files

      ---

      Note -

      You must run this command even for users who are not in group 14. If you are not in group 14 and do not have credentials, you are not a user according to sadmind; you will not be able to run any methods, even those that do not require root. You will have to supply the user's password to the newkey program.

      ---

   3. Run the following command for every host that you have configured to run secure sadmind.

      # newkey -h hostname

      You will have to provide the root password for each of these hosts to the newkey program.

   4. Copy the /etc/publickey file on this system to the source file that is specified in /var/yp/Makefile; remake and push the nis maps.

      # cd /var/yp; make

4. Verify that you are a member of group 14 in the group/nis maps.

   1. Login as root.

   2. Change directories to the source file specified in /var/yp/Makefile.

   3. Manually edit the group file and add yourself to group 14, just as you did in the /etc/group file.

   4. Change directories to /var/yp and run make.

      # cd /var/yp; make

      You should see the group map pushed; a message appears indicating that this action has occurred.

      ---

      Note -

      The security system looks in the NIS maps for your group 14 access and will fail if you do not have group14 specified there, regardless if your /etc/nsswitch.conf file has group files nis.

      ---

      When sadmind is running in -S 2 mode, it uses the publickey entry to determine which name service to look at for user credentials. When the entry in /etc/nsswitch.conf is nis, it looks in the nis group map to ensure that the user is a member of group 14.

5. As root, enter the following command on each system to put root's private key in /etc/.rootkey.

   # keylogin -r

   By doing this, you will not have to keylogin as root on every system every time you want to run AdminSuite; this creates an automatic root keylogin at boot time.

6. To ensure that the nscd gets flushed, reboot all of the workstations.

7. On each system that you want to the application to run on, log in and then keylogin. (You must be a member of group 14.)

   After the keylogin, you can safely log out; your key is stored in the keyserv daemon until you explicitly keylogout or the system reboots.

How to Create Level 2 DES Security for Systems Using NIS+ Name Service

1. On each system that runs the sadmind daemon, edit the /etc/inetd.conf file.

   Change this line:

   100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind

   to:

   100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind -S 2

2. On each system that runs the sadmind daemon, set the /etc/nsswitch.conf entry for publickey to nisplus.

   Change this entry (or one similar to this):

   publickey: nisplus [NOTFOUND=return] files

   to:

   publickey: nisplus

3. Log in as root on the NIS+ master server; create credentials for all group 14 users and all of the systems that will run sadmind -S 2.

   1. Create local credentials for the user.

      # nisaddcred -p uid username.domainname. local

   2. Create des credentials for the user.

      # nisaddcred -p unix.uid@domainname -P username.domainname. des

4. Log in as root on the NIS+ master server; add all of the users for the AdminSuite to the NIS+ group 14 using the following command.

   # nistbladm -m members=username,username...[name=sysadmin],group.org_dir

   ---

   Note -

   The use of this function replaces the current member list with the one that is input; therefore, you must include all members you wish to be a part of group 14.

   ---

5. As root, add all of the users for the AdminSuite to the NIS+ admin group.

   # nisgrpadm -a admin username

   Verify that the NIS_GROUP environmental variable is set to admin.

6. On all the workstations that you intend to run the admintool, enter the following command.

   # keylogin -r

7. Reboot all of the workstations; verify that the nscd gets flushed.

8. On each system that you want to the application to run on, log in and then keylogin. (You must be a member of group 14.)

   After the keylogin, you can safely log out; your key is stored in the keyserv daemon until you explicitly keylogout or the system reboots.