Chapter 6 Configuring NIS+ Clients

This chapter gives step-by-step instructions for setting up NIS+ clients using the NIS+ command set and three different initialization methods. These instructions apply to clients in both the root domain and subdomains, whether all-NIS+ or NIS-compatible.

NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available as of the Solaris 9 release. For more information, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) and visit NIS+ End-of-Feature (EOF) Announcement FAQ.

Introduction to NIS+ Client Configuration

This chapter describes how to configure clients in both standard NIS+ domains and NIS-compatible domains. 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 in Table 6–1.

It is much easier to perform this task with the NIS+ installation scripts, as described in Part 1, than with the NIS+ command set as described here. The methods described in this chapter should only be used by those administrators who are very familiar with NIS+ and who require some non-standard features or configurations not provided by the installation scripts. If you have them available, the Solaris Management Console tools also provide easier methods of adding and setting up NIS+ client machines.

At Step 11 in the client configuration instructions you must choose which of three methods to use: broadcast, host name, or cold-start file. Because each method is implemented differently, each has its own task description. After initializing a client by one of these methods, you can continue setting up the client by returning to Step 12.

The last task in the chapter describes how to change a machine's domain.

Configuring the NIS+ Client

This section describes how to configure a typical NIS+ client in either the root domain or a non-root domain. This procedure applies to regular NIS+ clients and to those clients that will later become NIS+ servers. It applies, as well, to clients in a standard NIS+ domain and those in an NIS-compatible domain.

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 do not want to create a sales.west.doc.com subdomain.

Setting up an NIS+ client involves the following tasks:

• Creating credentials for the client

• Preparing the machine

• Initializing the machine as an NIS+ client

However, as with setting up the root domain, setting up a client is not as simple as carrying out these three tasks in order.

To make the configuration process easier to execute, these tasks have been broken down into individual steps, and the steps have been arranged in the most efficient order:

1. Logging in to the domain's master server

2. Creating DES credentials for the new client machine

3. Ascertaining the Diffie-Hellman key length used on the master server

4. Logging in as superuser to the client

5. Assigning the client its new domain name

6. Stopping and restarting nscd

7. Checking the client's nsswitch.conf file

8. Setting the client's Diffie-Hellman key

9. Cleaning out leftover NIS+ material and processes

10. Initializing the client

11. Removing the /etc/.rootkey file and restarting the keyserv daemon

12. Running keylogin

13. Rebooting the client

Security Considerations When Configuring the NIS+ Client

Setting up a client has two main security requirements: both the administrator and the client must have the proper credentials and access rights. Otherwise, the only way for a client to obtain credentials in a domain running at security level 2 is for the credentials to be created by an administrator with valid DES credentials and modify rights to the cred table in the client's home domain. The administrator can either have DES credentials in the client's home domain or in the administrator's home domain.

After an administrator creates the client's credentials, the client can complete the configuration process. However, the client still needs read access to the directory object of its home domain. If you configured the client's home domain according to the instructions in either Chapter 5, Setting Up the NIS+ Root Domain or Chapter 8, Configuring an NIS+ Non-Root Domain, read access was provided to the world class by the NIS+ commands used to create the directory objects (nisinit and nismkdir, respectively).

You can check the directory object's access rights by using the niscat-o command. This command displays the properties of the directory, including its access rights:

rootmaster# niscat -o doc.com.
ObjectName : Doc
Owner : rootmaster.doc.com.
Group : admin.doc.com.
Domain : Com.
Access Rights : r---rmcdr---r---

You can change the directory object's access rights, provided you have modify rights to it yourself, by using the nischmod command, described in Chapter 15, Administering NIS+ Access Rights.

How to Configure an NIS+ Client

In this procedure you create credentials for the client, configure the client machine, and initialize it as an NIS+ client.

The NIS+ service is managed by the Service Management Facility (SMF). Administrative actions on this service, such as enabling, disabling, or restarting, can be performed by using the svcadm command. See NIS+ and the Service Management Facility for more information about using SMF with NIS+. For an overview of SMF, refer to Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M) and svcs(1) man pages for more details.

Before You Begin

Information you need to configure the client:

• The name of the client's home domain

• The superuser password of the machine that will become the client

• The IP address of an NIS+ server in the client's home domain

The administrator setting up the client's credentials must have:

• A valid DES credential

• Modify rights to the cred table in the client's home domain

The client must have:

• Read rights to the directory object of its home domain.

• The client's home domain must already be configured and running NIS+.

• An entry in either the master server's /etc/hosts or in its domain's hosts table.

  ---

  Note –

  Prior to the Solaris 10 7/07 release, an IPv6 client must have an entry in either the master server's /etc/inet/ipnodes file or in its domain's ipnodes table.

  ---

• A unique machine name that does duplicate any user ID.

• 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.)

1. Log in to the domain's master server.

   You can log in as superuser or as yourself, depending on which NIS+ principal has the proper access rights to add credentials to the domain's cred table.

