Name Services Administration Guide
  Sök endast i den här boken
Ladda ner denna bok i PDF

Setting Up the Root Domain

1

This chapter provides step-by-step instructions for one task, setting up the root domain with DES authentication.
This task describes how to set up the root domain for DES operation; that is, with the root master server running at security level 2. Setting up the root domain involves three major tasks:
  • Preparing the root master server
  • Creating the root domain
  • Creating credentials for the root domain
However, setting up the root domain is not as simple as performing these three tasks in order; they are intertwined with each other. For instance, you must specify some security parameters before you create the root directory; the rest, after. To make the root domain easier to set up, this section separates these tasks into individual steps and arranges them into their most efficient order.

Standard versus NIS-Compatible Setup Procedures

The steps in this section apply to both a standard NIS+ root domain and an NIS-compatible root domain. There are, however, some important differences. The NIS+ daemon for an NIS-compatible domain must be started with the -Y option, which allows the root master server to answer requests from NIS clients. This is described in Step 7. The equivalent step for standard NIS+ domains is Step 8.
An NIS compatible domain also requires Read rights to the Passwd table for the Nobody class, which allows NIS clients to access the information stored in the table's Passwd column. This is accomplished with the -Y option to the nissetup command, in Step 9. The standard NIS+ domain version uses the same command but without the -Y option.

Establishing the Root Domain

The procedure describes each step in detail and provides related information. For those who do not need detailed instructions, a summary listing of the necessary commands is provided at the end of the chapter.

Summary of Steps

Here is a summary of the entire setup process:
  1. Log on -- as superuser -- to the root master server.

  2. Check the root master server's domain name.

  3. Check the root master server's Switch configuration file.

  4. Clean out leftover NIS+ material and processes.

  5. Name the root domain's admin group.

  6. Create the root directory and initialize the root master server.

  7. --NIS-Compatiblity Only-- Start the NIS+ daemon with -Y.

  8. --Standard NIS+ Only--Start the NIS+ daemon.

  9. Create the root domain's subdirectories and tables.

  1. Create DES credentials for the root master server.

  1. Create the root domain's admin group.

  2. Add the root master to the root domain's admin group.

  3. Update the root domain's public keys.

  4. Start the NIS+ cache manager.

  5. Restart the NIS+ daemon with security level 2.

  1. Add your LOCAL credentials to the root domain.

  2. Add your DES credentials to the root domain.

  3. Add credentials for other administrators.

  4. Add yourself and other administrators to the root domain's admin group.

Security Considerations

NIS+ provides preset security defaults for the root domain. You can override or change these security defaults. To do this while setting up the root domain, see "Overriding Defaults" on page 147.

