|Skip Navigation Links|
|Exit Print View|
|System Administration Guide: Naming and Directory Services (NIS+)|
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.
The How to Configure an NIS+ Root Domain 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 on NIS+ Root Domain Configuration Summary.
Here is a summary of the entire configuration process:
Log in as superuser to the root master server.
Check the root master server's domain name.
Check the root master server's switch-configuration file.
Optionally, configure the Diffie-Hellman key length.
Restart the name service cache (nscd), if you made any changes to the nsswitch.conf file.
Delete /etc/.rootkey and restart keyserv.
Stop the NIS+ service.
Clean out leftover NIS+ material and processes.
Name the root domain's admin group.
Create the root directory and initialize the root master server.
[Optional] Edit the /lib/svc/method/nisplus file to add desired options.
Start the NIS+ daemon.
Verify that the root objects were created.
Create the root domain's subdirectories and tables.
Create DES credentials for the root master server.
Create the root domain's admin group.
Add the root master to the root domain's admin group.
Update the root domain's public keys.
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+ 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.
Before proceeding, make sure that the following prerequisites have been met.
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.
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
The examples in these steps use rootmaster as the root master server and doc.com. as the root domain.
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.
If the name is not correct, change it.
rootmaster# domainname strange.domain rootmaster# domainname doc.com rootmaster# domainname rootmaster# doc.com rootmaster# rm -f /etc/defaultdomain rootmaster# domainname > /etc/defaultdomain
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).
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.
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
rootmaster# svcs \*name\* online Jan_12 svc:/system/name-service-cache:default rootmaster# svcadm restart system/name-service-cache
Because nscd caches the contents of the nsswitch.conf file, it is necessary to restart nscd after any change to the switch file.
Complete instructions are provided in Chapter 1, Name Service Switch.
rootmaster# cp /etc/nsswitch.nisplus /etc/nsswitch.conf rootmaster# svcs \*keyserv\* online Jan_12 svc:/network/rpc/keyserv:default rootmaster# svcadm disable network/rpc/keyserv rootmaster# rm -f /etc/.rootkey rootmaster# svcadm enable network/rpc/keyserv
rootmaster# svcs \*nisplus\* online Jan_12 svc:/network/rpc/nisplus:default rootmaster# svcadm disable network/rpc/nisplus:default rootmaster# svcs \*nisplus\* disabled Jan_12 svc:/network/rpc/nisplus:default
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:
rootmaster# ls /var/nis NIS_COLD_START NIS_SHARED_CACHE rootmaster# rm -rf /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.
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
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.
rootmaster# ls -l /var/nis/data -rw-rw-rw- 1 root other 384 date root.object
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.
You must include the -S 0 option. Use your preferred text editor.
See NIS+ and the Service Management Facility for more information about editing the /lib/svc/method/nisplus file.
Sets the server's security level to 0, which is required at this point for bootstrapping.
Because no cred table exists yet, no NIS+ principals can have credentials. If you use a higher security level, you are locked out of the server.
Supports DNS forwarding
Starts the NIS+ daemon in NIS-compatibility mode
rootmaster# svcadm enable network/rpc/nisplus:default
Your namespace should now have:
A root directory object (root.dir)
A root master server (rootmaster) running the NIS+ service
A cold start file for the master server (NIS_COLD_START)
A transaction log file (trans.log)
A table dictionary file (data.dict)
The root directory object is stored in the directory created in Step 10. Verify that it is there.
rootmaster# ls -l /var/nis/data -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.
rootmaster# nisls -l doc.com. doc.com.:
However, it has several object properties, which you can examine using niscat -o:
rootmaster# niscat -o doc.com. Object Name : doc Owner : rootmaster.doc.com. Group : admin.doc.com. Domain : Com. Access Rights : r---rmcdrmcdr---
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.)
To verify that the NIS+ daemon is running, use the ps command.
rootmaster# ps -e | 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.
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.
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 -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.
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: firstname.lastname@example.org Adding key pair for email@example.com (rootmaster.doc.com.). Enter login password: Wrote secret key into /etc/.rootkey
Enter login password: nisaddcred: WARNING: password differs from login password. Retype 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.
nisaddcred: WARNING: password differs from login password. Retype password: nisaddcred: password incorrect. nisaddcred: unable to create credential.
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.
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.
doc.com. Object Name : admin Directory : groups_dir.doc.com Owner : rootmaster.doc.com. Group : admin.doc.com. Domain : groups_dir.doc.com. Access Rights : ----rmcdr---r--- Time to Live : 1:0:0 Object Type : GROUP Group Flags : Group Members :
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.
rootmaster# nisgrpadm -a admin.doc.com. rootmaster.doc.com. Added rootmaster.doc.com. to group admin.doc.com.
To verify that the root master is indeed a member of the group, use the nisgrpadm command with the -l option (see Chapter 17, Administering NIS+ Groups).
Note - 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
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.)
rootmaster# /usr/lib/nis/nisupdkeys doc.com. rootmaster# /usr/lib/nis/nisupdkeys org_dir.doc.com. rootmaster# /usr/lib/nis/nisupdkeys groups_dir.doc.com.
After each instance, you will receive a confirmation message such as this one:
Fetch Public key for server rootmaster.doc.com. netname = 'firstname.lastname@example.org.' Updating rootmaster.doc.com.'s public key. Public key:
Public key: Diffie-Hellman (192 bits)
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.
For an NIS-compatible root domain, be sure to edit the /lib/svc/method/nisplus file to add the -Y flag. See NIS+ and the Service Management Facility for more information.
rootmaster# svcs \*nisplus\* online Jan_12 svc:/network/rpc/nisplus:default rootmaster# svcadm restart network/rpc/nisplus:default
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.
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.
rootmaster# nisaddcred -p 11177 -P topadmin.doc.com. local
For more information about the nisaddcred command, see Chapter 12, Administering NIS+ Credentials.
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 email@example.com -P topadmin.doc.com. des Adding key pair for firstname.lastname@example.org (topadmin.doc.com.). Enter login password:
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 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.
rootmaster# nisaddcred -p 33355 -P miyoko.doc.com. local rootmaster# nisaddcred -p email@example.com -P miyoko.doc.com. des Adding key pair for firstname.lastname@example.org (miyoko.doc.com.). Enter login password:
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.)
rootmaster# nistbladm -D owner=miyoko.doc.com. name=miyoko uid=33355 gcos=miyoko home=/home/miyoko shell=/bin/tcsh passwd.org_dir rootmaster# nisaddent -a -f /etc/passwd.xfr passwd rootmaster# nisaddent -a -f /etc/shadow.xfr shadow rootmaster# nisaddcred -p 33355 -P miyoko.doc.com. local rootmaster# nisaddcred -p email@example.com -P miyoko.doc.com. des Adding key pair for firstname.lastname@example.org (miyoko.doc.com.). Enter miyoko's login password: nisaddcred: WARNING: password differs from login passwd. Retype password: rootmaster# nischown miyoko.doc.com. '[name=miyoko],passwd.org_dir'
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.
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:
rootmaster# nisgrpadm -a admin.doc.com. topadmin.doc.com. miyoko.doc.com. Added topadmin.doc.com. to group admin.doc.com. Added miyoko.doc.com. to group admin.doc.com.
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:
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.