2. Create DES credentials for the new client machine.

   Use the nisaddcred command with the -p and -P arguments. Here is the syntax:

   nisaddcred -p secure-RPC-netname principal-name des [domain]

   The secure-RPC-netname consists of the prefix unix followed by the client's host name, the symbol @ and the client's domain name, but without a trailing dot. The principal-name consists of the client's host name and domain name, with a trailing dot. If the client belongs to a different domain than the server from which you enter the command, append the client's domain name after the second argument.

   This example adds a DES credential for a client machine named client1 in the doc.com. domain:

   rootmaster% nisaddcred -p unix.client1@doc.com -P client1.doc.com. des Adding key pair for unix.client1@doc.com (client1.doc.com.). Enter client1.doc.com.'s root login passwd: Retype password:

   For more information about the nisaddcred command, see Chapter 12, Administering NIS+ Credentials.

3. Determine the Diffie-Hellman key length used on the master server.

   For example:

   rootmaster% nisauthconf dh640-0 des

4. Log in as superuser to the client.

   Now that the client machine has credentials, you can log out of the master server and begin working from the client itself. You can do this locally or remotely.

5. Assign the client its new domain name.

   See Changing an NIS+ Machine's Domain Name for information on how to assign (or change) a client's domain name, then return to Step 6.

6. Check the client's nsswitch.conf file.

   Make sure the client is using an NIS+ version of the nsswitch.conf file. This ensures that the primary source of information for the client will be NIS+ tables. See Example 1–1 for a description of an NIS+ switch file.

7. If you made any changes to the nsswitch.conf file (or copied over a new file), you must now restart nscd.

   client1# svcadm restart /system/name-service-cache

   (You do not need to stop and restart the keyserver at this point, as you will do so in Step 12.)

8. Set the Diffie-Hellman key length on the client, using the information from step 3.

   For example:

   client# nisauthconf dh640-0 des

9. Stop the NIS+ service.

   client1# svcadm disable network/rpc/nisplus:default client1# svcs \*nisplus\* disabled Jan_12 svc:/network/rpc/nisplus:default

10. Clean out leftover NIS+ material and processes.

    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.

    client1# ls /var/nis NIS_COLD_START NIS_SHARED_CACHE client1# rm -rf /var/nis/*

    This step makes sure that files left in /var/nis or directory objects stored by the cache manager are completely erased so that 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.

11. Initialize the client.

    You can initialize a client in three different ways: by host name, by cold-start file, or by broadcast. Choose and perform one of those methods. After initializing the client, proceed with Step 12.

12. Delete the /etc/.rootkey file and restart the keyserv daemon.

    This step stores the client's secret key on the keyserver.

    client1# cp /etc/nsswitch.nisplus /etc/nsswitch.conf client1# svcs \*keyserv\* online Jan_12 svc:/network/rpc/keyserv:default client1# svcadm disable network/rpc/keyserv client1# rm -f /etc/.rootkey client1# svcadm enable network/rpc/keyserv

Setting Up DNS Forwarding in NIS+

To enable DNS forwarding capabilities on an NIS+ client, perform the following:

How to Set Up DNS Forwarding in NIS+

1. Log in as superuser.

2. Properly configure the hosts line in the /etc/resolv.conf file to read: hosts:nisplus dns files.

   In this implementation of NIS+, if a /etc/resolv.conf file exists on the server, ypstart automatically starts the ypserv daemon with the -d option to forward requests to DNS.

Changing an NIS+ Machine's Domain Name

This task changes a machine's domain name. Since a machine's domain name is usually set during installation, you should check it by typing domainname without an argument before you perform this task.

How to Change an NIS+ Client's Domain Name

Use the domainname command to change the client machine domain

Before You Begin

You must perform this task as superuser on the machine whose domain name you are changing.

Information you need to change a client's domain name:

• The machine's superuser password

• The new domain name

1. Log in to the machine and become superuser.

   The examples in this task use client1 as the machine and doc.com. as the new domain name.

   client1% su Password:

2. Change the machine's domain name.

   Type the new name after the domainname command. Do not use a trailing dot. For example, to change a machine's domain to the doc.com domain, you enter:

   client1# domainname doc.com

   If the machine had been an NIS client, it may no longer be able to get NIS service.

3. Verify the result.

   Run the domainname command again, this time without an argument, to display the server's current domain.

   client1# domainname doc.com

4. Save the new domain name.

   Redirect the output of the domainname command into the /etc/defaultdomain file.

   client1# domainname > /etc/defaultdomain

5. At a convenient time, reboot the machine.

   Even after entering the new domain name into the /etc/defaultdomain file, some processes may still operate with the old domain name. To ensure that all processes are using the new domain name, reboot the machine.

   Because you may be performing this task in a sequence of many other tasks, examine the work remaining to be done on the machine before rebooting. Otherwise, you might find yourself rebooting several times instead of just once.

   Although restarting individual daemons, such as mountd may solve an NFS problem, it is strongly recommended that you reboot to synchronize configuration changes across daemons. This minimizes application failures caused by unknown changes to the configuration.

Initializing an NIS+ Client

The three different ways to initialize an NIS+ client are:

