Member users of an object's group usually have special privileges to access that object, such as permission to make certain changes to the object. For example, you could add several junior administrators to the admin group so that they can only modify the passwd and hosts tables, but they would be unable to modify any other tables. By using an admin group, you can distribute administration tasks across many users and not just reserve them for the superuser of the entire hierarchy. The NIS+ admin group must have credentials created for its members, even if you are running the domain in NIS-compatibility mode, because only authenticated users have permission to modify NIS+ tables.
After identifying the type of credentials you need, you should select the access rights that are required in the namespace. To make that task easier, you should first decide how many administrative groups you need. Using separate groups is useful when you want to assign them different rights. Usually, you create groups by domain. Each domain should have only one admin group.
Planning Access Rights to NIS+ Groups and Directories
After arranging your principals into groups, determine the kinds of access rights granted by the objects in the namespace to those groups, as well as to the other classes of principal (nobody, owner, group, and world). Planning these assignments ahead of time will help you establish a coherent security policy.
As shown in Table 26-7, NIS+ provides different default access rights for different namespace objects.
Table 26-7 Default Access Rights for NIS+ Objects
Object | Nobody | Owner | Group | World |
|---|---|---|---|---|
Root-directory object | r--- | rmcd | rmcd | r--- |
Non-root directory object | r--- | rmcd | rmcd | r--- |
groups_dir directory objects | r--- | rmcd | rmcd | r--- |
org_dir directory objects | r--- | rmcd | rmcd | r--- |
NIS+ groups | ---- | rmcd | r--- | r--- |
NIS+ tables | varies | varies | varies | varies |
You can use the default rights or assign your own. If you assign your own, you must consider how the objects in your namespace will be accessed. Keep in mind that the nobody class accepts all requests from NIS+ clients, whether authenticated or not. The world class comprises all authenticated requests from NIS+ clients. Therefore, if you don't want to provide namespace access to unauthenticated requests, don't assign any access rights to the nobody class; reserve them only for the world class. On the other hand, if you expect some clients--through applications, for instance--to make unauthenticated read requests, you should assign read rights to the nobody class. If you want to support NIS clients in NIS-compatibility mode, you must assign read rights to the nobody class.
Also consider the rights that each type of namespace object assigns to the NIS+ groups you specified earlier. Depending on how you plan to administer the namespace, you can assign all or some of the available access rights to the group. A good solution is to have the user root on the master server be the owner of the admin group. The admin group should have create and destroy rights on the objects in the root domain. If you want only one administrator to create and modify the root domain, then put just that administrator in the admin group. You can always add additional members to the group. If several administrators are involved in the setup process, put them all in the group and assign full rights to it. That is easier than switching ownership back and forth.
Finally, the owner of an object should have full rights, although this is not as important if the group does. A namespace is more secure if you give only the owner full rights, but it is easier to administer if you give the administrative group full rights.
Planning Access Rights to NIS+ Tables
NIS+ objects other than NIS+ tables are primarily structural. NIS+ tables, however, are a different kind of object: they are informational. Access to NIS+ tables is required by all NIS+ principals and applications running on behalf of those principals. Therefore, their access requirements are a somewhat different.
Table 26-8 lists the default access rights assigned to NIS+ tables. If any columns provide rights in addition to those of the table, they are also listed. You can change these rights at the table and entry level with the nischmod command, and at the column level with the nistbladm -u command. "Protecting the Encrypted Passwd Field" provides just one example of how to change table rights to accommodate different needs.
Table 26-8 Default Access Rights for NIS+ Tables and Columns
Table/Column | Nobody | Owner | Group | World | |
|---|---|---|---|---|---|
hosts table | r--- | rmcd | rmcd | r--- | |
bootparams table | r--- | rmcd | rmcd | r--- | |
passwd table | ---- | rmcd | rmcd | r--- | |
| name column | r--- | ---- | ---- | ---- |
| passwd column | ---- | -m-- | ---- | ---- |
| uid column | r--- | ---- | ---- | ---- |
| gid column | r--- | ---- | ---- | ---- |
| gcos column | r--- | -m-- | ---- | ---- |
| home column | r--- | ---- | ---- | ---- |
| shell column | r--- | ---- | ---- | ---- |
| shadow column | ---- | ---- | ---- | ---- |
group table | ---- | rmcd | rmcd | r--- | |
| name column | r--- | ---- | ---- | ---- |
| passwd column | ---- | -m-- | ---- | ---- |
| gid column | r--- | ---- | ---- | ---- |
| members column | r--- | -m-- | ---- | ---- |
cred table | r--- | rmcd | rmcd | r--- | |
| cname column | ---- | ---- | ---- | ---- |
| auth_type column | ---- | ---- | ---- | ---- |
| auth_name column | ---- | ---- | ---- | ---- |
| public_data column | ---- | -m-- | ---- | ---- |
| private_data column | ---- | -m-- | ---- | ---- |
networks table | r--- | rmcd | rmcd | r--- | |
netmasks table | r--- | rmcd | rmcd | r--- | |
ethers table | r--- | rmcd | rmcd | r--- | |
services table | r--- | rmcd | rmcd | r--- | |
protocols table | r--- | rmcd | rmcd | r--- | |
rpc table | r--- | rmcd | rmcd | r--- | |
auto_home table | r--- | rmcd | rmcd | r--- | |
auto_master table |
| rmcd | rmcd | r--- | |
Note - NIS-compatible domains give the nobody class read rights to the passwd table at the table level.
Protecting the Encrypted Passwd Field
As you can see in Table 26-8, default read access is provided to the nobody class by all tables except the passwd table. NIS+ tables give the nobody class read access because many applications that need to access NIS+ tables run as unauthenticated clients. However, if this were also done for the passwd table, it would expose the encrypted passwd column to unauthenticated clients.
The configuration shown in Table 26-8 is the default set of access rights for NIS-compatible domains. NIS-compatible domains must give the nobody class read access to the passwd column because NIS clients are unauthenticated and would otherwise be unable to access their passwd column. Therefore, in an NIS-compatible domain, even though passwords are encrypted, they are vulnerable to decoding. They would be much more secure if they were not readable by anyone except their owner.
Standard NIS+ domains (not NIS-compatible) provide that extra level of security. The default configuration (provided by nissetup) uses a column-based scheme to hide the passwd column from unauthenticated users, while still providing access to the rest of the passwd table. At the table level, no unauthenticated principals have read access. At the column level, they have read access to every column except the passwd column.
How does an entry owner get access to the passwd column? Entry owners have both read and modify access to their own entries. They obtain read access by being a member of the world class. (Remember that at the table level, the world class has read rights.) They obtain modify access by explicit assignment at the column level.
Keep in mind that table owners and entry owners are rarely and not necessarily the same NIS+ principals. Thus, table-level read access for the owner does not imply read access for the owner of any particular entry.
As mentioned earlier, this is the default setup from the Solaris 2.3 release through Solaris 9. For a more complete explanation and discussion of table-, entry-, and column level-security, see Chapter 16, Administering Passwords.
Using NIS Compatibility Mode: An Introduction
Deciding whether and how to run NIS+ in parallel to NIS--and when to stop--is probably one of the most difficult transition issues you will face. NIS+ provides several features that allow it to operate in parallel with NIS, notably, the NIS-compatibility mode.
If you plan to use NIS-compatibility mode, you have to consider the essential benefit provided by NIS-compatibility mode. You need not make any changes to NIS clients. The essential drawback is that you cannot take advantage of full NIS+ security and hierarchy and you may have to change those clients' domain names.
Figure 26-11 illustrates how you convert from an NIS-only namespace to an NIS-compatible namespace that responds to both NIS and NIS+ requests.
Figure 26-11 Transition to NIS-Compatibility Mode
Selecting Your NIS-Compatible Domains
Make a list of your NIS clients and group them in their eventual NIS+ domains. If the NIS+ domain running in NIS-compatibility mode does not have the same name as its NIS clients' original NIS domain, you must change the NIS clients' domain name to the NIS+ domain name that is being supported by the NIS-compatible NIS+ server.
At first, NIS will no doubt be the primary service. As you become familiar with the intricacies of sharing information, you can plan a transition to make NIS+ the primary service. Some NIS+ users may want the capability of switching back and forth between the main NIS domain and the new NIS+ domain. The nisclient script can help them do this when backup files are made.
Determining NIS-Compatible Server Configuration
Take stock of your NIS servers, keeping in mind the requirements for your NIS+ servers. If you plan to eventually use them for the NIS+ service, upgrade them to the NIS+ recommendations. Identify which NIS servers will be used to support which NIS+ domains, and in what capacity (either master or replica). Remember that NIS+ servers belong to the domain above the one they support (except for the root domain servers). Since NIS+ servers do not belong to the domain they serve, you cannot use the same machines for other services that require domain-dependent information.
If possible, plan to use your NIS+ server machines only for NIS+. This arrangement can require you to transfer other network services, such as DNS name services, boot server, home directories, NFS servers, and so on, to non-NIS+ server machines.
At many sites, the NIS server plays multiple roles, such as NFS server, compute server, rlogin server, and mail host server. Because the NIS server uses the same information to resolve its names as do its clients, the NIS server can provide other services as well. As discussed in "Domain Hierarchy", except for root domains, all NIS+ servers live in the domain above the ones that they serve. So either do not run services on an NIS+ server that require access to the name service, or use other means, such as files in nsswitch.conf, to acquire this same information. This problem would be solved if there were no hierarchy; the NIS+ root servers would live in the domain that they serve. The resource requirements of an NIS+ server are greater than those of an NIS server; therefore, it is advisable to avoid running other services along with NIS+.
If you have non-Solaris machines on your network, then you can either continue to run your NIS+ servers in NIS-compatibility mode or you can move all such machines into their own domain. If you move all non-Solaris machines to one subnet, you can remove the restriction of having NIS+ servers on the same subnet as their NIS-compatible clients. This will reduce the number of replicas required for any domain.
Deciding How to Transfer Information Between Services
To keep information synchronized, be sure to make one namespace subordinate to the other. At first, the NIS namespace may be the dominant one, in which case you would make changes to the NIS maps and load them into the NIS+ tables. In effect, the NIS namespace would be the master database.
An NIS+ server in NIS-compatibility mode supports standard NIS maps. An exhaustive list of these maps is in the Notes section of the ypfiles(4) man page. However, there are some limitations on map support: The NIS+ server serves ypmatch requests only on the netgroup map, and not on the reverse maps. It does not support enumeration requests on the netgroup map (for example, ypcat). The passwd.adjunct map is not supported, either.
Eventually, the NIS+ namespace should be dominant. When that is the case, you make changes in the NIS+ tables and copy them to the NIS maps.
The NIS+ nisaddent command and the NIS+ nispopulate script transfer information between NIS maps and NIS+ tables, as summarized in Table 26-9.
Table 26-9 Commands for Changing Information in the Passwd Table
NIS+ Command | Description |
|---|---|
/usr/lib/nis/nisaddent -y | Transfers information from an NIS map to an NIS+ table after you run ypxfr to transfer maps from an NIS server to the local disk. Nonstandard NIS maps can be transferred to NIS+ tables if the information is in key-value pairs. Multicolumned maps will be not be transferred. |
/usr/lib/nis/nisaddent -d | Copies information from an NIS+ table to a file, which can then be transferred to an NIS map with standard NIS utilities. |
/usr/lib/nis/nispopulate -Y | Transfers information from NIS maps to NIS+ tables. |
In versions of NIS+ previous to the Solaris 2.5 release, it was necessary to use separate password commands (passwd, yppasswd, nispasswd) to handle password matters, depending on whether a user's password information was stored in /etc files, NIS maps, or NIS+ tables. Starting with the Solaris 2.5 release, all of these matters are handled automatically by the passwd or passwd -r nisplus commands and are controlled by the passwd entry in the user's nsswitch.conf file.
In order to properly implement the passwd command and password aging on your NIS+ or NIS-compatible network, the passwd entry of the nsswitch.conf file on every machine must be correct. This entry determines where the passwd command goes for password information and where it updates password information.
Only five passwd entry configurations are permitted:
Example 26-2 Permitted passwd nsswitch.conf Entries
passwd:files passwd: files nis passwd: files nisplus passwd: compat passwd_compat: nisplus |
Caution - All of the nsswitch.conf files on all
of your network's machines must use one of the passwd configurations
shown above. If you configure the passwd entry in any other
way, users may not be able to log in.
In domains created with NIS-compatibility mode, the permissions are slightly different: permissions at the table level must be set to provide read rights to the world class, and at the column level, permissions must provide read access to the nobody class.