Prerequisites

  • The /etc/passwd file on the root master server must contain an entry for you and every other administrator whose credentials will be added to the root domain in this setup process.
  • If the server will operate in NIS-compatibility mode and support DNS forwarding for Solaris 1.x clients, it must have a properly configured /etc/resolv.config file (described in Name Services Configuration Guide.")

Information You Need

  • The superuser password of the workstation that will become the root master server (for Step 1)
  • The name of the root domain (for Step 2)
  • The name of the root domain's admin group (for Step 5)
  • Your UID and password
  • The UID of any administrator whose credentials you will add to the root domain.

· How to Set Up a Root Domain

  1. Log on -- as superuser -- to the root master server.

    Log on as superuser to the workstation that will become the root master server. The examples in these steps use "rootmaster" as the root master server and "Wiz.Com." as the root domain.

  1. Check the root master server's domain name.

    Make sure the root master server is using the correct domain name. Use the domainname command, as shown below:


  rootmaster# domainname  
  Strange.Domain  
  rootmaster# domainname Wiz.Com  
  rootmaster# domainname  
  Wiz.Com  
  rootmaster# domainname > /etc/defaultdomain  

The domainname command returns a workstation's current domain name. If the name is not correct, change it. (Complete instructions are provided in Chapter 2, "Setting Up NIS+ Clients") The above example changes the domain name of the root master server from StrangeDomain to Wiz.Com: Make sure that you don't include a trailing dot with the domain name in this instance. The domainname command is not an NIS+ command, so it does not follow the NIS+ conventions of a trailing dot. Also make sure that the domain name has at least two labels; e.g., "Wiz.Com" instead of "Wiz."
  1. Check the root master server's Switch configuration file.

    Make sure the root master server is using the NIS+ version of the nsswitch.conf file, even if it will run in NIS-compatibility mode. This step ensures that the primary source of information for the root master will be NIS+ tables. Figure 1-1 on page 6 shows the NIS+ version of the file.


  rootmaster# more /etc/nsswitch.conf  

If the root master server's configuration file is different from the one in Figure 1-1 on page 6, change it to the NIS+ version. Complete instructions are provided in Chapter 6, "Setting Up the Name Service Switch," but here is an example:

  rootmaster# cp /etc/nsswitch.nisplus /etc/nsswitch.conf  
  rootmaster# ps -e | grep keyserv  
    root 145  1 67 16:34:44  ?  keyserv  
      .  
      .  
      .  
  rootmaster# kill -9 145  
  rootmaster# rm -f /etc/.rootkey  
  rootmaster# keyserv  


  rootmaster# more /etc/nsswitch.conf  
  #  
  # /etc/nsswitch.nisplus:  
  #  
  # An example file that could be copied over to /etc/nsswitch.conf; it  
  # uses NIS+ (NIS Version 3) in conjunction with files.  
  #  
  # "hosts:" and "services:" in this file are used only if the /etc/netconfig  
  # file contains "switch.so" as a nametoaddr library for "inet" transports.  
  
  # the following two lines obviate the "+" entry in /etc/passwd and /etc/group.  
  passwd:   files nisplus  
  group:   files nisplus  
  
  # consult /etc "files" only if nisplus is down.  
  hosts:   nisplus [NOTFOUND=return] files  
  #Uncomment the following line, and comment out the above, to use both DNS and NIS+  
  #hosts:   nisplus dns [NOTFOUND=return] files  
  
  services:  nisplus [NOTFOUND=return] files  
  networks:  nisplus [NOTFOUND=return] files  
  protocols: nisplus [NOTFOUND=return] files  
  rpc:    nisplus [NOTFOUND=return] files  
  ethers:   nisplus [NOTFOUND=return] files  
  netmasks:  nisplus [NOTFOUND=return] files  
  bootparams: nisplus [NOTFOUND=return] files  
  
  publickey: nisplus  
  
  netgroup:  nisplus  
  
  automount: files nisplus  
  aliases:  files nisplus  

Figure 1-1 NIS+ Version of nsswitch.conf File
  1. Clean out leftover NIS+ material and processes.

    If the workstation you are working on was previously used as an NIS+ server or client, remove any files that might exist in /var/nis and kill the cache manager, if it is still running. In this example, a coldstart file and a directory cache file still exist in /var/nis:


  rootmaster# ls /var/nis  
  NIS_COLD_START   NIS_SHARED_CACHE  
  rootmaster# rm -rf /var/nis/*  
  rootmaster# ps -ef | grep nis_cachemgr  
    root 295  260 10 15:26:58 pts/0 0:00 grep nis_cachemgr  
    root 286   1 57 15:21:55 ?   0:01 /usr/sbin/nis_cachemgr  
  rootmaster# kill -9 286  

This step makes sure files left in /var/nis or directory objects stored by the cache manager are completely erased so they do not conflict with the new information generated during this setup process. If you have stored any admin scripts in /var/nis, you may want to consider storing them elsewhere temporarily, until you finish setting up the root domain.
  1. Name the root domain's admin group.

    Although you won't actually create the admin group until Step 11, you need to identify it now. Identifying it now ensures that the root domain's org_dir directory object, groups_dir directory object, and all its table objects are assigned the proper default group when they are created in Step 9.

    To name the admin group, set the value of the environment variable NIS_GROUP to the name of the root domain's admin group. Here are two examples, one for csh users, and one for sh/ksh users. They both set NIS_GROUP to "admin.Wiz.Com."

    (To view the workstation's environment variables, use the env command.)

  2. Create the root directory and initialize the root master server.

    This step creates the first object in the namespace -- the root directory -- and converts the workstation into the root master server. Use the nisinit -r command, as shown below. (This is the only instance in which you will create a domain's directory object and initialize its master server in one step.

In fact, nisinit -r performs an automatic nismkdir for the root directory. In any case except the root master, these two processes are performed as separate tasks. )

  rootmaster# nisinit -r  
  
  This machine is in the Wiz.Com. NIS+ domain  
  Setting up root server ...  
  All done.  

A UNIX directory with the name of the server (e.g., rootmaster) is created under /var/nis. Beneath it is a file named root.object:

  rootmaster# ls -l /var/nis/rootmaster  
  -rw-rw-rw-  1 root  other  384        date  root.object  

This is not the root directory object; it is actually a file that NIS+ uses to describe the root of the namespace for internal purposes. The NIS+ root directory object will be created in the following step.
In subsequent steps, other files will be added beneath the directory created in this step. Although you can verify the existence of these files by looking directly into the UNIX directory, NIS+ provides more appropriate commands. They are called out where applicable in the following steps.

Imported image(139x95)

  1. --NIS-Compatibility Only-- Start the NIS+ daemon with -Y.

    Perform this step only if you are setting up the root domain in NIS-compatibility mode; if setting up a standard NIS+ domain, perform Step 8 instead. This step includes instructions for supporting the DNS forwarding capabilities of NIS clients.

    This step consists of two sub-steps, a and b. Step a starts the NIS+ daemon in NIS-compatibility mode and Step b makes sure that when the server is rebooted, the NIS+ daemon restarts in NIS-compatibility mode. After Step b, skip to Step 9.

a. Use rpc.nisd with the -Y, -B, and -S 0, options:

  rootmaster# rpc.nisd -Y -B -S 0  

The -Y option invokes an interface that answers NIS requests in addition to NIS+ requests. The -B option supports DNS forwarding. The -S 0 flag sets the server's security level to 0, which is required at this point for bootstrapping. Since no Cred table exists yet, no NIS+ principals can have credentials; if you used a higher security level, you would be locked out of the server.
b. Edit the /etc/init.d/rpc file.
Search for the string EMULYP="Y" in the /etc/init.d/rpc file. Uncomment the line and, to retain DNS forwarding capabilities, add a -B flag:

  rootmaster# vi /etc/init.d/rpc  
  .  
  .  
  .  
  #   EMULYP="-Y"  
  .  
  .  
         -------uncomment and change to------  
  
      EMULYP="-Y -B"  

If you don't need to retain DNS forwarding capabilities, uncomment the line, but don't add the -B flag.

Imported image(139x83)

  1. --Standard NIS+ Only--Start the NIS+ daemon.

    Use the rpc.nisd and be sure to add the -S 0 flag.


  rootmaster# rpc.nisd -S 0  

The -S 0 flag sets the server's security level to 0, which is required at this point for bootstrapping. Since no Cred table exists yet, no NIS+ principals can have credentials, and if used a higher security level, you would be locked out of the server.
As a result of this step (or Step 7), your namespace now has:
  • A root directory object (root_dir)
  • A root master server (rootmaster) running the NIS+ daemon (rpc.nisd)
  • A coldstart file for the master server (NIS_COLD_START)
  • A transaction log file (servername.log)
  • A table dictionary file (servername.dict).
The root directory object is stored in the directory created in Step 6:

  rootmaster# ls -l /var/nis/rootmaster  
  -rw-rw-rw-  1 root  other  384        date root.object  
  -rw-rw-rw-  1 root  other  124        date root.dir  

At this point, the root directory is empty; in other words, it has no subdirectories. You can verify this by using the nisls command (described on page 169):

  rootmaster# nisls -l Wiz.Com.  
  Wiz.Com.:  

However, it has several object properties, which you can examine using niscat -o:

  rootmaster# niscat -o Wiz.Com.  
  Object Name  : Wiz  
  Owner     : rootmaster.Wiz.Com.  
  Group     : admin.Wiz.Com.  
  Domain    : Com.  
  Access Rights : r---rmcdrmcdr---  
  .  
  .  
  .  

Note that the root directory object provides full (Read, Modify, Create, and Destroy) permissions to both the Owner and the Group, while providing only Read access to the World and Nobody categories. (If your directory object does not provide these rights, you can change them using the nischmod command.)
You can verify that the NIS+ daemon is running, by using the ps command:

  rootmaster# ps -ef | grep rpc.nisd  
  root 1081   1 61 16:43:33 ?   0:01 rpc.nisd -S 0  
  root 1087 1004 11 16:44:09 pts/1 0:00 grep rpc.nisd  

The root domain's NIS_COLD_START file, which contains the Internet address (and eventually, public keys) of the root master server, is placed in /var/nis. Although there is no NIS+ command that you can use to examine its contents, its contents are loaded into the server's directory cache (NIS_SHARED_DIRCACHE). You can examine those contents with the /usr/lib/nis/nisshowcache command, described on page 180.
Also created are a transaction log file (servername.log) and a dictionary file (servername.dict). The transaction log of a master server stores all the transactions performed by the master server and all its replicas since the last update. You can examine its contents by using the nislog command (described on page 184). The dictionary file is used by NIS+ for internal purposes; it is of no interest to an administrator.

Imported image(139x108)

  1. Create the root domain's subdirectories and tables.

    This step adds the "org_dir" and "groups_dir" directories, and the NIS+ tables, beneath the root directory object. Use the nissetup utility. For an NIS-compatible domain, be sure to include the -Y flag. Here are examples for both versions:


  rootmaster# /usr/lib/nis/nissetup -Y          # NIS-compatible only  
  
  rootmaster# /usr/lib/nis/nissetup           # Standard NIS+ only  

Each object added by the utility is listed in the output:

  rootmaster# /usr/lib/nis/nissetup  
  org_dir.Wiz.Com. created  
  groups_dir.Wiz.Com. created  
  auto_master.org_dir.Wiz.Com. created  
  auto_home.org_dir.Wiz.Com. created  
  bootparams.org_dir.Wiz.Com. created  
  cred.org_dir.Wiz.Com. created  
  ethers.org_dir.Wiz.Com. created  
  group.org_dir.Wiz.Com. created  
  hosts.org_dir.Wiz.Com. created  
  mail_aliases.org_dir.Wiz.Com. created  
  sendmailvars.org_dir.Wiz.Com. created  
  netmasks.org_dir.Wiz.Com. created  
  netgroup.org_dir.Wiz.Com. created  
  networks.org_dir.Wiz.Com. created  
  passwd.org_dir.Wiz.Com. created  
  protocols.org_dir.Wiz.Com. created  
  rpc.org_dir.Wiz.Com. created  
  services.org_dir.Wiz.Com. created  
  timezone.org_dir.Wiz.Com. created  

The -Y option creates the same tables and subdirectories as for a standard NIS+ domain, but assigns Read rights to the Passwd table to the Nobody class so that requests from NIS clients, which are unauthenticated, can access the encrypted password in that column.
Recall that when you examined the contents of the root directory with
nisls (in Step 8), it was empty. Now, however, it has two subdirectories:

  rootmaster# nisls Wiz.Com.  
  Wiz.Com.:  
  org_dir  
  groups_dir  

You can examine the object properties of the subdirectories and tables by using the niscat -o command. You can also use the niscat option without a flag to examine the information in the tables, although at this point they are empty.
  1. Create DES credentials for the root master server.

    The root master server requires DES credentials so that its own requests can be authenticated. To create those credentials, use the nisaddcred command as shown below. When prompted, enter the server's root password:


  rootmaster# nisaddcred des  
  DES principal name : unix.rootmaster@Wiz.Com  
  Adding key pair for unix.rootmaster@Wiz.Com  
             (rootmaster.Wiz.Com.).  
  Enter login password: enter-login-password  
  Wrote secret key into /etc/.rootkey  

If you enter a password that is different from the server's root password, you'll get a warning message and a prompt to repeat the password:

  Enter login password: if-you-enter-different-password  
  nisaddcred: WARNING: password differs from login password.  
  Retype password:  

You can persist and retype the same password, and NIS+ will still create the credential. The new password will be stored in /etc/.rootkey and used by the keyserver when it starts up. To give the keyserver the new password right away, do a keylogin -r, as described in Chapter 8, "Administering NIS+ Credentials."
If you decide to use your login password after all, press Control-C and start the sequence over. If you were to simply retype your login password as encouraged by the server, you would get an error message designed for another purpose, but which in this instance, given the server's instructions, could be confusing:

  nisaddcred: WARNING: password differs from login password.  
  Retype password: enter-login-password  
  nisaddcred: password incorrect.  
  nisaddcred: unable to create credential.  

If for any reason you need to change the root master's DES credential, you can remove the old credential with the nisaddcred -r command, as
described in Chapter 8.
As a result of this step, the root server's private and public keys are stored in the root domain's Cred table ("cred.org_dir.Wiz.Com.") and its secret key is stored in /etc/.rootkey. You can verify the existence of its credentials in the Cred table by using the niscat command (described in Chapter 8.) Since the default domain name is Wiz.Com., you don't have to enter the Cred table's fully-qualified name; the "org_dir" suffix is enough. You can locate the root master's credential by looking for its secure RPC netname.
  1. Create the root domain's admin group.

    This step creates the admin group named in Step 5. Use the nisgrpadm with the -c option. The example below creates the "admin.Wiz.Com." group:


  rootmaster# nisgrpadm -c admin.Wiz.Com.  
  Group "admin.Wiz.Com." created.  

This step only creates the group -- it does not identify its members. That is done in Step 12. To observe the object properties of the group, use niscat -o, but be sure to use "groups_dir" in the group's name. For example:

  rootmaster# niscat -o admin.groups_dir.Wiz.Com.  
  Object Name  : admin  
  Owner     : rootmaster.Wiz.Com.  
  Group     : admin.Wiz.Com.  
  Domain    : groups_dir.Wiz.Com.  
  Access Rights : ----rmcdr---r---  
  Time to Live : 1:0:0  
  Object Type  : GROUP  
  Group Flags  :  
  Group Members :  

  1. Add the root master to the root domain's admin group.

    Since at this point, the root master server is the only NIS+ principal that has DES credentials, it is the only member you should add to the admin group. Use the nisgrpadm command again, but with the -a option. The first

argument is the group name, the second is the name of the root master server. This example adds "rootmaster.Wiz.Com." to the "admin.Wiz.Com." group:

  rootmaster# nisgrpadm -a admin.Wiz.Com. rootmaster.Wiz.Com.  
  Added "rootmaster.Wiz.Com." to group "admin.Wiz.Com."  

Text Box(144x120)

To verify that the root master is indeed a member of the group, use the nisgrpadm command with the -l option (see Chapter 10, "Administering NIS+ Groups"):

  rootmaster# nisgrpadm -l admin.Wiz.Com.  
  Group entry for "admin.Wiz.Com." group:  
    Explicit members:  
      rootmaster.Wiz.Com.  
    No implicit members  
    No recursive members  
    No explicit nonmembers  
    No implicit nonmembers  
    No recursive nonmembers  

  1. Update the root domain's public keys.

    Normally, directory objects are created by an NIS+ principal who already has DES credentials. In this case, however, the root master server could not acquire DES credentials until after it created the Cred table (since there was no parent domain in which to store its credentials). As a result, three directory objects -- root, "org_dir," and "groups_dir" -- do not have a copy of the root master server's public key. (You can verify this by using the

niscat -o command with any of the directory objects. Look for the "Public Key:" field. Instructions are provided in Chapter 11, "Administering NIS+ Directories.")
To propagate the root master server's public key from the root domain's Cred table to those three directory objects, use the /usr/lib/nis/nisupdkeys utility for each directory object, as shown below:

  rootmaster# /usr/lib/nis/nisupdkeys Wiz.Com.  
  rootmaster# /usr/lib/nis/nisupdkeys org_dir.Wiz.Com.  
  rootmaster# /usr/lib/nis/nisupdkeys groups_dir.Wiz.Com.  

After each instance, you'll get a confirmation message such as this one:

  Fetch Public key for server rootmaster.Wiz.Com.  
    netname = 'unix.rootmaster@Wiz.Com.'  
  Updating rootmaster.Wiz.Com.'s public key.  
    Public key : public-key  

Now, if you look in any of those directories (use niscat -o), you'll see this entry under the "Public Key:" field:
 Public Key: Diffie-Hellman (196 bits)

  1. Start the NIS+ cache manager

    The cache manager maintains a local cache of location information for an NIS+ client (in this case, the root master server). It obtains its initial set of information from the client's coldstart file (created in Step 7 or Step 8), and downloads it into a file named NIS_SHARED_DIRCACHE in /var/nis.

    To start the cache manager, simply enter the nis_cachemgr command as show below.


  rootmaster# nis_cachemgr  

Once the cache manager has been started, you only need to restart it if you have explicitly killed it. You don't need to restart it if you reboot, since the coldstart file in /var/nis starts it automatically when the client is rebooted. For more information about the NIS+ cache manager, see Chapter 11, "Administering NIS+ Directories."
  1. Restart the NIS+ daemon with security level 2.

    Now that the root master server has DES credentials and the root directory object has a copy of the root master's public key, you can restart the root master with security level 2. First kill the existing daemon, then restart one with security level 2. For an NIS-compatible root domain, be sure to use the -Y flag (and -B flag). Here is an example:


  rootmaster# ps -e | grep rpc.nisd  
  1081 ?     0:03 rpc.nisd  
  rootmaster# kill 1081  
  rootmaster# rpc.nisd             # Standard NIS+ domain only  
  rootmaster# rpc.nisd -Y -B           # NIS-compatible NIS+ domain  

Since security level 2 is the default, you don't need to use the -S 2 flag.
  1. Add your LOCAL credentials to the root domain.

    Since you don't have access rights to the root domain's Cred table, you must perform this operation as superuser. In addition, as mentioned in "Prerequisites," the root master's /etc/passwd file must contain an entry for you. Use the nisaddcred command with the -p and -P flags. Here is the syntax, followed by an example:


  nisaddcred -p uid -P principal-name local  

The principal-name consists of the administrator's login name and domain name. This example adds a LOCAL credential for an administrator with a UID of 11177 and an NIS+ principal name of "topadmin.Wiz.Com.:

  rootmaster# nisaddcred -p 11177 -P topadmin.Wiz.Com. local  

For more information about the nisaddcred command, see Chapter 8.
  1. Add your DES credentials to the root domain.

    Use the nisaddcred command again, but with the following syntax:


  nisaddcred -p secure-RPC-netname -P principal-name des  

The secure RPC netname consists of the prefix "unix." followed by your UID, the symbol "@" and your domain name, but without a trailing dot. The principal name is the same as for LOCAL credentials: your login name followed by your domain name, with a trailing dot.

  rootmaster# nisaddcred -p unix.11177@Wiz.Com \  
              -P topadmin.Wiz.Com. des  
  Adding key pair for unix.11177@Wiz.Com (topadmin.Wiz.Com.).  
  Enter login password: enter-login-password  

If after entering your login password you get a warning such as this one . . .

  nisaddcred: WARNING: password differs from login password.  
  Retype password:  

. . . and yet the password you entered is your correct login password, ignore the error message. The message appears because NIS+ cannot read the protected /etc/shadow file which stores the password, as expected. The message would not have appeared if you had no user password information stored in the /etc/passwd file.
  1. Add credentials for other administrators.

    Add the credentials, both LOCAL and DES, of the other administrators who will work in the root domain. You can do this in two different ways. One way is to ask them to add their own credentials. However, they will have to

do this as superuser. Here is an example that adds credentials for an administrator with a UID of 33355 and a principal name of "bobee.Wiz.Com."

  rootmaster# nisaddcred -p 33355 -P bobee.Wiz.Com. local  
  rootmaster# nisaddcred -p unix.33355@Wiz.Com \  
                 -P bobee.Wiz.Com. des  
  Adding key pair for unix.33355@Wiz.Com (bobee.Wiz.Com.).  
  Enter login password: enter-bobee's-login-password  

The other way is for you to create temporary credentials for the other administrators, using dummy passwords (note that each administrator must have an entry in the NIS+ Passwd table):

  rootmaster# /usr/lib/nis/nisaddent -a -f \  
        /etc/passwd.xfr passwd  
  rootmaster# /usr/lib/nis/nisaddent -a -f \  
         /etc/shadow.xfr shadow  
  rootmaster# nisaddcred -p 33355 -P bobee.Wiz.Com. local  
  rootmaster# nisaddcred -p unix.33355@Wiz.Com \  
                 -P bobee.Wiz.Com. des  
  Adding key pair for unix.33355@Wiz.Com (bobee.Wiz.Com.).  
  Enter bobee's login password: enter-dummy-password  
  nisaddcred: WARNING: password differs from login passwd.  
  Retype password: re-enter-dummy-password  

The first instance of nisaddent populates the Passwd table --except for the actual password column. The second instance populates the shadow column. Each administrator can later change his or her network password using the chkey command. Chapter 8, "Administering NIS+ Credentials," describes how to do this.
  1. Add yourself and other administrators to the root domain's admin group.

    You don't have to wait for the other administrators to change their dummy passwords to perform this step. Use the nisgrpadm command with the -a option. The first argument is the group name, the remaining arguments are the names of the administrators. This example adds two administrators, topadmin and bobee, to the "admin.Wiz.Com." group:


  rootmaster# nisgrpadm -a admin.Wiz.Com. topadmin.Wiz.Com. \  
                  bobee.Wiz.Com.  
  Added "topadmin.Wiz.Com." to group "admin.Wiz.Com.".  
  Added "bobee.Wiz.Com." to group "admin.Wiz.Com.".  

This step completes this task. A summary of the entire task is provided below.

Summary

Below is a summary of the steps required to set up the root domain. It assumes the simplest case, so be sure you are familiar with the more thorough task descriptions before you use this summary as a reference. Also, this summary does not show the server's responses to each command.
rootmaster% su
Password: enter-root-password
# domainname
# more /etc/nsswitch.conf
# rm -rf /var/nis*
# NIS_GROUP=admin.Wiz.Com.;export NIS_GROUP
# nisinit -r
1. Log on as superuser to rootmaster.

2. Check domain name
3. Check Switch file.
4. Remove leftover NIS+ material.
5. Name the admin group.
6. Initialize the root master.

# rpc.nisd -Y -B -S 0
# vi /etc/inet.d/rpc
# rpc.nisd -S 0
# /usr/lib/nis/nissetup [ -Y ]
# nisaddcred des
Enter login password: enter-login-password
# nisgrpadm -c admin.Wiz.Com.
# nischmod g+rmcd Wiz.Com.
7. NIS-compat only:
a. Start daemon with -Y -B, S 0.
b. Change to EMULYP="-Y -B".
8. NIS+ Only: Start daemon with S 0.
9. Create org_dir, groups_dir, tables.
10. Create DES credentials for root
master.
11. Create admin group.
12. Assign full group rights to root

# nisgrpadm -a admin.Wiz.Com. rootmaster.Wiz.Com.
# /usr/lib/nis/nisupdkeys Wiz.Com.
# /usr/lib/nis/nisupdkeys org_dir.Wiz.Com.
# /usr/lib/nis/nisupdkeys groups_dir.Wiz.Com.
# nis_cachemgr
# ps -ef | grep rpc.nisd
# kill -9 process-id
# rpc.nisd [ -Y ] [ -B ]
# nisaddcred -p 11177 -P topadmin.Wiz.Com. local
# nisaddcred -p unix.11177@Wiz.Com \
directory
13. Add root master to admin group.
14. Update root directory's keys.
Update org_dir's keys.
Update groups_dir's keys.
15. Start NIS+ cache manager
16. Restart the NIS+ daemon w/ sec 2.
First kill existing daemon.
Use -Y for NIS compat & -B for DNS.
17. Add your LOCAL credentials.
18. Add your DES credentials.
-P topadmin.Wiz.Com. des
Enter login password: enter-login-password
# nisaddcred . . .
# nisgrpadm -a admin.Wiz.Com. member ...

19. Add credentials for other admins.
20. Add other admins to admin group.
Figure 1-2 Summary of Steps to Set Up the Root Domain