• Broadcast method (see Broadcast Initialization in NIS+)

• Host-name method (see Initializing an NIS+ Client by Using the Host Name Method)

• Cold-start file method (see Initializing an NIS+ Client by Using the Cold-Start Method)

Broadcast Initialization in NIS+

This method initializes an NIS+ client by sending an IP broadcast on the client's subnet.

This is the simplest way to configure a client but is also the least secure. The NIS+ server that responds to the broadcast sends the client all the information that the client needs in its cold-start file, including the server's public key. Presumably, only an NIS+ server will respond to the broadcast. However, the client has no way of knowing whether the machine that responded to the broadcast is indeed a trusted server. As a result, this method is only recommended for sites with small, secure networks.

Initializing an NIS+ Client by Using the Broadcast Method

How to Initialize an NIS+ Client by Broadcasting

Before You Begin

At least one NIS+ server must exist on the same subnet as the client. The client must use the same Diffie-Hellman key lengths as those on the master server. See nisauthconf(1M).

You must perform this task as superuser on the client. You need the superuser password to the client.

1. Initialize the client.

   This step initializes the client and creates a NIS_COLD_START file in its /var/nis directory. Use the nisinit command with the -c and -B options.

   client1# nisinit -c -B This machine is in the doc.com. NIS+ domain. Setting up NIS+ client ... All done.

   An NIS+ server on the same subnet will reply to the broadcast and add its location information into the client's cold-start file.

Initializing an NIS+ Client by Using the Host Name Method

Initializing a client by host name consists of explicitly identifying the IP address of its trusted server. This server's name, location information, and public keys are then placed in the client's cold-start file.

This method is more secure than the broadcast method because it actually specifies the IP address of the trusted server, rather than relying on a server to identify itself. However, if a router exists between the client and the trusted server, it could intercept messages to the trusted IP address and route them to an untrusted server.

How to Initialize an NIS+ Client by Host Name

Use the nisinit command to initialize an NIS+ client by host name.

Before You Begin

You must perform this operation as superuser on the client.

You need the name and IP address of the trusted server.

• The NIS+ service must be running in the client's domain.

• The client must have an entry in its /etc/hosts file for an IPv6 trusted server.

  ---

  Note –

  Prior to the Solaris 10 7/07 release, the client must have an entry in its /etc/inet/ipnodes file for its IPv6 trusted server.

  ---

• An entry in either the master server's /etc/hosts or in its domain's hosts table.

• The client must use the same Diffie-Hellman key lengths as those on the master server. See nisauthconf(1M).

1. Check the client's /etc/hosts file.

   ---

   Note –

   Prior to the Solaris 10 7/07 release, check the client's /etc/inet/ipnodes file.

   ---

   Make sure the client has an entry for the trusted server.

2. Initialize the client.

   This step initializes the client and creates a NIS_COLD_START file in its /var/nis directory. Use the nisinit command with the -c and -H options. This example uses rootmaster as the trusted server.

   Client1# nisinit -c -H rootmaster This machine is in the doc.com. NIS+ domain. Setting up NIS+ client ... All done.

   The nisinit utility looks for the server's address in the client's /etc/hosts file, so do not append a domain name to the server. If you do, the utility will not be able to find its address.

   ---

   Note –

   Prior to the Solaris 10 7/07 release, the nisinit utility looks for an IPv6 server's address in the client's/etc/inet/ipnodes file.

   ---

Initializing an NIS+ Client by Using the Cold-Start Method

This task initializes an NIS+ client by using the cold-start file of another NIS+ client, preferably one from the same domain. This is the most secure method of setting up an NIS+ client. It ensures that the client obtains its NIS+ information from a trusted server, something that cannot be guaranteed by the host-name or broadcast method.

How to Initialize an NIS+ Client With a Cold-Start File

Use the nisinit command with a cold-start file to initialize an NIS+ client.

Before You Begin

You must perform this task as superuser on the client.

• You need the name and location of the cold-start file you will copy.

• The servers specified in the cold-start file must already be configured and running NIS+.

• The client must use the same Diffie-Hellman key lengths as those on the master server. See nisauthconf(1M).

1. Copy the other client's cold-start file.

   Copy the other client's cold-start file into a directory in the new client. This may be easier to do while logged on as yourself rather than as superuser on the client. Be sure to switch back to superuser before initializing the client.

   Don't copy the NIS_COLD_START file into /var/nis, because that file gets overwritten during initialization. This example copies the cold-start file of previously initialized client1 into the /tmp directory of uninitialized client2.

   client2# exit client2% rcp client1:/var/nis/NIS_COLD_START /tmp client2% su

2. Initialize the client from the cold-start file.

   Use the nisinit command with the -c and -C options.

   client2# nisinit -c -C /tmp/NIS_COLD_START This machine is in the doc.com. NIS+ domain. Setting up NIS+ client ... All done.

NIS+ Client Configuration Summary

Table 6–1 shows a summary of the steps required to configure a client named client1 in the doc.com 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. For the sake of brevity, this summary does not show the responses to each command.