Establishing the NIS+ Root Domain

To establish a root domain, you use the domainname command
to establish the root domain. You can optionally extend the Diffie-Hellman
key length. Use the ncsd daemon to start NIS+, and then
restart keyserv.

Start the NIS+ service (this starts the cache manager and
the NIS+ daemon, with security level 2).

Add your LOCAL credentials to the root domain.

Add your DES credentials to the root domain.

Add credentials for other administrators.

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

Allocate sufficient swap space.

NIS+ Security Considerations

NIS+ provides preset security defaults for the root domain. The default
security level is level 2. Operational networks with actual users should always
be run at security level 2. Security levels 0 and 1 are for configuring and
testing purposes only. Do not run an operational network at level 0 or 1.

Note –

The NIS+ security system is complex. If you are not familiar with
NIS+ security, you might want to review Chapter 11, NIS+ Security Overview before starting to configure your NIS+ environment.

Prerequisites to Establishing an NIS+ Root Domain

Before proceeding, make sure that the following prerequisites have been
met.

The /etc/passwd file on the root master server
contains an entry for you and every other administrator whose credentials
will be added to the root domain in this configuration process.

If the server will operate in NIS-compatibility mode and support
DNS forwarding for Solaris 1 clients, the server must have a properly
configured /etc/resolv.conf file.

The server must have a unique machine name that duplicates
all user IDs.

The server must have a machine name that does not contain
any dots. For example, a machine named sales.alpha is not
allowed. A machine named sales-alpha is allowed.

How to Configure an NIS+ Root Domain

Before You Begin

To complete this task you need to know:

The superuser password of the machine that will become the
root master server

The name of the root domain

The name of the root domain's admin group

Your UID and password

The UID of any administrator whose credentials you will add
to the root domain

Log in as superuser on the machine designated
to be the root master server.

The examples in these steps use rootmaster as the root master server and doc.com. as
the root domain.

Check the root master server's domain name.

Use
the domainname command to make sure the root master server
is using the correct domain name. The domainname command
returns a machine's current domain name.

Caution –

Domains and hosts should not have the same name. For example,
if you have a sales domain you should not have a machine
named sales. Similarly, if you have a machine named home, you do not want to create a domain named home.
This caution also applies to subdomains. For example, if you have a machine
named west, you don't want to create a sales.west.doc.com subdirectory.

(Do not include a trailing dot with the domainname command. The domainname command is
not an NIS+ command, so it does not follow the NIS+ conventions of a trailing
dot.)

The above example changes the domain name of the root master server
from strange.domain to doc.com. When
changing or establishing a domain name, make sure that it has at least two
elements; for example, doc.com instead of doc.
The final element should end in either an Internet organizational name (such
as .com) or a geographical identifier (such as .jp or .uk).

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 are NIS+ tables.

rootmaster# more /etc/nsswitch.conf

This command displays the current nsswitch.conf file.
The primary name service referenced by this file should be nisplus.
If the root master server's configuration file does not use nisplus as
the primary name service, exchange it for one that does, as explained in Selecting a Different Configuration File.

Optionally, configure the Diffie-Hellman key
length.

If you are using DES authentication, you can elect to
increase the Diffie-Hellman key length from the default 192 bits. For example,
to allow both 640 and 192–bit keys type the following:

rootmaster# nisauthconf dh640-0 des

If you made any changes at all to the nsswitch.conf file, restart the name service cache (nscd)
daemon.

If the machine you are working on was previously used as an NIS+
server or client, remove any files that might exist in /var/nis.
In this example, a cold-start file and a directory cache file still exist
in /var/nis:

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 configuration
process. If you have stored any admin scripts in /var/nis,
you might want to consider temporarily storing them elsewhere, until you finish
setting up the root domain.

Name the root domain's admin group.

Although
you won't actually create the admin group until Step 16, you must 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 14.

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.doc.com..

For C Shell

rootmaster# setenv NIS_GROUP admin.doc.com.

For Bourne or Korn Shell

rootmaster# NIS_GROUP=admin.doc.com.
rootmaster# export NIS_GROUP

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 machine 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 doc.com. NIS+ domain
Setting up root server ...
All done.

This is not the root directory object; it is a file that NIS+ uses to
describe the root of the namespace for internal purposes. The NIS+ root directory
object is created later.

In subsequent steps, other files are 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.

Caution –

Do not rename the /var/nis or /var/nis/data directories or any of the files in these directories that were
created by nisinit or any of the other NIS+ configuration
procedures. In the Solaris 2 release, the /var/nis directory
contained two files named hostname. The directory
also contained a subdirectory named /var/nis/hostname.

Starting in the Solaris 2.5 release, the two files
are named trans.log and data.dict,
and the subdirectory is named /var/nis/data. In the Solaris
2.5 release, the content of the files has also been changed, so these files
are not backward compatible with earlier releases. Thus, if you rename either
the directories or the files to match the Solaris 2.4 patterns, the files
will not work with either the Solaris 2.4 or the Solaris 2.5 version of the rpc.nisd daemon. Therefore, do not rename either the directories
or the files.

(Optional) Edit the /lib/svc/method/nisplus file to
add the options you want.

Notice that the root directory object provides full (read, modify, create,
and destroy) rights to both the owner and the group, while providing only
read access to the world and nobody classes. (If your directory object does
not provide these rights, you can change them using the nischmod command.)

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.

Also created are a transaction log file (trans.log)
and a dictionary file (data.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. The dictionary file is used by
NIS+ for internal purposes; it is of no interest to an administrator.

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:

For standard NIS+ only

rootmaster# /usr/lib/nis/nissetup

NIS-compatible only

rootmaster# /usr/lib/nis/nissetup-Y

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

rootmaster# /usr/lib/nis/nissetup
org_dir.doc.com. created
groups_dir.doc.com. created
auto_master.org_dir.doc.com. created
auto_home.org_dir.doc.com. created
bootparams.org_dir.doc.com. created
cred.org_dir.doc.com. created
ethers.org_dir.doc.com. created
group.org_dir.doc.com. created
hosts.org_dir.doc.com. created
mail_aliases.org_dir.doc.com. created
sendmailvars.org_dir.doc.com. created
netmasks.org_dir.doc.com. created
netgroup.org_dir.doc.com. created
networks.org_dir.doc.com. created
passwd.org_dir.doc.com. created
protocols.org_dir.doc.com. created
rpc.org_dir.doc.com. created
services.org_dir.doc.com. created
timezone.org_dir.doc.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.

The root directory now contains two subdirectories.

rootmaster# nisls doc.com.
doc.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.

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.

If you persist and retype the same password, NIS+ will still create
the credential. The new password will be stored in /etc/.rootkey and
be used by the keyserver when it starts up. To give the keyserver the new
password right away, run keylogin-r, as
described in Chapter 12, 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 retype your login password as
encouraged by the server, you would get an error message designed for another
purpose, but which in this instance could be confusing.

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.doc.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. Since the default domain name
is doc.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.

Create the root domain's admin
group.

This step creates the admin group named in Step 9. Use the nisgrpadm command
with the -c option. The example below creates the admin.doc.com. group.

rootmaster# nisgrpadm -c admin.doc.com.
Group admin.doc.com. created.

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

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. doc.com. to
the doc.com domain.

With group-related commands such as nisgrpadm,
you don't have to include the groups_dir subdirectory
in the name. You need to include that directory with commands like niscat because they are designed to work on NIS+ objects in general. The
group-related commands are “targeted” at the groups_dir subdirectory.

rootmaster# nisgrpadm -l admin.doc.com.
Group entry for admin.doc.com. group:
Explicit members:
rootmaster.doc.com.
No implicit members
No recursive members
No explicit nonmembers
No implicit nonmembers
No recursive nonmembers

Update the root domain's public
keys.

Normally, directory objects are created by an NIS+ principal that
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 18, 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.

If
you look in any of those directories (use niscat-o),
you can find one or more entries like the following in the public key field:

Public key: Diffie-Hellman (192 bits)

Restart the NIS+ service.

Now
that the root master server has DES credentials and the root directory object
has a copy of the root master's public key, when you restart the root master,
it automatically starts with security level 2.

The Service Management Facility automatically starts nis_cachemgr when it enables the NIS+ service, if it detects the /var/nis/NIS_COLD_START file.

Since security level 2 is the default, you don't need to use the -S
2 flag.

Note –

Operational networks with actual users should always be run at
security level 2. Security levels 0 and 1 are for configuration and testing
purposes only. Do not run an operational network at level 0 or 1.

Add your LOCAL credentials
to the root domain.

Because you don't
have access rights to the root domain's cred table, you must perform this
operation as superuser. In addition, the root master's /etc/passwd file
must contain an entry for you. Use the nisaddcred command
with the -p and -P flags as shown below.

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.doc.com.

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.

If, after entering your login password, you get a password that differs
from the login password warning, 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 that stores
the password, as expected. The message would not have appeared if you had
no user password information stored in the /etc/passwd file.

Add credentials for the 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 the following ways.

An easy way to create temporary credentials for the other
administrators is to use Solaris Management Console (if you have it available) running in NIS+
mode.

A second
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 miyoko.doc.com.

A third
way is for you to create temporary credentials for the other administrators,
using dummy passwords. (Note that the other administrator, in this example miyoko, must have an entry in the NIS+ passwd table.
If no such entry exists, you must first create one with nistbladm.
The example below includes that step.)

In this case, the first instance of nisaddent populates
the passwd table – except for the password column.
The second instance populates the shadow column. Each administrator can later
change his or her network password using the chkey command. Chapter 12, Administering NIS+ Credentials describes
how to do this.

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 miyoko,
to the admin.doc.com. group:

Swap space should be double the size
of the maximum size of rpc.nisd. To determine how much
memory rpc.nisd is using, issue the following command:

rootmaster# /usr/lib/nis/nisstat

rpc.nisd will under certain circumstances fork a
copy of itself. If there is not enough memory, rpc.nisd fails.

You can also calculate the memory and swap space requirements for NIS+
tables. For example, if you have 180,000 users and 180,000 hosts in your NIS+
tables, those two tables occupy approximately 190 Mbytes of memory. When you
add credentials for 180,000 users and 180,000 hosts, the cred table
has 540,000 entries (one entry for each local user credential, one entry for
each DES user credential, and one entry for each host). The cred table
occupies approximately 285 Mbytes of memory. In this example, rpc.nisd occupies
at least 190 Mbytes + 285 Mbytes = 475 Mbytes of memory. So, you will require
at least 1 Gbyte swap space. You will also want at least 500 Mbytes of memory
to hold rpc.nisd entirely in memory.