Part III NIS+ Administration

This part describes the administration and troubleshooting of the NIS+ naming service in the Solaris OS.

Chapter 10 NIS+ Tables and Information

This chapter describes the structure of NIS+ tables and provides a brief overview of how they can be set up.

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.

NIS+ Table Structure

NIS+ stores a wide variety of network information in tables. NIS+ tables provide several features not found in simple text files or maps. They have a column-entry structure, they accept search paths, they can be linked together, and they can be set up in several different ways. NIS+ provides 16 preconfigured system tables, and you can also create your own tables. Table 10–1 lists the preconfigured NIS+ tables.

As a naming service, NIS+ tables are designed to store references to objects, not the objects themselves. For this reason, NIS+ does not support tables with large entries. If a table contains excessively large entries, rpc.nisd may fail.

Because it contains only information related to NIS+ security, the Cred table, is described in Chapter 12, Administering NIS+ Credentials.

These tables store a wide variety of information, ranging from user names to Internet services. Most of this information is generated during a setup or configuration procedure. For instance, an entry in the passwd table is created when a user account is set up. An entry in the hosts table is created when a machine is added to the network. And an entry in the networks table is created when a new network is set up.

Since this information is generated from such a wide field of operations, much of it is beyond the scope of this manual. However, as a convenience, Chapter 23, Information in NIS+ Tables summarizes the information contained in each column of the tables, providing details only when necessary to keep things from getting confusing, such as when distinguishing groups from NIS+ groups and netgroups. For thorough explanations of the information, consult Solaris system and network administration manuals.

You can create more automounter maps for a domain, but be sure to store them as NIS+ tables and list them in the auto_master table. When creating additional automount maps to supplement auto_master (which is created for you), the column names must include key and value. For more information about the automounter, consult books about the automounter or books that describe the NFS file system.

NIS+ Columns and Entries

Although NIS+ tables store different types of information, they all have the same underlying structure; they are each made up of rows and columns (the rows are called “entries” or “entry objects”):

A client can access information by a key, or by any column that is searchable. For example, to find the network address of a machine named baseball, a client could look through the hostname column until it found baseball.

It then would move along the baseball entry to find its network address:

Because a client can access table information at any level, NIS+ provides security mechanisms for all three levels. For instance, an administrator could assign read rights to everyone for a table at the object level, modify rights to the owner at the column level, and modify rights to the group at the entry level. Details about table security are provided in Chapter 15, Administering NIS+ Access Rights.

NIS+ Search Paths

A table contains information only about its local domain. For instance, tables in the doc.com. domain contain information only about the users, clients, and services of the doc.com. domain. The tables in the sales.doc.com. domain store information only about the users, clients, and services of the sales.doc.com. domain. And so on.

If a client in one domain tries to find information that is stored in another domain, it has to provide a fully qualified name. As described in NIS+ NIS_PATH Environment Variable if the NIS_PATH environment variable is set up properly, the NIS+ service will do this automatically.

Every NIS+ table can also specify a search path that a server will follow when looking for information. The search path is an ordered list of NIS+ tables, separated by colons:

table:table:table...

The table names in the search path don't have to be fully qualified; they can be expanded just like names entered at the command line. When a server cannot find information in its local table, it returns the table's search path to the client. The client uses that path to look for the information in every table named in the search path, in order, until it finds the information or runs out of names.

Here is an example that demonstrates the benefit of search paths. Assume the following domain hierarchy:

The hosts tables of the lower two domains contain the following information.

Assume now that a user logged onto the luna machine in the sales.doc.com. domain wants to log in remotely to another client. Without providing a fully qualified name, that user can only remotely log in to five machines: localhost, phoebus, europa, ganymede, and the mailhost.

Now assume that the search path of the hosts table in the sales.doc.com. domain listed the hosts table from the manf.doc.com. domain:

hosts.org_dir.manf.doc.com.

Now a user in the sales.doc.com. domain can enter something like rlogin sirius, and the NIS+ server will find it. It will first look for sirius in the local domain, but when it does not find a match, it will look in the manf.doc.com. domain. How does the client know how to find the manf.doc.com. domain? As described in Chapter 2, NIS+: An Introduction, the information is stored in its directory cache. If it is not stored in its directory cache, the client will obtain the information by following the process described in Chapter 2, NIS+: An Introduction.

There is a slight drawback, though, to specifying a search path. If the user were to enter an incorrect name, such as rlogin luba (rather than “luna”), the server would need to look through three tables – instead of just one – before returning an error message. If you set up search paths throughout the namespace, an operation may end up searching through the tables in 10 domains instead of just 2 or 3. Another drawback is a performance loss from having many clients contact more than one set of servers when they need to access NIS+ tables.

You should also be aware that since “mailhost” is often used as an alias, when trying to find information about a specific mailhost, you should use its fully qualified name (for example, mailhost.sales.doc.com.), or NIS+ will return all the mailhosts it finds in all the domains it searches through.

You can specify a table's search path by using the -p option to the nistbladm command, as described in Using the nistbladm Command With NIS+ Tables.

Ways to Set Up NIS+ Tables

Setting up NIS+ tables involves three or four tasks:

1. Creating the org_dir directory

2. Creating the system tables

3. Creating non-system tables (optional)

4. Populating the tables with information

As described in NIS+ Files and Directories, NIS+ system tables are stored under an org_dir directory. So, before you can create any tables, you must create the org_dir directory that will hold them. You can do this in three ways.

• Use the nisserver script. The nisserver script creates the appropriate directories and a full set of system tables. Running the nisserver script is the recommended method.

• Use the nismkdir command. The nismkdir command simply creates the directory.

• Use the /usr/lib/nis/nissetup utility. The nissetup utility creates the org_dir and groups_dir directories and a full set of system tables.

The nisserver script and the nissetup and nismkdir utilities are described in nismkdir Command. Additional information on the nismkdir command can be found in nismkdir Command.

A benefit of the nissetup utility is its capability to assign the proper access rights to the tables of a domain whose servers are running in NIS-compatibility mode. When entered with the -Y flag, it assigns read permissions to the nobody class of the objects it creates, allowing NIS clients, who are unauthenticated, to get information from the domain's NIS+ tables.

The 16 NIS+ system tables and the type of information they store are described in Table 10–1. To create them, you could use one of the three ways mentioned above. The nistbladm utility also creates and modifies NIS+ tables. You could conceivably create all the tables in a namespace with the nistbladm command, but you would have to type much more and you would have to know the correct column names and access rights. A much easier way is to use the nisserver script.

To create a non-system table – that is, a table that has not been preconfigured by NIS+ – use the nistbladm command. (Note that if you are creating additional automount maps, the first column must be named key and the second column named value.)

You can populate NIS+ tables in three ways: from NIS maps, from ASCII files (such as /etc files), and manually.

If you are upgrading from the NIS service, you already have most of your network information stored in NIS maps. You don't have to re-enter this information manually into NIS+ tables. You can transfer it automatically with the nispopulate script or the nisaddent utility.

If you are not using another network information service, but maintain network data in a set of /etc files, you don't have to re-enter this information, either. You can transfer it automatically, also using the nispopulate script or the nisaddent utility.

If you are setting up a network for the first time, you may not have much network information stored anywhere. In that case, you'll need to first get the information and then enter it manually into the NIS+ tables. You can do this with the nistbladm command. You can also do it by entering all the information for a particular table into an input file& – is essentially the same as an /etc file – and then transferring the contents of the file with the nispopulate script or the nisaddent utility.

How NIS+ Tables Are Updated

When a domain is set up, its servers receive their first versions of the domain's NIS+ tables. These versions are stored on disk, but when a server begins operating, it loads them into memory. When a server receives an update to a table, it immediately updates its memory-based version of the table. When it receives a request for information, it uses the memory-based copy for its reply.

Of course, the server also needs to store its updates on disk. Since updating disk-based tables takes time, all NIS+ servers keep log files for their tables. The log files are designed to temporarily store changes made to the table, until they can be updated on disk. They use the table name as the prefix and append .log. For example:

hosts.org_dir.log
bootparams.org_dir.log
password.org_dir.log

You should update disk-based copies of a table on a daily basis so that the log files don't grow too large and take up too much disk space. This process is called checkpointing. To do this, use the nisping -C command.

Chapter 11 NIS+ Security Overview

This chapter describes the NIS+ security system and how it affects the entire NIS+ namespace.

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.

Solaris Security and NIS+

In essence, Solaris security is provided by gates that users must pass through in order to enter the Solaris system, and permission matrixes that determine what they are able to do once inside. (See Figure 11–1 for a schematic representation of this system.)

Figure 11–1 Solaris Security Gates and Filters

As you can see in the above figure, the overall system is composed of four gates and two permission matrixes:

• Dialup gate. To access a given Solaris system from the outside through a modem and phone line, you must provide a valid login ID and dialup password.

• Login gate. To enter a given Solaris system you must provide a valid login ID and user password.

• File and Directory Matrix. Once you have gained access to a Solaris system, your ability to read, execute, modify, create, and destroy files and directories is governed by the applicable permissions matrix.

• Root gate. To gain access to root privileges, you must provide a valid super user (root) password.

• Secure RPC gate. In an NIS+ environment running at security level 2 (the default), when you try to use NIS+ services and gain access to NIS+ objects (servers, directories, tables, table entries, and so forth) your identity is confirmed by NIS+ using the Secure RPC process.

  Consult your Solaris documentation for detailed descriptions of the Dialup, Login, and Root gates, and the File and Directory permissions matrix.

  To enter the Secure RPC gate requires presentation of a Secure RPC password. (In some contexts Secure RPC passwords have been referred to as network passwords.) Your Secure RPC password and your login password normally are identical and when that is the case you are passed through the gate automatically without having to re-enter your password. (See Secure RPC Passwords and the Login Password Problem in NIS+ for information regarding cases where the two passwords are not the same.)

  A set of credentials are used to automatically pass your requests through the Secure RPC gate. The process of generating, presenting, and validating your credentials is called authentication because it confirms who you are and that you have a valid Secure RPC password. This authentication process is automatically performed every time you request an NIS+ service.

  In an NIS+ environment running in NIS-compatibility mode (also known as YP-compatibility mode), the protection provided by the Secure RPC gate is significantly weakened because everyone has read rights for all NIS+ objects and modify rights for those entries that apply to them regardless of whether or not they have a valid credential (that is, regardless of whether or not the authentication process has confirmed their identity and validated their Secure RPC password). Since that allows anyone to have read rights for all NIS+ objects and modify rights for those entries that apply to them, an NIS+ network running in compatibility mode is less secure than one running in normal mode.

  For details on how to create and administer NIS+ authentication and credentials, see Chapter 12, Administering NIS+ Credentials.

• NIS+ objects matrix. Once you have been properly authenticated to NIS+ your ability to read, modify, create, and destroy NIS+ objects is governed by the applicable permissions matrix. This process is called NIS+ authorization.

  For details NIS+ permissions and authorization, see Chapter 15, Administering NIS+ Access Rights.

NIS+ Security Overview

NIS+ security is an integral part of the NIS+ namespace. You cannot set up security and the namespace independently. For this reason, instructions for setting up security are woven through the steps used to set up the other components of the namespace. Once an NIS+ security environment has been set up, you can add and remove users, change permissions, reassign group members, and all other routine administrative tasks needed to manage an evolving network.

The security features of NIS+ protect the information in the namespace, as well as the structure of the namespace itself, from unauthorized access. Without these security features, any NIS+ client could obtain and change information stored in the namespace or even damage it.

NIS+ security does two things:

• Authentication. Authentication is used to identify NIS+ principals. Every time a principal (user or machine) tries to access an NIS+ object, the user's identity and Secure RPC password is confirmed and validated.

• Authorization. Authorization is used to specify access rights. Every time NIS+ principals try to access NIS+ objects, they are placed in one of four authorization classes (owner, group, world, nobody). The NIS+ security system allows NIS+ administrators to specify different read, modify, create, or destroy rights to NIS+ objects for each class. Thus, for example, a given class could be permitted to modify a particular column in the passwd table but not read that column, or a different class could be allowed to read some entries of a table but not others.

In essence, then, NIS+ security is a two-step process:

1. Authentication. NIS+ uses credentials to confirm that you are who you claim to be.

2. Authorization. Once your identity is established by the authentication process, NIS+ determines your class. What you can do with a given NIS+ object or service depends on which class you belong to. This is similar in concept to the standard UNIX file and directory permissions system. (See NIS+ Authorization Classes for more information on classes.)

This process, for example, prevents someone with root privileges on machine A from using the su command to assume the identity of a second user and then accessing NIS+ objects with the second user's NIS+ access privileges.

Note, however, that NIS+ cannot prevent someone who knows another user's login password from assuming that other user's identity and NIS+ access privileges. Nor can NIS+ prevent a user with root privileges from assuming the identity of another user who is logged in from the same machine.

Figure 11–2 details this process.

Figure 11–2 Summary of the NIS+ Security Process

NIS+ Principals

NIS+ principals are the entities (clients) that submit requests for NIS+ services. An NIS+ principal may be someone who is logged in to a client machine as a regular user, someone who is logged in as superuser, or any process that runs with superuser permission on an NIS+ client machine. Thus, an NIS+ principal can be a client user or a client machine.

An NIS+ principal can also be the entity that supplies an NIS+ service from an NIS+ server. Since all NIS+ servers are also NIS+ clients, much of this discussion also applies to servers.

NIS+ Security Levels

NIS+ servers operate at one of two security levels. These levels determine the type of credential principals that must submit for their requests to be authenticated. NIS+ is designed to run at the most secure level, which is security level 2. Level 0 is provided only for testing, setup, and debugging purposes. These security levels are summarized in Table 11–1.

NIS+ Security Levels and Password Commands

In Solaris releases 2.0 through 2.4, you used the nispasswd command to change your password. However, nispasswd could not function without credentials. (In other words, it could not function under security level 0 unless there were credentials existing from some previous higher level.) Starting with the Solaris 2.5 release, the passwd command must be used to change your own password regardless of security level or credential status.

NIS+ Authentication and Credentials

The purpose of NIS+ credentials is to authenticate (confirm) the identity of each principal requesting an NIS+ service or access to an NIS+ object. In essence, the NIS+ credential/authorization process is an implementation of the Secure RPC system.

The credential/authentication system prevents someone from assuming some other user's identity. That is, it prevents someone with root privileges on one machine from using the su command to assume the identity of a second user who is not logged in and then accessing NIS+ objects with the second user's NIS+ access privileges.

Once a server authenticates a principal, the principal is placed in one of four authorization classes. The server then checks the NIS+ object that the principal wants to access to see what activities that class of principal is authorized to perform. (See NIS+ Authorization and Access for further information on authorization.)

NIS+ User and Machine Credentials

There are two basic types of principal, users and machines, and thus two different types of credentials:

• User credentials. When someone is logged in to an NIS+ client as a regular user, requests for NIS+ services include that person's user credentials.

• Machine credentials. When a user is logged in to an NIS+ client as superuser, request for services use the client machine's credentials.

DES Credentials and LOCAL Credentials in NIS+

NIS+ principals can have two types of credential: DES and LOCAL.

DES Credentials in NIS+

DES credentials are only one method of achieving authentication. In the future, other methods may be available. Thus, do not equate DES credentials with NIS+ credentials.

In this document, the term DES credentials is used generically to denote a Diffie-Hellman key based authentication, regardless of key length. The system allows you to specify the key length from a pre-determined set. Use nisauthconf to set or display the Diffie-Hellman key length.

DES (Data Encryption Standard) credentials are the type of credential that provide secure authentication. When this guide refers to NIS+ checking a credential to authenticate an NIS+ principal, it is the DES credential that NIS+ is validating.

Each time a principal requests an NIS+ service or access to an NIS+ object, the software uses the credential information stored for that principal to generate a credential for that principal. DES credentials are generated from information created for each principal by an NIS+ administrator, as explained in Chapter 12, Administering NIS+ Credentials.

• When the validity of a principal's DES credential is confirmed by NIS+, that principal is authenticated.

• A principal must be authenticated in order to be placed in the owner, group, or world authorization classes. In other words, you must have a valid DES credential in order to be placed in one of those classes. (Principals who do not have a valid DES credential are automatically placed in the nobody class.)

• DES credential information is always stored in the cred table of the principal's home domain, regardless of whether that principal is a client user or a client machine.

LOCAL Credentials in NIS+

LOCAL credentials are simply a map between a user's User ID number and NIS+ principal name which includes their home domain name. When users log in, the system looks up their LOCAL credential, which identifies their home domain where their DES credential is stored. The system uses that information to get the user's DES credential information.

When users log in to a remote domain, those requests use their LOCAL credential which points back to their home domain; NIS+ then queries the user's home domain for that user's DES credential information. This allows a user to be authenticated in a remote domain even though the user's DES credential information is not stored in that domain.

Figure 11–3 NIS+ Credentials and Domains

LOCAL credential information can be stored in any domain. In fact, in order to log into a remote domain and be authenticated, a client user must have a LOCAL credential in the cred table of the remote domain. If a user does not have a LOCAL credential in a remote domain the user is trying to access, NIS+ will be unable to locate the user's home domain to obtain the user's DES credential. In such a case the user would not be authenticated and would be placed in the nobody class.

NIS+ User Types and Credential Types

A user can have both types of credentials, but a machine can only have DES credentials.

Root cannot have NIS+ access, as root, to other machines because the root UID of every machine is always zero. If root (UID=0) of machine A tried to access machine B as root, that would conflict with machine B's already existing root (UID=0). Thus, a LOCAL credential doesn't make sense for a client machine; so it is allowed only for a client user.

NIS+ Authorization and Access

The basic purpose of NIS+ authorization is to specify the access rights that each NIS+ principal has for each NIS+ object and service.

Once the principal making an NIS+ request is authenticated, NIS+ places them in an authorization class. The access rights (permissions) that specify which activities a principal may do with a given NIS+ object are assigned on a class basis. In other words, one authorization class may have certain access rights while a different class has different rights.

• Authorization classes. There are four authorization classes: owner, group, world, and nobody. (See NIS+ Authorization Classes below for details.)

• Access rights. There are four types of access rights (permissions): create, destroy, modify, and read. (See NIS+ Access Rights for details.)

NIS+ Authorization Classes

NIS+ objects do not grant access rights directly to NIS+ principals.

Instead, they grant access rights to four classes of principal:

• Owner. The principal who happens to be the object's owner gets the rights granted to the owner class.

• Group. Each NIS+ object has one group associated with it. The members of an object's group are specified by the NIS+ administrator. The principals who belong to the object's group class get the rights granted to the group class. (In this context, group refers to NIS+ groups, not UNIX or net groups.)

• World. The world class encompasses all NIS+ principals that a server has been able to authenticate. (That is, everyone who has been authenticated but who is not in either the owner or group classes.)

• Nobody. Everyone belongs to the nobody class even those who are not authenticated.

Figure 11–4 Authorization Classes in NIS+

For any NIS+ request, the system determines which class the requesting principal belongs to and the principal then can use whatever access rights belonging to that class.

An object can grant any combination of access rights to each of these classes. Normally, however, a higher class is assigned the same rights as all the lower classes, plus possible additional rights.

For instance, an object could grant read access to the nobody and world classes; both read and modify access to the group class; and read, modify, create, and destroy access to the owner class.

The four classes are described in detail below.

NIS+ Owner Class

The owner is a single NIS+ principal.

A principal making a request for access to an NIS+ object must be authenticated (present a valid DES credential) before being granted owner access rights.

By default, an object's owner is the principal that created the object. However, an object's owner can cede ownership to another principal in two ways:

• One way is for the principal to specify a different owner at the time the object is created (see Specifying NIS+ Access Rights in Commands).

• A second way is for the principal to change the ownership of the object after it is created (see Changing Ownership of NIS+ Objects and Entries).

Once a principal gives up ownership, that principal gives up all owner's access rights to the object and keeps only the rights the object assigns to either the group, the world, or nobody.

NIS+ Group Class

The object's group is a single NIS+ group. (In this context, group refers to NIS+ groups, not UNIX or net groups.)

A principal making a request for access to an NIS+ object must be authenticated (present a valid DES credential) and belong to the group before being granted group access rights.

An NIS+ group is a collection of NIS+ principals, grouped together as a convenience for providing access to the namespace. The access rights granted to an NIS+ group apply to all the principals that are members of that group. (An object's owner, however, does not need to belong to the object's group.)

When an object is created it may be assigned a default group. A nondefault group can be specified for an object when it is created or after it is created. An object's group may be changed at any time.

Information about NIS+ groups is not stored in the NIS+ group table. The group table stores information about UNIX groups. Information about NIS+ groups is stored in the appropriate groups_dir directory object.

Information about NIS+ groups is stored in NIS+ group objects, under the groups_dir subdirectory of every NIS+ domain.

Figure 11–5 NIS+ Directory Structure

Instructions for administering NIS+ groups are provided in Chapter 17, Administering NIS+ Groups.

NIS+ World Class

The world class contains all NIS+ principals that are authenticated by NIS+. In other words, the world class includes everyone in the owner and group class, plus everyone else who presents a valid DES credential.

Access rights granted to the world class apply to all authenticated principals.

NIS+ Nobody Class

The nobody class is composed of anyone who is not properly authenticated. In other words, the nobody class includes everyone who does not present a valid DES credential.

Authorization Classes and the NIS+ Object Hierarchy

There is a hierarchy of NIS+ objects and authorization classes that can apply independently to each level.

The standard default NIS+ directory hierarchy is:

• Directory level. In each NIS+ domain there are two NIS+ directory objects: groups_dir and org_dir. Each groups_dir directory object contains various groups. Each org_dir directory object contains various tables.

• Group level or table level. Groups contain individual entries and possibly other groups. Tables contain both columns and individual entries.

• Column level. A given table will have one or more columns.

• Entry (row) level. A given group or table will have one or more entries.

The four authorization classes apply at each level. Thus, a directory object will have its own owner and group. The individual tables within a directory object will have their own individual owners and groups which may be different than the owner and group of the directory object. Within a table, an entry (row) may have its own individual owner or group which may be different than the owner and group of the table as a whole or the directory object as a whole. Within a table, individual columns have the same owner and group as the table as a whole.

NIS+ Access Rights

NIS+ objects specify their access rights as part of their object definitions. (You can examine these by using the niscat -o command.)

NIS+ objects specify access rights for NIS+ principals in the same way that UNIX files specify permissions for UNIX users. Access rights specify the types of operations that NIS+ principals are allowed to perform on NIS+ objects.

NIS+ operations vary among different types of objects, but they all fall into one of the four access rights categories: read, modify, create, and destroy.

• Read A principal with read rights to an object can view the contents of that object.

• Modify. A principal with modify rights to an object can change the contents of that object.

• Destroy. A principal with destroy rights to an object can destroy or delete the object.

• Create. A principal with create rights to a higher level object can create new objects within that level. In other words, if you have create rights to an NIS+ directory object, you can create new tables within that directory. If you have create rights to an NIS+ table, you can create new columns and entries within that table.

Every communication from an NIS+ client to an NIS+ server is, in effect, a request to perform one of these operations on a specific NIS+ object. For instance, when an NIS+ principal requests the IP address of another machine, it is requesting read access to the hosts table object, which stores that type of information. When a principal asks the server to add a directory to the NIS+ namespace, it is actually requesting modify access to the directory's parent object.

Keep in mind that these rights logically evolve down from directory to table to table column and entry levels. For example, to create a new table, you must have create rights for the NIS+ directory object where the table will be stored. When you create that table, you become its default owner. As owner, you can assign yourself create rights to the table which allows you to create new entries in the table. If you create new entries in a table, you become the default owner of those entries. As table owner, you can also grant table-level create rights to others. For example, you can give your table's group class table-level create rights. In that case, any member of the table's group can create new entries in the table. The individual member of the group who creates a new table entry becomes the default owner of that entry.

NIS+ Administrator

An NIS+ administrator is anyone who has administrative rights over an NIS+ object. For the purpose of this discussion, administrative rights are defined as create, destroy, and for some objects, modify rights. (See NIS+ Access Rights for a description of NIS+ access rights.)

Whoever creates an NIS+ object sets the initial access rights to that object. If the creator restricts administrative rights to the object's owner (initially the creator), than only the owner has administrative power over that object. On the other hand, if the creator grants administrative rights to the object's group, then everyone in that group has administrative power over that object.

Thus, who ever has administrative rights over an object is considered to be an NIS+ administrator for that object.

In other words, the NIS+ software does not enforce any requirement that there be a single NIS+ administrator.

Theoretically, you could grant administrative rights to the world class, or even the nobody class. The software allows you to do that. But granting administrative rights beyond the group class nullifies NIS+ security. Thus, if you grant administrative rights to either the World or the nobody class you are, in effect, defeating the purpose of NIS+ security.

NIS+ Password, Credential, and Key Commands

The NIS+ service is managed by the Service Management Facility. 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 the Facility with NIS+. For an overview of the Facility, 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.

Use the following commands to administer passwords, credentials, and keys (see the appropriate man pages for a full description of each command):

• chkey. Changes a principal's Secure RPC key pair. Do not use chkey unless necessary, use passwd instead. See Changing Keys for an NIS+ Principal for more information.

• keylogin. Decrypts and stores a principal's secret key with the keyserv.

• keylogout. Deletes stored secret key from keyserv.

• keyserv. Enables the server for storing private encryption keys. See Keylogin With NIS+ for more information about keys. See NIS+ and the Service Management Facility for information about managing NIS+ by using the Service Management Facility.

• newkey. Creates a new key pair in public-key database.

• nisaddcred. Creates credentials for NIS+ principals. See Creating NIS+ Credential Information and Administering NIS+ Credential Information for more information.

• nisauthconf. Display or set the Diffie-Hellman key length.

• nisupdkeys. Updates public keys in directory objects. See Updating Public Keys for NIS+ for more information.

• passwd. Changes and administers principal's password. See Chapter 16, Administering NIS+ Passwords for more information.

Chapter 12 Administering NIS+ Credentials

This chapter describes NIS+ credentials and how to administer them.

Some NIS+ security tasks can be performed more easily with Solaris Management Console tools if you have them available.

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.

NIS+ Credentials

NIS+ credentials are used to identify NIS+ users. This chapter assumes that you have an adequate understanding of the NIS+ security system in general, and in particular of the role that credentials play in that system.

For a complete description of NIS+ credential-related commands and their syntax and options, see the NIS+ man pages.

The description of DES credentials in this chapter is applicable to 192-bit Diffie-Hellman DES credentials. While similar, authentication using other key lengths differs in details. When the command line interface is used to manipulate the keys, the differences are transparent to both the user and the system administrator. Use nisauthconf to display or set the prescribed key lengths.

How NIS+ Credentials Work

Some NIS+ security tasks can be performed more easily with Solaris Management Console tools, if you have them available.

The credential/authentication system prevents someone from assuming some other user's identity. That is, it prevents someone with root privileges on one machine from using the su command to assume the identity of a second user who is either not logged in at all or logged in on another machine and then accessing NIS+ objects with the second user's NIS+ access privileges.

NIS+ cannot prevent someone who knows another user's login password from assuming that other user's identity and the other user's NIS+ access privileges. Nor can NIS+ prevent a user with root privileges from assuming the identity of another user who is currently logged in on the same machine.

NIS+ Credentials and Credential Information

To understand how DES credentials are created and how they work, you need to distinguish between the credential itself and the information that is used to create and verify it.

• Credential information: The data that is used to generate a DES credential and by the server to verify that credential.

• DES credential: The bundle of numbers that is sent by the principal to the server to authenticate the principal. A principal's credential is generated and verified each time the principal makes an NIS+ request. See DES Credential in NIS+ for a detailed description of the DES credential.

NIS+ Authentication Components

In order for the credential/authentication process to work the following components must be in place:

• Principal's DES credential information. This information is initially created by an NIS+ administrator for each principal. It is stored in the cred table of the principal's home domain. A principal's DES credential information consists of:

  • Principal name. This would be a user's fully qualified login ID or a machine's fully qualified host name.

  • Principal's Secure RPC netname. Each principal has a unique Secure RPC netname. (See DES Credential Secure RPC Netname for more information on Secure RPC netnames.)

  • Principal's public key.

  • Principal's encrypted private key.

• Principal's LOCAL credential

• Server's public keys. Each directory object stores copies of the public keys of all the servers in that domain. Note that each server's DES credentials are also stored in the cred table.

• Keyserver copy of principal's private key. The keyserver has a copy of the private key of the principal that is currently logged in (user or machine).

How NIS+ Principals Are Authenticated

There are three phases to the authorization process:

• Preparation phase. This consists of the setup work performed by an NIS+ administrator prior to the user logging in; for example, creating credential information for the user.

• Login phase. This consists of the actions taken by the system when a user logs in.

• Request phase. This consists of the actions taken by the software when an NIS+ principal makes a request for an NIS+ service or access to an NIS+ object.

These three phases are described in detail in the following subsections.

NIS+ Credentials Preparation Phase

The easiest way for an NIS+ administrator to create credential information for users is to use the nisclient script. This section describes how to create client information using the NIS+ command set.

Prior to an NIS+ principal logging in, an NIS+ administrator must create DES credential information for that principal (user or machine).

The administrator must:

• Create a public key and an encrypted private key for each principal. These keys are stored in the principal's home domain cred table. This can be done with the nisaddcred command as described in Creating Credential Information for NIS+ Principals.

• Create server public keys. (See Updating Public Keys for NIS+.)

NIS+ Login Phase – Detailed Description

When a principal logs into the system the following steps are automatically performed:

1. The keylogin program is run for the principal. The keylogin program gets the principal's encrypted private key from the cred table and decrypts it using the principal's login password.

   ---

   Note –

   When a principal's login password is different from his or her Secure RPC password, keylogin cannot decrypt it and the user starts getting “cannot decrypt” errors or the command fails without a message. For a discussion of this problem, see Secure RPC Passwords and the Login Password Problem in NIS+.

   ---

2. The principal's decrypted private key is passed to the keyserver which stores it for use during the request phase.

   ---

   Note –

   The decrypted private key remains stored for use by the keyserver until the user does an explicit keylogout. If the user simply logs out (or goes home for the day without logging out), the decrypted private key remains stored in the server. If someone with root privileges on a user's machine switched to the user's login ID, that person would then have use of the user's decrypted private key and could access NIS+ objects using the user's access authorization. Thus, for added security, users should be cautioned to perform an explicit keylogout when they cease work. If they also log out of the system, all they need do is log back in when they return. If they do not explicitly log out, they will have to perform an explicit keylogin when they return to work.

   ---

NIS+ Request Phase – Detailed Description

Every time an NIS+ principal requests access to an NIS+ object, the NIS+ software performs a multistage process to authenticate that principal:

1. NIS+ checks the cred table of the object's domain.

   • If the principal has LOCAL credential information, NIS+ uses the domain information contained in the LOCAL credential to find the principal's home domain cred table where it obtains the information it needs.

   • If the principal has no credential information, the rest of the process is aborted and the principal is given the authorization access class of nobody.

2. NIS+ gets the user's DES credential from the cred table of the user's home domain. The encrypted private key is decrypted with the user's password and saved by the keyserver.

3. NIS+ obtains the server's public key from the NIS+ directory object.

4. The keyserver takes the principal's decrypted private key and the public key of the object's server (the server where the object is stored) and uses them to create a common key.

5. The common key is then used to generate an encrypted DES key. To do this, Secure RPC generates a random number which is then encrypted using the common key. For this reason, the DES key is sometimes referred to as the random key or the random DES key.

6. NIS+ then takes the current time of the principal's server and creates a time stamp that is encrypted using the DES key.

7. NIS+ then creates a 15-second window, which is encrypted with the DES key. This window is the maximum amount of time that is permitted between the time stamp and the server's internal clock.

8. NIS+ then forms the principal's DES credential, which is composed of the following items.

   • The principal's Secure RPC netname (unix.identifier@domain) from the principal's cred table

   • The principal's encrypted DES key from the keyserver

   • The encrypted time stamp

   • The encrypted window

9. NIS+ then passes the following information to the server where the NIS+ object is stored.

   • The access request (whatever it might be)

   • The principal's DES credential

   • Window verifier (encrypted), which is the encrypted window plus one

10. The object's server receives this information.

11. The object's server uses the Secure RPC netname portion of the credential to look up the principal's public key in the cred table of the principal's home domain.

12. The server then uses the principal's public key and the server's private key to regenerate the common key. This common key must match the common key that was generated by the principal's private key and the server's public key.

13. The common key is used to decrypt the DES key that arrived as part of the principal's credential.

14. The server decrypts the principal's time stamp with the newly decrypted DES key and verifies it with the window verifier.

15. The server then compares the decrypted and verified time stamp with the server's current time and proceeds as follows.

    1. If the time difference at the server exceeds the window limit, the request is denied and the process aborts with an error message. For example, suppose the time stamp is 9:00am and the window is one minute. If the request is received and decrypted by the server after 9:01am, it is denied.

    2. If the time stamp is within the window limit, the server checks to see if the time stamp is greater than the one previously received from the principal. This ensures that NIS+ requests are handled in the correct order.

       • Requests received out of order are rejected with an error message. For example, if the time stamp is 9:00am and the most recently received request from this principal had a time stamp of 9:02am, the request would be rejected.

       • Requests that have a time stamp equal to the previous one are rejected with an error message. This ensures that a replayed request is not acted on twice. For example, if the time stamp is 9:00am and the most recently received request from this principal also had a time stamp of 9:00am, this request would be rejected.

16. If the time stamp is within the window limit, and greater than the previous request from that principal, the server accepts the request.

17. The server then complies with the request and stores the time stamp from this principal as the most recently received and acted on request.

18. To confirm to the principal that the information received from the server in answer to the request comes from a trusted server, the server encrypts the time stamp with the principal's DES key and sends it back to the principal along with the data.

19. At the principal's end, the returned time stamp is decrypted with the principal's DES key.

    • If the decryption succeeds, the information from the server is returned to the requester.

    • If the decryption fails for some reason, an error message is displayed.

DES Credential in NIS+

The DES credential consists of:

• The principal's Secure RPC netname (see DES Credential Secure RPC Netname).

• A verification field (see DES Credential Verification Field in NIS+).

DES Credential Secure RPC Netname

Secure RPC netname. This portion of the credential is used to identify the NIS+ principal. Every Secure RPC netname contains the following three components.

• Prefix. The prefix is always the word unix.

• Identifier. If the principal is a client user, the ID field is the user's UID. If the principal is a client machine, the ID field is the machine's hostname.

• Domain name. The domain name is the name of the domain that contains the principal's DES credential (in other words, the principal's home domain).

Remember that an NIS+ principal name always has a trailing dot, and a Secure RPC netname never has a trailing dot.

DES Credential Verification Field in NIS+

The verification field is used to make sure the credential is not forged. It is generated from the credential information stored in the cred table.

The verification field is composed of:

• The principal's encrypted DES key, generated from the principal's private key and the NIS+ server's public key as described in NIS+ Request Phase – Detailed Description

• The encrypted time stamp

• The time window

How the DES Credential in NIS+ Is Generated

To generate its DES credential, the principal depends on the keylogin command, which must have been executed before the principal tries to generate its credential. The keylogin command (often referred to simply as a keylogin) is executed automatically when an NIS+ principal logs in. See Figure 12–2.

Note that if the principal's login password is different from the principal's Secure RPC password, a successful keylogin cannot be performed. See Secure RPC Passwords and the Login Password Problem in NIS+ for a discussion of this situation.

The purpose of the keylogin is to give the principal access to the principal's private key. keylogin fetches the principal's private key from the cred table, decrypts it with the principal's Secure RPC password (remember that the private key was originally encrypted with the principal's Secure RPC password), and stores it locally with the keyserver for future NIS+ requests.

Figure 12–1 keylogin Generates an NIS+ Principal's Private Key

To generate its DES credential, the principal still needs the public key of the server to which it will send the request. This information is stored in the principal's directory object. Once the principal has this information, it can form the verification field of the credential.

First, the principal generates a random DES key for encrypting various credential information. The principal uses its own private key (stored in the keyserver) and the server's public key to generate a common key that is used to generate and encrypt the random DES key. It then generates a time stamp that is encrypted with the DES key and combines it with other credential-related information into the verification field.

Figure 12–2 Creating the DES Credential in NIS+

Secure RPC Passwords and the Login Password Problem in NIS+

When a principal's login password is different from his or her Secure RPC password, keylogin cannot decrypt it at login time because keylogin defaults to using the principal's login password, and the private key was encrypted using the principal's Secure RPC password.

When this occurs, the principal can log in to the system, but for NIS+ purposes the principal is placed in the authorization class of nobody because the keyserver does not have a decrypted private key for that user. Since most NIS+ environments are set up to deny the nobody class create, destroy, and modify rights to most NIS+ objects, this results in “permission denied” errors when the user tries to access NIS+ objects.

In this context, network password is sometimes used as a synonym for Secure RPC password. When prompted for your “network password,” enter your Secure RPC password.

To be placed in one of the other authorization classes, a user in this situation must explicitly run the keylogin program and give the principal's Secure RPC password when keylogin prompts for a password. (See Keylogin With NIS+.)

But an explicit keylogin provides only a temporary solution that is good only for the current login session. The keyserver now has a decrypted private key for the user, but the private key in the user's cred table is still encrypted using the user's Secure RPC password, which is different than the user's login password. The next time the user logs in, the same problem recurs. To permanently solve the problem the user needs to re-encrypt the private key in the cred table to one based on the user's login ID rather than the user's Secure RPC password. To do this, the user needs to run chkey -p as described in Changing Keys for an NIS+ Principal.

Thus, to permanently solve problems related to a difference in Secure RPC password and login password, the user (or an administrator acting for the user) must perform these steps:

1. Log in using the login password.

2. Run the keylogin program to temporarily get a decrypted private key stored in the keyserver and thus gain temporary NIS+ access privileges.

3. Run chkey -p to permanently change the encrypted private key in the cred table to one based on the user's login password.

4. When you are ready to finish this login session, run keylogout.

5. Log off the system with logout.

Cached Public Keys Problems in NIS+

Occasionally, you might find that even though you have created the proper credentials and assigned the proper access rights, some principal requests still get denied. The most common cause of this problem is the existence of stale objects with old versions of a server's public key.

You can usually correct this problem by:

• Running nisupdkeys on the domain you are trying to access. (See nisupdkeys Command for information on using the nisupdkeys command and Stale and Outdated NIS+ Credential Information for information on how to correct this type of problem.)

• Stopping the NIS+ service on your machine by using the svcadm command, removing /var/nis/NIS_SHARED_DIRCACHE, and then restarting the NIS+ service.

Where Credential-Related Information Is Stored in NIS+

This section describes where credential-related information is stored throughout the NIS+ namespace.

Credential-related information, such as public keys, is stored in many locations throughout the namespace. NIS+ updates this information periodically, depending on the time-to-live values of the objects that store it, but sometimes, between updates, it gets out of sync. As a result, you may find that operations that should work, do not. lists all the objects, tables, and files that store credential-related information and how to reset it.

The NIS+ service is managed by the Service Management Facility (SMF). Enabling, disabling, or restarting NIS+ daemons such as rpc.nisd, keyserv, and nis_cachemgr, 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.

NIS+ cred Table in Detail

Credential information for principals is stored in a cred table. The cred table is one of the 16 standard NIS+ tables. Each domain has one cred table, which stores the credential information of client machines that belong to that domain and client users who are allowed to log into them. (In other words, the principals of that domain.) The cred tables are located in their domains' org_dir subdirectory.

Never link a cred table. Each org_dir directory must have its own cred table. Never use a link to some other org_dir cred table.

For users, the cred table stores LOCAL credential information for all users who are allowed to log into any of the machines in the domain. The cred table also stores DES credential information for those users that have the domain as their home domain.

You can view the contents of a cred table with the niscat command, described in Chapter 19, Administering NIS+ Tables.

The cred table, as shown in Table 12–3, has five columns.

The Authentication Type column, determines the types of values found in the other four columns.

• LOCAL. If the authentication type is LOCAL, the other columns contain a principal user's name, UID, and GID; the last column is empty.

• DES. If the authentication type is DES, the other columns contain a principal's name, Secure RPC netname, public key, and encrypted private key. These keys are used in conjunction with other information to encrypt and decrypt a DES credential.

Creating NIS+ Credential Information

There are several methods of creating and administering credential information:

• Use Solaris Management Console tools if you have them available. They provide easier methods of credential administration and are recommended for administering individual credentials.

• Use the nisclient script. This is another easy method of creating or altering credentials for a single principal. Because of its convenience, this is a recommended method of administering individual credentials. gives step by step instructions on using the nisclient script to create credential information.

• Use the nispopulate script. This is an easy method of creating or altering credentials for a one or more principals who already have information on them stored in NIS maps or /etc files. Because of its convenience, this is a recommended method of administering credentials for groups of NIS+ principals. For step by step instructions on using the nispopulate script to create credential information, see.Populating NIS+ Tables.

• Use the nisaddcred command. The section below describes how credentials and credential information are created using nisaddcred.

nisaddcred Command

The command used to create credential information is nisaddcred.

You can also use the nispopulate and nisclient scripts to create credential information. They, in turn, use the nisaddcred command. These scripts are much easier to use, and more efficient, than the nisaddcred command. Unless your network requires special features, you should use the scripts.

The nisaddcred command creates, updates, and removes LOCAL and DES credential information. To create credential information, you must have create rights to the proper domain's cred table. To update a credential, you must have modify rights to the cred table or, at least, to that particular entry in the cred table. To delete a credential, you must have destroy rights to the cred table or the entry in the cred table.

• To create or update credentials for another NIS+ principal, use:

  For LOCAL credentials

  nisaddcred -p uid -P principal-name local

  For DES credentials

  nisaddcred -p rpc-netname -P principal-name des

• To update your own credentials, use:

  For LOCAL credentials

  nisaddcred -local

  For DES credentials, use:

  nisaddcred des

• To remove credentials, use:

  nisaddcred -r principal-name

NIS+ Credential-Related Commands

In addition to the nisaddcred command described in this chapter, two other commands can provide some useful information about credentials. The niscat and nismatch commands are described in the following table.

How nisaddcred Creates NIS+ Credential Information

Use nisaddcred to create LOCAL and DES credential information.

LOCAL NIS+ Credential Information

When used to create LOCAL credential information, nisaddcred simply extracts the principal user's UID (and GID) from the principal's login record and places it in the domain's cred table.

DES Credential Information in NIS+

When used to create DES credential information, nisaddcred goes through a two-part process:

1. Forming the principal's Secure RPC netname. A Secure RPC netname is formed by taking the principal's user ID number from the password record and combining it with the domain name (unix.1050@doc.com, for example).

2. Generating the principal's private and public keys.

To encrypt the private key, nisaddcred needs the principal's Secure RPC password. When the nisaddcred command is invoked with the -des argument, it prompts the principal for a Secure RPC password. Normally, this password is the same as the principal's login password. (If it is different, the user will have to perform additional steps when logging in, as described in Secure RPC Passwords and the Login Password Problem in NIS+.)

The nisaddcred command generates a pair of random, but mathematically related 192-bit authentication keys using the Diffie-Hellman cryptography scheme. These keys are called the Diffie-Hellman key-pair, or simply key-pair for short.

One of these is the private key, and the other is the public key. The public key is placed in the public data field of the cred table. The private key is placed in the private data field, but only after being encrypted with the principal's Secure RPC password.

Figure 12–3 How nisaddcred Creates an NIS+ Principal's Keys

The principal's private key is encrypted as a security precaution because the cred table, by default, is readable by all NIS+ principals, even unauthenticated ones.

Secure RPC Netname and NIS+ Principal Name

When creating credential information, you will often have to enter a principal's rpc-netname and principal-name.

Each has its own syntax:

• Secure RPC netname. A Secure RPC netname is a name whose syntax is determined by the Secure RPC protocol. Therefore, it does not follow NIS+ naming conventions:

  • For users, the syntax is: unix.uid@domain

  • For machines, the syntax is: unix.hostname@domain

  If a Secure RPC netname identifies a user, it requires the user's UID. If it identifies a machine, it requires the machine's host name. (When used with the nisaddcred command it is always preceded by the -p (lowercase) flag.)

  A Secure RPC netname always begins with the unix (all lowercase) prefix and ends with a domain name. However, because it follows the Secure RPC protocol, the domain name does not contain a trailing dot.

• Principal name. An NIS+ principal follows the normal NIS+ naming conventions, but it must always be fully qualified. the syntax is: principal.domain.

Whether it identifies a client user or a client machine, it begins with the principal's name, followed by a dot and the complete domain name, ending in a dot. (When used with nisaddcred to create credential information, it is always preceded by the -P (uppercase) flag. When used to remove credential information, it does not use the -P flag.)

Creating NIS+ Credential Information for the Administrator

When a namespace is first set up, credential information is created first for the administrators who will support the domain. Once they have credential information, they can create credential information for other administrators, client machines, and client users.

When you try to create your own credential information, you run into a problem of circularity: you cannot create your own credential information unless you have Create rights to your domain's cred table, but if the NIS+ environment is properly set up, you cannot have such rights until you have credentials. You have to step out of the loop somehow.

You can do this in one of two ways:

• By creating your credential information while logged in as superuser to your domain's master server.

• By having another administrator create your credential information using a dummy password, then changing your password with the chkey command.

In either case, your credential information is thus created by another NIS+ principal. To create your own credential information, follow the instructions in Creating Credential Information for NIS+ Principals.

Creating Credential Information for NIS+ Principals

Credential information for NIS+ principals can be created any time after their domain has been set up; in other words, once a cred table exists.

To create credential information for an NIS+ principal:

• You must have Create rights to the cred table of the principal's home domain.

• The principal must be recognized by the server. This means that:

  • If the principal is a user, the principal must have an entry either in the domain's NIS+ passwd table or in the server's /etc/passwd file.

  • If the principal is a machine, it must have an entry either in the domain's NIS+ Hosts table or in the server's.

Once those conditions are met, you can use the nisaddcred command with both the -p and -P options:

For LOCAL credentials

nisaddcred -p uid -P principal-name local

For DES credentials

nisaddcred -p rpc.netname -P principal-name des

Remember these principles:

• You can create both LOCAL and DES credential information for a principal user.

• You can only create DES credential information for a principal machine.

• You can create DES credential information only in the principal's home domain (user or machine).

• You can create LOCAL credential information for a user in both the user's home domain and in other domains.

For NIS+ User Principals – Example

This example creates both LOCAL and DES credential information for an NIS+ user named morena who has a UID of 11177. She belongs to the doc.com. domain, so this example enters her credential information from a principal machine of that domain:

client# nisaddcred -p 11177 -P morena.doc.com. local 
client# nisaddcred -p unix.11177@sales.doc.com \
   -P morena.doc.com. des
Adding key pair for unix.11177@sales.doc.com 
   (morena.doc.com.).
Enter login password:

The proper response to the Enter login password: prompt is morena's login password. (If you don't know her login password, you can use a dummy password that she can later change using chkey, as described in the next example.)

Using a Dummy Password and chkey in NIS+ – Example

If you don't know the user's login password, you can use a dummy password as described below.

Table 12–5, shows how another administrator, whose credential information you create using a dummy password, can then use chkey to change his or her own password. In this example, you create credential information for an administrator named Eiji who has a UID of 119. Eiji, whose login ID is eiji, belongs to the root domain, so you would enter his credential information from the root master server which is named rootmaster.

Retype password:
Done.

First, you would create Eiji's credential information in the usual way, but using a dummy login password. NIS+ would warn you and ask you to re-type it. When you did, the operation would be complete. The domain's cred table would contain Eiji's credential information based on the dummy password. The domain's passwd table (or /etc/passwd file), however, would still have his login password entry so that he can log in to the system.

Then, Eiji would log in to the domain's master server, typing his correct login password (since the login procedure checks the password entry in the passwd table or /etc/passwd file). From there, Eiji would first run keylogin, using the dummy password (since a keylogin checks the cred table), and then use the chkey -p command to change the cred entry to the real thing.

Creating Credential Information in Another NIS+ Domain – Example

The two previous examples created credential information for a principal user while the principal user was logged in to the master server of the principal's home domain. However, if you have the proper access rights, you can create credential information in another domain. Simply append the domain name to this syntax:

For LOCAL credentials

nisaddcred -p uid -P principal-name local domain-name

For DES credentials

nisaddcred -p rpc-netname -P principal-name des domain-name 

The following example first creates LOCAL and DES credential information for an administrator named Chou in her home domain, which happens to be the root domain, then adds her LOCAL credential information to the doc.com domain. Chou's UID is 11155. This command is typed on from the root master server. For simplicity, it assumes you are entering Chou's correct login password.

rmaster# nisaddcred -p 11155 -P chou.doc.com. local
rmaster# nisaddcred -p unix.11155@doc.com -P chou.doc.com. des
Adding key pair for unix.11155@doc.com (chou.doc.com.).
Enter login password: 
rootmaster# nisaddcred -p 11155 -P chou.doc.com. local doc.com.

LOCAL credential information maps a UID to an NIS+ principal name. Although an NIS+ principal that is a client user can have different user IDs in different domains, it can have only one NIS+ principal name. So, if an NIS+ principal such as chou will be logging in from a domain other than her home domain, not only should she have a password entry in that domain, but also a LOCAL credential in that domain's cred table.

For NIS+ Machines – Example

This example creates credential information for a principal machine. Its host name is starshine1 and it belongs to the root domain. Therefore, its credential information is created from the root master server. In this example, you create them while logged in as root to the root master; however, if you already have valid credential information and the proper access rights, you could create them while logged in as yourself.

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

The proper response to the password prompt is the principal machine's superuser password. Of course, you could use a dummy password that would later be changed by someone logged in as superuser to that principal machine.

Administering NIS+ Credential Information

The following sections describe how to use the nisaddcred command to administer existing credential information. You must have create, modify, read, and destroy rights to the cred table to perform these operations.

Updating Your Own NIS+ Credential Information

Updating your own credential information is considerably easier than creating it. Just type the simple versions of the nisaddcred command while logged in as yourself:

# nisaddcred des
# nisaddcred local

To update credential information for someone else, you simply perform the same procedure that you would use to create that person's credential information.

Removing NIS+ Credential Information

The nisaddcred command removes a principal's credential information, but only from the local domain where the command is run.

Thus, to completely remove a principal from the entire system, you must explicitly remove that principal's credential information from the principal's home domain and all domains where the principal has LOCAL credential information.

To remove credential information, you must have modify rights to the local domain's cred table. Use the -r option and specify the principal with a full NIS+ principal name:

# nisaddcred -r principal-name

The following two examples remove the LOCAL and DES credential information of the administrator Morena.doc.com. The first example removes both types of credential information from her home domain (doc.com.), the second removes her LOCAL credential information from the sales.doc.com. domain. Note how they are each entered from the appropriate domain's master servers.

rootmaster# nisaddcred -r morena.doc.com.
salesmaster# nisaddcred -r morena.doc.com.

To verify that the credential information was indeed removed, run nismatch on the cred table, as shown below. For more information about nismatch, see Chapter 19, Administering NIS+ Tables.

rootmaster# nismatch morena.doc.com. cred.org_dir
salesmaster# nismatch morena.doc.com. cred.org_dir

Chapter 13 Administering NIS+ Keys

This chapter describes NIS+ keys and how to administer them.

Some NIS+ security tasks can be performed more easily with Solaris Management Console tools if you have them available.

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.

NIS+ Keys

NIS+ keys are used to encrypt NIS+ related information.

This chapter assumes that you have an adequate understanding of the NIS+ security system in general, and in particular of the role that keys play in that system. See Chapter 11, NIS+ Security Overview for more information.

For a complete description of NIS+ key-related commands and their syntax and options, see the NIS+ man pages. (The nisaddcred command also performs some key-related operations. See Chapter 12, Administering NIS+ Credentials for more information.)

The NIS+ service is managed by the Service Management Facility (SMF). Administrative actions on the NIS+ services, 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.

Keylogin With NIS+

When a principal logs in, the login process prompts for a password. That password is used to pass the user through the login security gate and give the user access to the network. The login process also decrypts the user's private key stored in the user's home domain cred table and passes that private key to the keyserver. The keyserver then uses that decrypted private key to authenticate the user each time the user accesses an NIS+ object.

Normally, this is the only time the principal is asked to provide a password. However, if the principal's private key in the cred table was encrypted with a password that was different from the user's login password, login cannot decrypt it using the login password at login time, and thus cannot provide a decrypted private key to the keyserver. (This most often occurs when a user's private key in the cred table was encrypted with a Secure RPC password different from the user's login password.)

In this context, network password is sometimes used as a synonym for Secure RPC password.

To temporarily remedy this problem, the principal must perform a keylogin, using the keylogin command, after every login. (The -r flag is used to keylogin the superuser principal and to store the superuser's key in /etc/.rootkey on a host.)

For a principal user

keylogin

For a principal machine (only once)

keylogin -r

Note, however, that performing an explicit keylogin with the original password provides only a temporary solution good for the current login session only. The private key in the cred table is still encrypted with a password different than the user's login password so the next time the user logs in the problem will reoccur. To permanently solve this problem, the user must run chkey to change the password used to encrypt the private key to the user's login password (see Changing Keys for an NIS+ Principal).

Changing Keys for an NIS+ Principal

The chkey command changes an NIS+ principal's public and private keys that are stored in the cred table. It does not affect the principal's entry either in the passwd table or in the /etc/passwd file.

The chkey command:

• Generates new keys and encrypts the private key with the password. Run chkey with the -p option to re-encrypt the existing private key with a new password.

• Generates a new Diffie-Hellman key pair and encrypts the private key with the password you provide. (Multiple Diffie-Hellman key pairs can exist for each principal.) In most cases, however, you do not want a new keypair, you want to re-encrypt your current existing private key with the new password. To do this, run chkey with the -p option.

See the man pages for more information on these subjects.

In an NIS+ environment, when you change your login password with any of the current administration tools or the passwd (or nispasswd) commands, your private key in the cred table is automatically re-encrypted with the new password for you. Thus, you do not need to explicitly run chkey after a change of login password.

The chkey command interacts with the keyserver, the cred table, and the passwd table.

In order to run chkey, you:

• Must have an entry in the passwd table of your home domain. Failure to meet this requirement will result in an error message.

• Must run keylogin to make sure that the keyserver has a decrypted private key for you.

• Must have modify rights to the cred table. If you do not have modify rights you will get a “permission denied” type of error message.

• Must know the original password with which the private key in the cred table was encrypted. (In most cases, this your Secure RPC password.)

To use the chkey command to re-encrypt your private key with your login password, you first run keylogin using the original password, and then use chkey -p, as shown in Table 13–1, which illustrates how to perform a keylogin and chkey for a principal user.

Sirius% chkey -p
Updating nisplus publickey database
Updating new key for 'unix.1199@Doc.com'.

Changing the NIS+ Keys

The following sections describe how to change the keys of an NIS+ principal.

Whenever you change a server's keys, you must also update the key information of all the clients in that domain as explained in Updating NIS+ Client Key Information.

Changing NIS+ Root Keys From Root

Table 13–2, shows how to change the keys for the root master server from the root master (as root).

rootmaster# nisaddcred des

Where:

dirs are the directory objects you wish to update. (That is, the directory objects that are served by rootmaster.)

In the first step of the process outlined in Table 13–2, nisaddcred updates the cred table for the root master, updates /etc/.rootkey and performs a keylogin for the root master. At this point the directory objects served by the master have not been updated and their credential information is now out of synch with the root master. The subsequent steps described in Table 13–2 are necessary to successfully update all the objects.

Whenever you change a server's keys, you must also update the key information of all the clients in that domain as explained in Updating NIS+ Client Key Information.

Changing Root Keys From Another NIS+ Machine

To change the keys for the root master server from some other machine you must have the required NIS+ credentials and authorization to do so.

Where:

• principal is the root machine's Secure RPC netname. For example:unix.rootmaster@doc.com (no dot at the end).

• nis-principal is the root machine's NIS+ principal name. For example, rootmaster.doc.com. (a dot at the end).

• dirs are the directory objects you want to update (that is, the directory objects that are served by rootmaster).

When running nisupdkeys be sure to update all relevant directory objects at the same time. In other words, do them all with one command. Separate updates may result in an authentication error.

Whenever you change a server's keys, you must also update the key information of all the clients in that domain as explained in Updating NIS+ Client Key Information.

Changing the Keys of an NIS+ Root Replica From the Replica

To change the keys of a root replica from the replica, use these commands:

replica# nisaddcred des
replica# nisupdkeys dirs

Where:

dirs are the directory objects you wish to update, (that is, the directory objects that are served by replica).

When running nisupdkeys be sure to update all relevant directory objects at the same time. In other words, do them all with one command. Separate updates may result in an authentication error.

Whenever you change a server's keys, you must also update the key information of all the clients in that domain as explained in Updating NIS+ Client Key Information.

Changing the Keys of an NIS+ Non-Root Server

To change the keys of a non-root server (master or replica) from the server, use these commands:

subreplica# nisaddcred des
subreplica# nisupdkeys parentdir dirs

Where:

• parentdir is the non-root server's parent directory (that is, the directory containing subreplica's NIS+ server).

• dirs are the directory objects you want to update (that is, the directory objects that are served by subreplica).

When running nisupdkeys be sure to update all relevant directory objects at the same time. In other words, do them all with one command. Separate updates may result in an authentication error.

Whenever you change a server's keys, you must also update the key information of all the clients in that domain, as explained in Updating NIS+ Client Key Information.

Updating Public Keys for NIS+

The public keys of NIS+ servers are stored in several locations throughout the namespace. When new credential information is created for the server, a new key pair is generated and stored in the cred table. However, namespace directory objects still have copies of the server's old public key. The nisupdkeys command is used to update those directory object copies.

nisupdkeys Command

If a new keypair is generated because the old key pair has been compromised or the password used to encrypt the private key is forgotten, the nisupdkeys can be used to update the old public key in the directory objects.

The nisupdkeys command can:

• Update the key of one particular server

• Update the keys of all the servers that support an NIS+ directory object

• Remove a server's public key from the directory object

• Update a server's IP address, if that has changed

However, nisupdkeys cannot update the NIS_COLD_START files on the principal machines. To update their copies of a server's keys, NIS+ clients should run the nisclient command. Or, if the NIS+ cache manager is running and more than one server is available in the cold-start file, the principals can wait until the time-to-live expires on the directory object. When that happens, the cache manager automatically updates the cold-start file. The default time-to-live is 12 hours.

To use the nisupdkeys command, you must have modify rights to the NIS+ directory object.

Updating Public Keys Arguments and Examples in NIS+

The nisupdkeys command is located in /usr/lib/nis. The nisupdkeys command uses the following arguments (for a complete description of the nisupdkeys command and a full list of all its arguments, see the nisupdkeys man page).

Table 13–5 gives an example of updating a public key.

Updating IP Addresses in NIS+

If you change a server's IP address, or add additional addresses, you need to run nisupdkeys to update NIS+ address information.

To update the IP addresses of one or more servers, use the nisupdkeys command -a option.

To update the IP addresses of servers of a given domain

rootmaster# nisupdkeys -a domain

To update the IP address of a particular server

rootmaster# nisupdkeys -a -H server

Updating NIS+ Client Key Information

Whenever you change any server's keys, you must update all of the clients as well. Remember, that all NIS+ servers are also NIS+ clients, so if you update the keys on one server, you must update key information on all other machines in the domain regardless of whether or not they are NIS+ servers or ordinary clients.

There are three ways to update client key information:

• The easiest way to update an individual client's key information is by running the nisclient script on the client.

• Another way to update an individual client's key information is by running the nisinit command on the client as described in Three Methods to Initialize an NIS+ Client.

• You can globally update client key information for all the machines in a domain by shortening the Time To Live value of the domain's directory object as explained in Globally Updating NIS+ Client Key Information.

Globally Updating NIS+ Client Key Information

After changing a server's keys, you can globally update client key information for all the machines in a domain by:

How to Update Client Key Information

1. Use the nischttl command to reduce the Time To Live (TTL) value of the domain's directory object so that the value expires almost immediately.

   For example, if you have changed the keys for a server in the sales.doc.com. domain, to reduce the directory's TTL value to one minute you would enter:

   client% nischttl 60 sales.doc.com.

2. When the directory's TTL value expires, the cache manager expires the entry and then obtains the new, updated information for clients.

3. Once the directory object's TTL value has expired, reset the directory object's TTL to its default value.

   For example, to reset the TTL value to 12 hours for the sales.doc.com. domain's directory object, you would enter:

   client% nischttl 12h sales.doc.com.

   See nischttl Command for more information on working with TTL values.

Chapter 14 Administering Enhanced NIS+ Security Credentials

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.

Diffie-Hellman Extended Key

NIS+ offers increased security at the RPC(3N) layer beyond 192 bit Diffie-Hellman (RPC(3N) security flavor AUTH_DH) using the RPCSEC_GSS RPC(3N) security flavor. See the nisauthconf command for a list of which security mechanisms are available on the system. Along with more stringent cryptographic strength, these security mechanisms also provide integrity for each NIS+ transaction. That is, the data for each NIS+ transaction is verified that it has not been modified.

System administraters can take advantage of the more stringent security mechanisms either by running nisauthconf before the NIS+ server environment is constructed or after, using the guidelines below.

AUTH_DH was formerly referred to as AUTH_DES.

Transitioning NIS+ to a New Public Key-Based Security Mechanism

The more stringent security mechanisms of the public key cryptography family such as Diffie-Hellman 640 bit (dh640-0) will require new credentials for each principal to be added to the existing cred table. The procedure outlined below is for a system currently running with Diffie-Hellman 192 bit (RPC security flavor AUTH_DH) security that will be converted to running with Diffie-Hellman 640 bit (RPC security flavor RPCSEC_GSS) security. Although this transition document highlights the most likely case, the principles are the same for converting from any one security mechanism type of the public key cryptography family to another security mechanism of the public key cryptography family.

The following example assumes that $PATH includes /usr/lib/nis.

Configuring NIS+ Security Mechanisms

NIS+ security configuration is done with the nisauthconf command. nisauthconf takes a list of security mechanisms in order of preference. A security mechanism may use one or more authentication flavors specified in secure_rpc(3N). If des is the only specified mechanism, then NIS+ only uses AUTH_DH (formerly AUTH_DES) for authentication with other NIS+ clients and servers. Any other security mechanisms after des will be ignored by NIS+, except for nisaddcred.

nisauthconf [-v] [mechanism, ...]

Where mechanism is a RPC security mechanism that is available on the system. See nisauthconf for the list of mechanisms available. If no mechanisms are specified, then a list of currently configured mechanisms is printed.

Creating New NIS+ Security Mechanism Credentials

Credential information for the new mechanism must be created for each NIS+ user and host principal. In order to do this, on one of the machines running NIS+, the nisauthconf command must be run to allow the creation of new credentials while the system continues to authenticate with the current mechanism. Also see Creating Credential Information for NIS+ Principals for details on credential creation basics.

New NIS+ Security Mechanism Credentials – Example

Converting des to dh640-0; the nisauthconf should be run as root and the nisaddcred should be run as any principal that has Create rights in the principal's home directory. The server is named server1 and the user principal is named morena. User morena has UID 11177.

client# nisauthconf des dh640-0
client% nisaddcred -P server1.doc.com. -p unix.server1@doc.com dh640-0
      (screen notices not shown) 
client% nisaddcred -P morena.doc.com. -p unix.11177@doc.com -ldummy-password dh640-0
      (screen notices not shown) 

Adding New Keys to NIS+ Directory Objects

Once the new credentials have been generated for all the servers, run nisupdkeys(1m) to add the new public keys to all the directory objects served by these servers. To use the nisupdkeys(1m) command, you must have modify rights to the NIS+ directory object. See Updating Public Keys for NIS+ for more details.

All servers that serve these NIS+ directories and all clients that access these directories must be running at least the Solaris 7 release.

Adding New Public Keys to NIS+ Directory Objects – Example

In this example, the directories that are being served by the servers with new public keys are doc.com, org_dir.doc.com., groups_dir.doc.com.. The update will be done as the master server principal. Before running the new mechanism, nisupdkeys needs to be configured with nisauthconf. In this example, the current authentication mechanism is des and the new mechanism is dh640-0.

masterserver#	nisauthconf dh640-0 des
masterserver#	nisupdkeys doc.com.
			(screen notices not shown)
masterserver#  nisupdkeys org_dir.doc.com.
			(screen notices not shown)
masterserver#	nisupdkeys groups_dir.doc.com.
			(screen notices not shown)

Configuring NIS+ Servers to Accept New Security Mechanism Credentials

On each server, configure NIS+ authentication so that it accepts both the old and new credentials. This will require running nisauthconf(1m) and keylogin and restarting keyserv(1m). The keylogin command stores the keys for each mechanism in the /etc/.rootkey. See Keylogin With NIS+ for basic keylogin details.

Configuring NIS+ Servers to Accept New Security Mechanism Credentials – Example

In this example, the current authentication mechanism is des and the new mechanism is dh640-0. Note the ordering is significant here; any mechanisms after the des entry will be ignored for client and server NIS+ authentication.

server# nisauthconf dh640-0 des
server# keylogin -r
		(screen notices not shown)
server# /etc/reboot

Configuring NIS+ Machines to Use New Security Mechanism Credentials

Now that the servers can accept the new credentials, the machines can be converted to authenticate by using the new credentials. To do this, run nisauthconf and keylogin as root and reboot.

Configuring NIS+ Machines to Use New Security Mechanism Credentials – Examples

In this example, the new mechanism is dh640-0 but the system will also attempt authentication with des credentials if the dh640-0 ones are not available or do not succeed.

workstation# nisauthconf dh640-0 des
workstation#  keylogin -r
		(screen notices not shown)
workstation# /etc/reboot

In the next example, the new mechanism is dh640-0 and authentication will only be attempted with this mechanism. Before configuring any system to authenticate by using the new mechanism exclusively, the cached directory objects must be refreshed to include the keys for the new mechanism. This can be verified with nisshowcache. An alternative to waiting for the cached directory objects to time out and be refreshed is the following: stop the NIS+ service, then construct a new NIS_COLD_START by using nisinit, and then restart the NIS+ service.

Manually Refresh NIS+ Directory Objects – Example NETNAMER

To manually refresh directory objects, use the svcadm command. See the svcadm(1M) man page for more information.

# svcadm disable -t /network/rpc/nisplus:default
# nisinit -cH masterserver
# svcadm enable /network/rpc/nisplus:default

The machine principal and all users of this machine must have dh640-0 credentials in the cred table before the system can be configured to authenticate exclusively with dh640-0.

workstation# nisauthconf dh640-0
workstation#  keylogin -r
		(screen notices not shown)
workstation# /etc/reboot

Changing the Password Protecting New NIS+ Credentials

For each user given new credentials with the dummy passwd, they need to run chkey to convert to their login password. For more information, see Changing Keys for an NIS+ Principal.

Change Password Protecting New NIS+ Credentials – Example

Run chkey to convert to your login password:

# chkey -p
		(screen notices not shown)

Configuring NIS+ Servers to Accept Only New Security Mechanism Credentials

When converting from a lower grade security mechanism to a higher one, the maximum security benefit is achieved by configuring the NIS+ servers to only accept credentials of the new higher grade security mechanism type. Do this only after the servers have been successfully configured to authenticate by using the old and the new mechanism.

Before configuring any system to authenticate by using the new mechanism exclusively, the cached directory objects must be refreshed to include the keys for the new mechanism and verified with nisshowcache.

Configuring NIS+ Servers to Accept Only New Security Mechanism Credentials – Example

Run nisauthconf(1m) on each NIS+ server and reboot. In this example, the NIS+ server will be configured to only accept authentication of dh640-0 credentials.

server#  nisauthconf dh640-0
server# /etc/reboot

Optionally, the directory objects can now be updated to remove the old public keys. This should be done from the master server and nisupdkeys(1m) should be run once for each directory served by the servers authenticating only with the new security mechanism. In this example, the directories to be updated are doc.com, org_dir.doc.com., and groups_dir.doc.com.

masterserver#	nisupdkeys doc.com.
			(screen notices not shown)
masterserver#  nisupdkeys org_dir.doc.com.
			(screen notices not shown)
masterserver#	nisupdkeys groups_dir.doc.com.

Removing Old Credentials From the NIS+ cred Table

If desired, the credentials of the old security mechanism can be removed from the cred table. You must have modify rights to the local domain's cred table. See Removing NIS+ Credential Information for more details.

Removing Old Credentials From the NIS+ cred Table – Example

In this example, the principal morena.doc.com will have her des credentials removed from the cred table.

master# nisaddcred -r morena.doc.com. dh192-0

Chapter 15 Administering NIS+ Access Rights

This chapter describes NIS+ access rights and how to administer them.

Some NIS+ security tasks can be performed more easily with Solaris Management Console tools if you have them available.

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.

About NIS+ Access Rights

NIS+ access rights determine what operations NIS+ users can perform and what information they have access to. This chapter assumes that you have an adequate understanding of the NIS+ security system in general, and in particular of the role that access rights play in that system (see Chapter 11, NIS+ Security Overview for this information).

For a complete description of NIS+ access-related commands and their syntax and options, see the NIS+ man pages.

Introduction to NIS+ Authorization and Access Rights

See NIS+ Authorization and Access for a description of how authorization and access rights work with NIS+ credentials and authentication to provide security for the NIS+ namespace.

NIS+ Authorization Classes – Review

As described more fully in NIS+ Authorization Classes, NIS+ access rights are assigned on a class basis.

There are four different NIS+ classes:

• Owner. The owner class is a single NIS+ principal. By default, an object's owner is the principal that created the object. However, an object's owner can transfer ownership to another principal who then becomes the new owner.

• Group. The group class is a collection of one or more NIS+ principals. An NIS+ object can have only one NIS+ group.

• World. The world class contains all NIS+ principals that are authenticated by NIS+ (in other words, everyone in the owner and group class, plus everyone else who presents a valid DES credential).

• Nobody. The nobody class is composed of anyone who is not properly authenticated (in other words, anyone who does not present a valid DES credential).

NIS+ Access Rights – Review

As described more fully in NIS+ Access Rights, there are four types of NIS+ access rights:

• Read. A principal with read rights to an object can view the contents of that object.

• Modify. A principal with modify rights to an object can change the contents of that object.

• Destroy. A principal with Destroy rights to an object can delete the object.

• Create. A principal with create rights to a higher level object can create new objects within that level. In other words, if you have create rights to an NIS+ directory object, you can create new tables within that directory. If you have create rights to an NIS+ table, you can create new columns and entries within that table.

Keep in mind that these rights logically evolve down from directory to table to table column and entry levels. For example, to create a new table, you must have create rights for the NIS+ directory object where the table will be stored. When you create that table, you become its default owner. As owner, you can assign yourself create rights to the table which allows you to create new entries in the table. If you create new entries in a table, you become the default owner of those entries. As table owner, you can also grant table level create rights to others. For example, you can give your table's group class table level create rights. In that case, any member of the table's group can create new entries in the table. The individual member of the group who creates a new table entry becomes the default owner of that entry.

Concatenation of NIS+ Access Rights

Authorization classes are concatenated. In other words, the higher class usually belongs to the lower class and automatically gets the rights assigned to the lower class.

The algorithm works like this:

• Owner class. An object's owner may, or may not, belong to the object's group. If the owner does belong to the group, then the owner gets whatever rights are assigned to the group. The object's owner automatically belongs to the world and nobody classes, so the owner automatically gets whatever rights that object assigns to those two classes.

• Group class. Members of the object's group automatically belong to the world and nobody classes, so the group members automatically get whatever rights that object assigns to world and nobody.

• World class. The world class automatically gets the same rights to an object that are given to the nobody class.

• Nobody class. The nobody class only gets those rights an object specifically assigns to the nobody class.

The basic principle that governs this is that access rights override the absence of access rights. In other words, a higher class can have more rights than a lower class, but not fewer rights. (The one exception to this rule is that if the owner is not a member of the group, it is possible to give rights to the group class that the owner does not have.)

How NIS+ Access Rights Are Assigned and Changed

When you create an NIS+ object, NIS+ assigns that object a default set of access rights for the owner and group classes. By default, the owner is the NIS+ principal who creates the object. The default group is the group named in the NIS_GROUP environment variable.

Specifying Different Default Rights in NIS+

NIS+ provides two different ways to change the default rights that are automatically assigned to an NIS+ object when it is created.

• The NIS_DEFAULTS environment variable. NIS_DEFAULTS stores a set of security-related default values, one of which is access rights. These default access rights are the ones automatically assigned to an object when it is created. (See Displaying NIS+ Defaults With nisdefaults for details.)

  If the value of the NIS_DEFAULTS environment variable is changed, objects created after the change are assigned the new values. However, previously created objects are not affected.

• The -D option, which is available with several NIS+ commands. When you use the -D option as part of the command to create an NIS+ object, it overrides the default rights specified by the NIS_DEFAULTS environment variable and allows you to explicitly specify an initial set of rights for that object. (See Specifying Non-Default Security Values at Creation Time in NIS+ for details.)

Changing Access Rights to an Existing NIS+ Object

When an NIS+ object is created, it comes into existence with a default set of access rights (from either the NIS_DEFAULTS environment variable or as specified with the -D option). These default rights can be changed with the

• nischmod command

• nistbladm command for table columns

NIS+ Table, Column, and Entry Security

NIS+ tables allow you to specify access rights on the table three ways:

• You can specify access rights to the table as a whole.

• You can specify access rights to each entry (row) by itself.

• You can specify access rights to each table column individually.

A field is the intersection between a column and an entry (row). All data values are entered in fields.

These column-level and entry-level access rights allow you to specify additional access to individual rows and columns that override table level restrictions, but column and entry level rights cannot be more restrictive than the table as a whole:

• Table. The table level is the base level. Access rights assigned at the table level apply to every piece of data in the table unless specifically modified by a column or entry exception. Thus, the table level rights should be the most restrictive.

  ---

  Note –

  Remember that authorization classes concatenate. A higher class gets the rights assigned to lower classes. See Concatenation of NIS+ Access Rights.

  ---

• Column. Column-level rights allow you to grant additional access rights on a column-by-column basis. For example, suppose the table level granted no access rights whatsoever to the world and nobody classes. In such a case, no one in those two classes could read, modify, create, or destroy any data in the table. You could use column-level rights to override that table level restriction and permit members of the world class the right to view data in a particular column.

  On the other hand, if the table level grants table-wide read rights to the owner and group classes, you cannot use column-level rights to prevent the group class from having read rights to that column.

• Entry (row). entry level rights allow you to grant additional access rights on a row-by-row basis. For example, this allows you to permit individual users to change entries that apply to them, but not entries that apply to anyone else.

  Keep in mind that an entry's group does not have to be the same as the table's group. Tables and entries can have different groups. This means that you can permit members of a particular group to work with one set of entries while preventing them from affecting entries belonging to other groups.

NIS+ Table, Column, Entry Example

Column- or entry level access rights can provide additional access in two ways: by extending the rights to additional principals or by providing additional rights to the same principals. Of course, both ways can be combined. Following are some examples.

Assume a table object granted read rights to the table's owner.

This means that the table's owner could read the contents of the entire table but no one else could read anything. You could then specify that Entry-2 of the table grant read rights to the group class.

Although only the owner could read all the contents of the table, any member of the table's group could read the contents of that particular entry. Now, assume that a particular column granted read rights to the world class.

Members of the world class could now read that column for all entries in the table. Members of the group class could read everything in Column-1 (because members of the group class are also members of the world class) and also all columns of Entry-2. Neither the world nor the group classes could read any cells marked *NP* (for Nor Permitted).

NIS+ Rights at Different Levels

This section describes how the four different access rights (read, create, modify, and destroy) work at the four different access levels (directory, table, column, and entry).

The objects that these various rights and levels act on are summarized in Table 15–5.

NIS+ Read Rights

• Directory. If you have read rights to a directory, you can list the contents of the directory.

• Table. If you have read rights to a table, you can view all the data in that table.

• Column. If you have read rights to a column, you can view all the data in that column.

• Entry. If you have read rights to an entry, you can view all the data in that entry.

NIS+ Create Rights

• Directory. If you have create rights at the directory level, you can create new objects in the directory such as new tables.

• Table. If you have create rights at the table level, you can create new entries. (You cannot add new columns to an existing table regardless of what rights you have.)

• Column. If you have create rights to a column, you can enter new data values in the fields of that column. You cannot create new columns.

• Entry. If you have create rights to an entry, you can enter new data values in the fields of that row. (Entry level create rights do not permit you to create new rows.)

NIS+ Modify Rights

• Directory. If you have modify rights at the directory level, you can move or rename directory objects.

• Table. If you have modify rights at the table level, you can change any data values in the table. You can create (add) new rows, but you cannot create new columns. If an existing field is blank, you can enter new data in it.

• Column. If you have modify rights to a column, you can change the data values in the fields of that column.

• Entry. If you have modify rights to an entry, you can change the data values in the fields of that row.

NIS+ Destroy Rights

• Directory. If you have destroy rights at the directory level, you can destroy existing objects in the directory such as tables.

• Table. If you have destroy rights at the table level, you can destroy existing entries (rows) in the table but not columns. You cannot destroy existing columns in a table: you can only destroy entries.

• Column. If you have destroy rights to a column, you can destroy existing data values in the fields of that column.

• Entry. If you have destroy rights to an entry, you can destroy existing data values in the fields of that row.

Where NIS+ Access Rights Are Stored

An object's access rights are specified and stored as part of the object's definition. This information is not stored in an NIS+ table.

Viewing an NIS+ Object's Access Rights

The access rights can be viewed by using the niscat command:

niscat -o objectname

Where objectname is the name of the object whose access rights you want to view.

This command returns the following information about an NIS+ object:

• Owner. The single NIS+ principal who has ownership rights. This is usually the person who created the object, but it could be someone to whom the original owner transferred ownership rights.

• Group. The object's NIS+ group.

• Nobody class access rights. The access rights granted to everyone, whether they are authenticated (have a valid DES credential) or not.

• Owner class access rights. The access rights granted to the object's owner.

• Group class access rights. The access rights granted to the principals in the object's group.

• World class access rights. The access rights granted to all authenticated NIS+ principals.

Access rights for the four authorization classes are displayed as a list of 16 characters, like this:

	r---rmcdr---r---

Each character represents a type of access right:

• r represents read rights.

• m represents modify rights.

• d represents destroy rights.

• c represents create rights.

• - represents no access rights.

The first four characters represent the access rights granted to nobody, the next four to the owner, the next four to the group, and the last four to the world.

Figure 15–1 NIS+ Access Rights Display

Unlike UNIX file systems, the first set of rights is for nobody, not for the owner.

Default NIS+ Access Rights

When you create an object, NIS+ assigns the object a default owner and group, and a default set of access rights for all four classes. The default owner is the NIS+ principal who creates the object. The default group is the group named in the NIS_GROUP environment variable. Table 15–6, shows the default access rights.

If you have the NIS_DEFAULTS environment variable set, the values specified in NIS_DEFAULTS will determine the defaults that are applied to new objects. When you create an object from the command line, you can use the -D flag to specify values other than the default values.

How an NIS+ Server Grants Access Rights to Tables

This section discusses how a server grants access to tables objects, entries, and columns during each type of operation: read, modify, destroy, and create.

At security level 0, a server enforces no NIS+ access rights and all clients are granted full access rights to the table object. Security level 0 is only for administrator setup and testing purposes. Do not use level 0 in any environment where ordinary users are performing their normal work.

The four factors that a server must consider when deciding whether to grant access are:

• The type of operation requested by the principal

• The table, entry, or column the principal is trying to access

• The authorization class the principal belongs to for that particular object

• The access rights that the table, entry, or column has assigned to the principal's authorization class

After authenticating the principal making the request by making sure the principal has a valid DES credential, an NIS+ server determines the type of operation and the object of the request.

• Directory. If the object is a directory or group, the server examines the object's definition to see what rights are granted to the four authorization classes, determines which class the principal belongs to, and then grants or denies the request based on the principal's class and the rights assigned to that class.

• Table. If the object is a table, the server examines the table's definition to see what table level rights are granted to the four authorization classes, and determines which class the principal belongs to. If the class to which the principal belongs does not have table level rights to perform the requested operation, the server then determines which row or column the operation concerns and determines if there are corresponding row-level or column-level access rights permitting the principal to perform the requested operation.

Specifying NIS+ Access Rights in Commands

This section assume an NIS+ environment running at security level 2 (the default level).

This section describes how to specify access rights, as well as owner, group owner, and object, when using any of the commands described in this chapter.

NIS+ Syntax for Access Rights

This subsection describes the access rights syntax used with the various NIS+ commands that deal with authorization and access rights.

NIS+ Class, Operator, and Rights Syntax

Access rights, whether specified in an environment variable or a command, are identified with three types of arguments: class, operator, and right.

• Class. Class refers to the type of NIS+ principal (authorization class) to which the rights will apply.

  Class	Description
  n	Nobody: all unauthenticated requests
  o	The owner of the object or table entry
  g	The group owner of the object or table entry
  w	World: all authenticated principals
  a	All: shorthand for owner, group, and world (this is the default)

• Operator. The operator indicates the kind of operation that will be performed with the rights.

  Operator	Description
  +	Adds the access rights specified by right
  -	Revokes the access rights specified by right
  =	Explicitly changes the access rights specified by right; in other words, revokes all existing rights and replaces them with the new access rights.

• Rights. The rights are the access rights themselves. The accepted values for each are listed below.

  Right	Description
  r	Reads the object definition or table entry
  m	Modifies the object definition or table entry
  c	Creates a table entry or column
  d	Destroys a table entry or column

You can combine operations on a single command line by separating each operation from the next with a comma (,).

NIS+ Syntax for Owner and Group

• Owner. To specify an owner, use an NIS+ principal name.

• Group. To specify an NIS+ group, use an NIS+ group name with the domain name appended.

Remember that principal names are fully qualified (principalname.domainname).

For owner

principalname

For group

groupname.domainname

NIS+ Syntax for Objects and Table Entries

Objects and table entries use different syntaxes.

• Objects use simple object names.

• Table entries use indexed names.

For objects

objectname

For table entries

columnname=value],tablename

In this case, the brackets are part of the syntax.

Indexed names can specify more than one column-value pair. If so, the operation applies only to the entries that match all the column-value pairs. The more column-value pairs you provide, the more stringent the search, as in the following.

Columns use a special version of indexed names. Because you can only work on columns with the nistbladm command, see Using the nistbladm Command With NIS+ Tables for more information.

Displaying NIS+ Defaults With nisdefaults

The nisdefaults command displays the seven default values currently active in the namespace. These default values are either

• Preset values supplied by the NIS+ software

• The defaults specified in the NIS_DEFAULTS environment variable (if you have NIS_DEFAULTS values set)

Any object that you create on this machine will automatically acquire these default values unless you override them with the -D option of the command you are using to create the object.

You can use these options to display all default values or any subset of them:

• To display all values in verbose format, type the nisdefaults command without arguments.

  master% nisdefaults Principal Name : topadmin.doc.com. Domain Name : doc.com. Host Name : rootmaster.doc.com. Group Name : salesboss Access Rights : ----rmcdr---r--- Time to live : 12:00:00:00:00 Search Path : doc.com.

• To display all values in terse format, add the -a option.

• To display a subset of the values, use the appropriate options. The values are displayed in terse mode. For example, to display the rights and search path defaults in terse mode, type the following.

  rootmaster% nisdefaults -rs ----rmcdr---r--- doc.com.

• To display a subset of the values in verbose mode, add the -v flag.

Setting NIS+ Default Security Values

This section describes how to perform tasks related to the nisdefaults command, the NIS_DEFAULTS environment variable, and the -D option.

The NIS_DEFAULTS environment variable specifies the following default values:

• Owner

• Group

• Access rights

• Time-to-live

The values that you set in the NIS_DEFAULTS environment variable are the default values applied to all NIS+ objects that you create using that shell (unless overridden by using the -D option with the command that creates the object).

You can specify the default values (owner, group, access rights, and time-to-live) specified with the NIS_DEFAULTS environment variable. Once you set the value of NIS_DEFAULTS, every object you create from that shell will acquire those defaults, unless you override them by using the -D option when you invoke a command.

Displaying the Value of the NIS+ NIS_DEFAULTS Variable

You can check the setting of an environment variable by using the echo command, as shown below:

client% echo $NIS_DEFAULTS
owner=butler:group=gamblers:access=o+rmcd

You can also display a general list of the NIS+ defaults active in the namespace by using the nisdefaults command as described in Displaying NIS+ Defaults With nisdefaults.

Changing NIS+ Defaults

You can change the default access rights, owner, and group, by changing the value of the NIS_DEFAULTS environment variable.

Use the environment command that is appropriate for your shell (setenv for C-shell or $NIS_DEFAULTS=, export for Bourne and Korn shells) with the following arguments:

• access=right, where right are the access rights using the formats described in Specifying NIS+ Access Rights in Commands.

• owner=name, where name is the user name of the owner.

• group=group, where group is the name of the default group.

You can combine two or more arguments into one line separated by colons:

-owner=principal-name:-group=group-name

Table 15–10 shows some examples.

All objects and entries created from the shell in which you changed the defaults will have the new values you specified. You cannot specify default settings for a table column or entry; the columns and entries simply inherit the defaults of the table.

Resetting the Value of NIS_DEFAULTS

You can reset the NIS_DEFAULTS variable to its original values, by typing the name of the variable without arguments, using the format appropriate to your shell:

For C shell

client# unsetenv NIS_DEFAULTS

For Bourne or Korn shell

client$ NIS_DEFAULTS=; export NIS_DEFAULTS

Specifying Non-Default Security Values at Creation Time in NIS+

You can specify different (that is, nondefault) access rights, owner, and group, any time that you create an NIS+ object or table entry with any of the following NIS+ commands:

• nismkdir – Creates NIS+ directory objects

• nisaddent – Transfers entries into an NIS+ table

• nistbladm – Creates entries in an NIS+ table

To specify security values other than the default values, insert the -D option into the syntax of those commands, as described in Specifying NIS+ Access Rights in Commands.

As when setting defaults, you can combine two or more arguments into one line. Remember that column and entry's owner and group are always the same as the table, so you cannot override them.

For example, to use the nismkdir command to create a sales.doc.com directory and override the default access right by granting the owner only read rights you would type:

client% nismkdir -D access=o+r sales.doc.com

Changing NIS+ Object and Entry Access Rights

The nischmod command operates on the access rights of an NIS+ object or table entry. It does not operate on the access rights of a table column; for columns, use the nistbladm command with the -D option. For all nischmod operations, you must already have modify rights to the object or entry.

Using nischmod to Add NIS+ Rights

To add rights for an object or entry use:

For object

nischmod class+right object-name

For table entry

nischmod class+right [column-name=value],table-name

For example, to add read and modify rights to the group of the sales.doc.com. directory object you would type:

client% nischmod g+rm sales.doc.com.

For example to add read and modify rights to group for the name=abe entry in the hosts.org_dir.doc.com. table you would type:

client% nischmod g+rm '[name=abe],hosts.org_dir.doc.com.'

Using nischmod to Remove NIS+ Rights

To remove rights for an object or entry use:

For object

nischmod class-right object-name

For entry

nischmod class-right [column-name=value],table-name

For example, to remove create and destroy rights from the group of the sales.doc.com. directory object you would type:

client% nischmod g-cd sales.doc.com.

For example to remove destroy rights from group for the name=abe entry in the hosts.org_dir.doc.com. table, you would type:

client% nischmod g-d '[name=abe],hosts.org_dir.doc.com.'

Specifying Column Access Rights in NIS+

The nistbladm command performs a variety of operations on NIS+ tables. Most of these tasks are described in Using the nistbladm Command With NIS+ Tables.

However, two of its options, -c and -u, enable you to perform some security-related tasks:

• The -c option. The -c option allows you to specify initial column access rights when creating a table with the nistbladm command.

• The -u option. The -u option allows you to change column access rights with the nistbladm command.

Setting Column Rights When Creating an NIS+ Table

When a table is created, its columns are assigned the same rights as the table object. These table level, rights are derived from the NIS_DEFAULTS environment variable, or are specified as part of the command that creates the table. You can also use the nistbladm -c option to specify initial column access rights when creating a table with nistbladm. To use this option you must have create rights to the directory in which you will be creating the table. To set column rights when creating a table use:

nistbladm -c type `columname=[flags] [,access]... tablename'

Where:

• type is a character string identifying the kind of table. A table's type can be anything you want it to be.

• columnname is the name of the column.

• flags is the type of column. Valid flags are:

  • S for searchable

  • I for case insensitive

  • C for encrypted

  • B for binary data

  • X for XDR encoded data

• access is the access rights for this column that you specify using the syntax described in Specifying NIS+ Access Rights in Commands.

• ... indicates that you can specify multiple columns each of the own type and with their own set of rights.

• tablename is the fully qualified name of the table you are creating.

To assign a column its own set of rights at table creation time, append access rights to each column's equal sign after the column type and a comma. Separate the columns with a space:

column=type,rights column=type,rights column=type,rights

The example below creates a table named depts in the doc.com directory, of type div, with three columns (Name, Site, and Manager), and adds modify rights for the group to the second and third columns:

rootmaster% nistbladm -c div Name=S Site=S,g+m Manager=S,g+m depts.doc.com.

For more information about the nistbladm and the -c option, see Chapter 19, Administering NIS+ Tables.

Adding Rights to an Existing NIS+ Table Column

The nistbladm -u option allows you to add additional column access rights to an existing table column with the nistbladm command. To use this option you must have modify rights to the table column. To add additional column rights use:

nistbladm -u [column=access,...],tablename

Where:

• column is the name of the column.

• access is the access rights for this column that you specify using the syntax described in Specifying NIS+ Access Rights in Commands.

• ... indicates that you can specify rights for multiple columns.

• tablename is the fully qualified name of the table you are creating.

Use one column=access pair for each column whose rights you want to update. To update multiple columns, separate them with commas and enclose the entire set with square brackets:

[column=access, column=access, column=access]

The full syntax of this option is described in Chapter 2, NIS+: An Introduction.

The example below adds read and modify rights to the group for the name and addr columns in the hosts.org_dir.doc.com. table.

client% nistbladm -u `[name=g+rm,addr=g+rm],hosts.org_dir..doc.com.'

Removing Rights to an NIS+ Table Column

To remove access rights to a column in an NIS+ table, you use the -u option as described above in Adding Rights to an Existing NIS+ Table Column except that you subtract rights with a minus sign (rather than adding them with a plus sign).

The example below removes group's read and modify rights to the hostname column in the hosts.org_dir.doc.com. table.

client% nistbladm -u 'name=g-rm,hosts.org_dir.doc.com.'

Changing Ownership of NIS+ Objects and Entries

The nischown command changes the owner of one or more objects or entries. To use it, you must have modify rights to the object or entry. The nischown command cannot change the owner of a column, since a table's columns belong the table's owner. To change a column's owner, you must change the table's owner.

Changing an NIS+ Object Owner With nischown

To change an object's owner, use the following syntax:

nischown new-owner object

Where:

• new-owner is the fully qualified user ID of the object's new owner.

• object is the fully qualified name of the object.

Be sure to append the domain name to both the object name and new owner name.

The example below changes the owner of the hosts table in the doc.com. domain to the user named lincoln whose home domain is doc.com.:

client% nischown lincoln.doc.com. hosts.org_dir.doc.com.

Changing an NIS+ Table Entry Owner With nischown

The syntax for changing a table entry's owner uses an indexed entry to identify the entry, as shown in the following, where:

• new-owner is the fully qualified user ID of the object's new owner.

• column is the name of the column whose value will identify the particular entry (row) whose owner is to be changed.

• value is the data value that identified the particular entry (row) whose owner is to be changed.

• ... indicates that you can specify ownership changes for multiple entries.

• tablename is the fully qualified name of the tables containing the entry whose owner is to be changed.

Be sure to append the domain name to both the new owner name and the table name.

The example below changes the owner of an entry in the hosts table of the doc.com. domain to takeda whose home domain is doc.com. The entry is the one whose value in the name column is virginia.

client% nischown takeda.doc.com. '[name=virginia],hosts.org_dir.doc.com.'

Changing an NIS+ Object or Entry's Group

The nischgrp command changes the group of one or more objects or table entries. To use it, you must have modify rights to the object or entry. The nischgrp command cannot change the group of a column, since the group assigned to a table's columns is the same as the group assigned to the table. To change a column's group owner, you must change the table's group owner.

Changing an NIS+ Object's Group With nischgrp

To change an object's group, use the following syntax:

nischgrp group object 

Where:

• group is the fully qualified name of the object's new group.

• object is the fully qualified name of the object.

Be sure to append the domain name to both the object name and new group name.

The example below changes the group of the hosts table in the doc.com. domain to admins.doc.com.:

client% nischgrp admins.doc.com. hosts.org_dir.doc.com.

Changing an NIS+ Table Entry's Group With nischgrp

The syntax for changing a table entry's group uses an indexed entry to identify the entry, as shown below (this syntax is fully described in NIS+ Syntax for Objects and Table Entries).

nischgrp new-group [column=value,...],tablename

Where:

• new-group is the fully qualified name of the object's new group.

• column is the name of the column whose value will identify the particular entry (row) whose group is to be changed.

• value is the data value that identified the particular entry (row) whose group is to be changed.

• tablename is the fully qualified name of the tables containing the entry whose group is to be changed.

• ... indicates that you can specify group changes for multiple entries.

Be sure to append the domain name to both the new group name and the table name.

The example below changes the group of an entry in the hosts table of the doc.com. domain to sales.doc.com. The entry is the one whose value in the host name column is virginia.

client% nischgrp sales.doc.com. '[name=virginia],hosts.org_dir.doc.com.'

Chapter 16 Administering NIS+ Passwords

This chapter describes how to use the passwd command from the point of view of an ordinary user (NIS+ principal) and how an NIS+ administrator manages the password system.

Some NIS+ security tasks can be performed more easily with Solaris Management Console tools if you have them available.

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.

Using Passwords in NIS+

When logging in to a machine, users must enter both a user name (also known as a login ID) and a password. Although login IDs are publicly known, passwords must be kept secret by their owners.

Logging In to an NIS+ Domain

Logging in to a system is a two-step process.

How to Use Passwords

1. Type your login ID at the Login: prompt.

2. Type your password at the Password: prompt.

   (To maintain password secrecy, your password is not displayed on your screen when you type it.)

   If your login is successful you will see your system's message of the day (if any) and then your command-line prompt, windowing system, or normal application.

Login incorrect Message

The Login incorrect message indicates that:

• You have entered the wrong login ID or the wrong password. This is the most common cause of the Login incorrect message. Check your spelling and repeat the process. Note that most systems limit to five the number of unsuccessful login tries you can make:

  • If you exceed a number of tries limit, you will get a Too many failures - try later message and not be allowed to try again until a designated time span has passed.

  • If you fail to successfully log in within a specified amount of time you will receive a Too many tries; try again later message, and not be allowed to try again until a designated time span has passed.

• Another possible cause of the Login incorrect message is that an administrator has locked your password and you cannot use it until it is unlocked. If you are sure that you are entering your login ID and password correctly, and you still get a Login incorrect message, contact your system administrator.

• Another possible cause of the Login incorrect message is that an administrator has expired your password privileges and you cannot use your password until your privileges are restored. If you are sure that you are entering your login ID and password correctly, and you still get a Login incorrect message, contact your system administrator.

Password will expire Message

If you receive a Your password will expire in N days message (where N is a number of days), or a Your password will expire within 24 hours message, it means that your password will reach its age limit and expire in that number of days (or hours).

In essence, this message is telling you to change your password now. (See Changing Your NIS+ Password.)

Permission denied Message at Login

After entering your login ID and password, you may get a Permission denied message and be returned to the login: prompt. This means that your login attempt has failed because an administrator has either locked your password, or terminated your account, or your password privileges have expired. In these situations you cannot log in until an administrator unlocks your password or reactivates your account or privileges. Consult your system administrator.

Changing Your NIS+ Password

To maintain security, you should change your password regularly. (See Choosing a Password for password requirements and criteria.)

The passwd command now performs all functions previously performed by nispasswd. For operations specific to an NIS+ name space, use passwd -r nisplus.

Changing your password is a four-step process:

How to Change Your NIS+ Password

1. Run the passwd command at a system prompt.

2. Type your old password at the Enter login password (or similar) prompt.

   Your keystrokes are not shown on your screen.

   • If you receive a Sorry: less than N days since the last change message, it means that your old password has not been in use long enough and you will not be allowed to change it at this time. You are returned to your system prompt. Consult your system administrator to find out the minimum number of days a password must be in use before it can be changed.

   • If you receive a You may not change this password message, it means that your network administrator has blocked any change.

3. Type your new password at the Enter new password prompt.

   Your keystrokes are not shown on your screen.

   At this point the system checks to make sure that your new password meets the requirements:

   • If it does meet the requirements, you are asked to enter it again.

   • If your new password does not meet the system requirements, a message is displayed informing you of the problem. You must then enter a new password that does meet the requirements.

   See Password Requirements for the requirements a password must meet.

4. Type your new password again at the Re-enter new password prompt.

   Your keystrokes are not shown on your screen.

   If your second entry of the new password is not identical to your first entry, you are prompted to repeat the process.

   ---

   Note –

   When changing root's password, you must always run chkey -p immediately after changing the password. (See Changing NIS+ Root Keys From Root and Changing Root Keys From Another NIS+ Machine for information on using chkey -p to change root's keys.) Failure to run chkey -p after changing root's password will result in root being unable to properly log in.

   ---

   If you receive a Your password has expired message it means that your password has reached its age limit and expired. In other words, the password has been in use for too long and you must choose a new password at this time. (See Choosing a Password, for criteria that a new password must meet.)

   In this case, choosing a new password is a three-step process:

   1. Type your old password at the Enter login password (or similar) prompt.

      Your keystrokes are not shown on your screen.

   2. Type your new password at the Enter new password prompt.

      Your keystrokes are not shown on your screen.

   3. Type your new password again at the Re-enter new password prompt.

      Your keystrokes are not shown on your screen.

NIS+ Password Change Failures

Some systems limit either the number of failed attempts you can make in changing your password or the total amount of time you can take to make a successful change. (These limits are implemented to prevent someone else from changing your password by guessing your current password.)

If you (or someone posing as you) fails to successfully log in or change your password within the specified number of tries or time limit, you will get a Too many failures - try later or Too many tries: try again later message. You will not be allowed to make any more attempts until a certain amount of time has passed. (That amount of time is set by your administrator.)

Choosing a Password

Many breaches of computer security involve guessing another user's password. While the passwd command enforces some criteria for making sure the password is hard to guess, a clever person can sometimes figure out a password just by knowing something about the user. Thus, a good password is one that is easy for you to remember but hard for someone else to guess. A bad password is one that is so hard for you to remember that you have to write it down (which you are not supposed to do), or that is easy for someone who knows about you to guess.

Password Requirements

A password must meet the following requirements:

• Length. By default, a password must have at least six characters. Only the first eight characters are significant. (In other words, you can have a password that is longer than eight characters, but the system only checks the first eight.) Because the minimum length of a password can be changed by a system administrator, it may be different on your system.

• Characters. A password must contain at least two letters (either uppercase or lowercase) and at least one numeral or symbol such as @,#,%. For example, you can use dog#food or dog2food as a password, but you cannot use dogfood.

• Not your login ID. A password cannot be the same as your login ID, nor can it be a rearrangement of the letters and characters of your login ID. (For the purpose of this criteria, upper and lower case letters are considered to be the same.) For example, if your login ID is Claire2 you cannot have e2clair as your password.

• Different from old password. Your new password must differ from your old one by at least three characters. (For the purpose of this criterion, uppercase and lowercase letters are considered to be the same.) For example, if your current password is Dog#fooD you can change it to dog#Meat but you cannot change it to daT#Food.

Bad Choices for Passwords

Bad choices for passwords include:

• Any password based on your name

• Names of family members or pets

• Car license numbers

• Telephone numbers

• Social Security numbers

• Employee numbers

• Names related to a hobby or interest

• Seasonal themes, such as Santa in December

• Any word that is in a standard dictionary

Good Choices for Passwords

Good choices for passwords include:

• Phrases plus numbers or symbols (beam#meup)

• Nonsense words made up of the first letters of every word in a phrase plus a number or symbol (swotrb7 for SomeWhere Over The RainBow)

• Words with numbers, or symbols substituted for letters (sn00py for snoopy)

Administering NIS+ Passwords

This section describes how to administer passwords in an NIS+ namespace. This section assumes that you have an adequate understanding of the NIS+ security system in general, and in particular of the role that login passwords play in that system (see Chapter 11, NIS+ Security Overview, for this information).

The passwd command now performs all functions previously performed by nispasswd. For operations specific to an NIS+ namespace, use passwd -r nisplus.

nsswitch.conf File Requirements for Passwords

In order to properly implement the passwd command and password aging on your network, the passwd entry of the nsswitch.conf file on every machine must be correct. This entry determines where the passwd command will go for password information and where it will update password information.

Only five passwd configurations are permitted:

• passwd: files

• passwd: files nis

• passwd: files nisplus

• passwd: compat

• passwd: compat passwd_compat: nisplus

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.

nispasswd Command

All functions previously performed by the nispasswd command are now performed by the passwd command. When issuing commands from the command line, you should use passwd, not nispasswd.

(The nispasswd command is still retained with all of its functionality for the purpose of backward compatibility.)

yppasswd Command

All functions previously performed by the yppasswd command are now performed by the passwd command. When issuing commands from the command line, you should use passwd, not yppasswd.

(The yppasswd is still retained with all of its functionality for the purpose of backward compatibility.)

passwd Command

The passwd command performs various operations regarding passwords. The passwd command replaces the nispasswd command. You should use the passwd command for all activities which used to be performed with the nispasswd command. (See the passwd command man page for a complete description of all passwd flags, options, and arguments.)

The passwd command allows users to perform the following operations:

• Change their passwords

• List their password information

Administrators can use the passwd command to perform the following operations:

• Force users to change their passwords the next time the log in

• Lock a user's password (prevent it from being used)

• Set a minimum number of days before a user can change passwords

• Specified when a user is warned to change passwords

• Set a maximum number of days a password can be used without being changed

passwd and the nsswitch.conf Files

The name service switch determines where the passwd command (and other commands) obtains and stores password information.

If the passwd entry of the applicable nsswitch.conf file points to:

• nisplus. Password information will be obtained, modified, and stored in the passwd and cred tables of the appropriate domain.

• nis. Password information will be obtained, modified, and stored in passwd maps.

• files. Password information will be obtained, modified, and stored in the /etc/passwd and /etc/shadow files.

passwd -r Option

When you run the passwd command with the -r nisplus, -r nis, or -r files arguments, those options override the nsswitch.conf file setting. You will be warned that this is the case. If you continue, the -r option will cause the passwd command to ignore the nsswitch.conf file sequence and update the information in the password information storage location pointed to by the -r flag.

For example, if the passwd entry in the applicable nsswitch.conf file reads:

 passwd: files nisplus

files is the first (primary) source, and passwd run without the -r option will get its password information from the /etc/passwd file. If you run the command with the -r nisplus option, passwd will get its information from the appropriate NIS+ passwd table and make its changes to that table, not to the /etc/passwd file.

The -r option should only be used when you cannot use the nsswitch.conf file because the search sequence is wrong. For example, when you need to update password information that is stored in two places, you can use the order specified in the nsswitch.conf file for the first one, but for the second one you have to force the use of the secondary or tertiary source.

The message:

Your specified repository is not defined in the nsswitch file!

indicates that your change will be made to the password information in the repository specified by the -r option, but that change will not affect anyone until the nsswitch.conf file is changed to point to that repository. For example, suppose the nsswitch.conf file reads passwd: files nis and you use the -r nisplus option to establish password-aging limits in an NIS+ passwd table. Those password-aging rules will sit in that table unused because the nsswitch.conf file is directing everyone to other places for their password information.

passwd Command and “NIS+ Environment”

In this chapter, the phrase NIS+ environment refers to situations where the passwd entry of the applicable nsswitch.conf file is set to nisplus, or the passwd command is run with the -r nisplus argument.

passwd Command and Credentials

When run in an NIS+ environment (see above), the passwd command is designed to function with or without credentials. Users without credentials are limited to changing their own password. Other password operations can only be performed by users who have credentials (are authenticated) and who have the necessary access rights (are authorized).

passwd Command and NIS+ Permissions

In this discussion of authorization and permissions, it is assumed that everyone referred to has the proper credentials.

By default, in a normal NIS+ environment the owner of the passwd table can change password information at any time and without constraints. In other words, the owner of the passwd table is normally granted full read, modify, create, and destroy authorization (permission) for that table.

An owner can also:

• Assign table ownership to someone else with the nischown command.

• Grant some or all of read, modify, create, and destroy rights to the table's group, or even to the world or nobody class. (Of course, granting such rights to world or nobody seriously weakens NIS+ security.)

• Change the permissions granted to any class with the nisdefaults, nischmod, or nistbladm commands.

Regardless of what permissions they have, everyone in the world, and nobody classes are forced to comply with password-aging constraints. In other words, they cannot change a password for themselves or anyone else unless that password has aged past its minimum. Nor can members of the group, world, and nobody classes avoid having to change their own passwords when the age limit has been reached. However, age constraints do not apply to the owner of the passwd table.

To use the passwd command in an NIS+ environment, you must have the required authorization (access rights) for the operation.

passwd Command and NIS+ Keys

If you use passwd in an NIS+ environment to change a principal's password, it tries to update the principal's private (secret) key in the cred table.

• If you have modify rights to the DES entry in the cred table and if the principal's login and Secure RPC passwords are the same, passwd will update the private key in the cred table.

• If you do not have modify rights to the DES entry in the cred table or if the principal's login and Secure RPC passwords are not the same, the passwd command will change the password, but not change the private key.

  If you do not have modify rights to the DES entry, it means that the private key in the cred table will have been formed with a password that is now different from the one stored in the passwd table. In this case, the user will have to change keys with the chkey command or run keylogin after each login.

passwd Command and Other NIS+ Domains

To operate on the passwd table of another domain, use:

passwd [options] -D domainname

nistbladm Command

The nistbladm command allows you to create, change, and display information about any NIS+ table, including the passwd table.

To perform password operations using the nistbladm command you must apply nistbladm to the shadow column of the passwd table. Applying nistbladm to the shadow column is complex and tricky. Therefore, you should not use the nistbladm command for any operation that can more easily be performed by the passwd command or by using the Solaris Management Console tools.

Use the passwd command or Solaris Management Console tools to perform the following operations:

• Changing a password

• Setting the maximum period that a password can be used (password aging)

• Setting the minimum period that a password must be used

• Setting the password warning period

• Turning off password aging

It is possible to use the nistbladm command to:

• Create new passwd table entries

• Delete an existing entry

• Change the UID and GID fields in the passwd table

• Change access rights and other security-related attributes of the passwd table

• Set expiration and inactivity periods for a user's account (see Password Privilege Expiration in NIS+ and Specifying Maximum Number of Inactive Days for Users in NIS+)

nistbladm and NIS+ Shadow Column Fields

You use the nistbladm command to set password parameters by specifying the values of the different fields in the shadow column. These fields are entered in the format:

Where:

• N1 Lastchange. The date of the last password change expressed as a number of days since January 1, 1970. The value in this field is automatically updated each time the user changes passwords. (See nistbladm and the Number of Days Password Parameter in NIS+ for important information regarding the number of days.) If the field is blank, or contains a zero, it indicates that there has not been any change in the past.

  Note that the number of days in the lastchange field is the base from which other fields and operations are calculated. Thus, an incorrect change in this field could have unintended consequence in regards to minimum, maximum, warning, and inactive time periods.

• N2 Min. The minimum number of days that must pass since the last time the password was changed before the user can change passwords again. For example, if the value in the lastchange field is 9201 (that is, 9201 days since 1/1/70) and the value in the min field is 8, the user is unable to change passwords until after day 9209. See Setting Minimum Password Life in NIS+ for additional information on password minimums.

  Where min is one of the following values:

  • Zero (0). A value of zero in this field (or a blank space) means that there is no minimum period.

  • Greater than zero. Any number greater than zero sets that number of days as the minimum password life.

  • Greater than max. A value in this field that is greater than the value in the max field prevents the user from ever changing passwords. The message: You may not change this password is displayed when the user attempts to change passwords.

• N3 Max. The maximum number of days that can pass since the last time the password was changed. Once this maximum number of days is exceeded, the user is forced to choose a new password the next time the user logs in. For example, if the value in the lastchange field is 9201 and the value in the max field is 30, after day 9231 (figured 9201+30=9231), the user is forced to choose a new password at the next login. See Setting a Password Age Limit in NIS+ for additional information on password maximums.

  Where max is one of the following values:

  • Zero (0). A value of zero (0) forces the user to change passwords the next time the user logs in, and it then turns off password aging.

  • Greater than zero. Any number greater than zero sets that number of days before the password must be changed.

  • Minus one (-1). A value of minus one (-1) turns off password aging. In other words, entering passwd -x -1 username cancels any previous password aging applied to that user. A blank space in the field is treated as if it were a minus one.

• N4 Warn. The number of days before a password reaches its maximum that the user is warned to change passwords. For example, suppose the value in the lastchange field is 9201, the value in the max field is 30, and the value in the warn field is 5. Then after day 9226 (figured 9201+30-5=9226) the user starts receiving “change your password” type warnings at each longing time. See Establishing a Password Warning Period in NIS+ for additional information on password warning times.

  Where warn is one of the following values:

  • Zero (0). No warning period.

  • Greater than zero. A value of zero (0) sets the warning period to that number of days.

• N5 Inactive. The maximum number of days between logins. If this maximum is exceeded, the user is not allowed to log in. For example, if the value of this field is 6, and the user does not log in for six days, on the seventh day the user is no longer allowed to log in. See Specifying Maximum Number of Inactive Days for Users in NIS+ for additional information on account inactivity.

  Where inactive is one of the following values:

  • Minus one (-1). A value of minus one (-1) turns off the inactivity feature. The user can be inactive for any number of days without losing login privileges. This is the default.

  • Greater than zero. A value greater than zero sets the maximum inactive period to that number of days.

• N6 Expire. The date on which a password expires, expressed as a number of days since January 1, 1970. After this date, the user can no longer log in. For example, if this field is set to 9739 (September 1, 1995) on September 2, 1995 GMT, the user will not be able to login and will receive a Login incorrect message after each try. See Password Privilege Expiration in NIS+ for additional information on password expiration.

  Where expire is one of the following values:

  • Minus one (-1). A value of minus one (-1) turns off the expiration feature. If a user's password has already expired, changing this value to -1 restores it. If you do not want to set any expiration date, type a -1 in this field.

  • Greater than zero. A value greater than zero sets the expiration date to that number of days since 1/1/70. If you enter today's date or an earlier date, you immediately deactivate the users password.

• N7 Unused. This field is not currently used. Values entered in this field will be ignored.

• Login is the user's login ID.

When using nistbladm on the shadow column of the password table, all of the numeric fields must contain appropriate values. You cannot leave a field blank, or enter a zero, as a no change placeholder.

For example, to specify that the user amy last changed her password on day 9246 (May 1, 1995), cannot change her password until it has been in use for 7 days, must change her password after 30 days, will be warned to change her password after 25 days, must not remain inactive more than 15 days, and has an account that will expire on day number 9285, you would type:

nistbladm -m shadow=9246:7:30:5:15:9285 [name=amy], passwd.org.dir

nistbladm and the Number of Days Password Parameter in NIS+

Most password aging parameters are expressed in number of days.

The following principles and rules apply:

• Days are counted from January 1, 1970. That is day zero. January 2, 1970, is day 1.

• NIS+ uses Greenwich mean time (GMT) in figuring and counting days. In other words, the day count changes at midnight GMT.

• When you specify a number of days, you must use a whole number. You cannot use fractions of days.

• When the number of days is used to specify some action, such as locking a password, the change takes effect on the day. For example, if you specify that a user's password privilege expires on day 9125 (January 2, 1995), that is the last day that the user can use the password. On the next day, the user can no longer use the password.

Values are entered in both the Lastchange and the Expire fields as a number of days since January 1, 1970, as in the following.

Password-Related Commands in NIS+

The passwd and nistbladm commands provide capabilities that are similar to those offered by other commands. Table 16–3 summarizes their differences.

Displaying Password Information in NIS+

You can use the passwd command to display password information about all users in a domain or about one particular user:

For your password information

passwd -s

For all users in current domain

passwd -s -a

For a particular user

passwd -s username

Only the entries and columns for which you have read permission will be displayed.

Entries are displayed with the following format:

• Without password aging: username status

• With password aging: username status mm/dd/yy min max warn expire inactive

To display entries from a passwd table in another domain, use the -D option:

For all users in another domain

passwd -s -a -D domainname

For a particular user

passwd -s -D domainname username

Changing Passwords in NIS+

New passwords must meet the criteria described in Password Requirements.

Changing Your Own Password

To change your password, type

station1% passwd

You will be prompted for your old password and then the new password and then the new password a second time to confirm it.

Changing Someone Else's Password in NIS+

To change another user's password in the same domain, use:

passwd username

To change another user's password in a different domain, use:

passwd -D domainname username

When using the passwd command in an NIS+ environment (see passwd Command and “NIS+ Environment”) to change someone else's password you must have modify rights to that user's entry in the passwd table (this usually means that you are a member of the group for the passwd table and the group has modify rights). You do not have to enter either the user's old password or your password. You will be prompted to enter the new password twice to make sure that they match. If they do not match, you will be prompted to enter them again.

Changing Root's Password in NIS+

When changing root's password, you must always run chkey -p immediately after changing the password with the passwd command. Failure to run chkey -p after changing root's password will result in root being unable to properly log in.

To change a root password, follow these steps:

How to Change root's Password

1. Log in as root.

2. Change root's password using passwd.

   Do not use nispasswd.

3. Run chkey -p.

   You must use the -p option.

Locking a Password in NIS+

When operating in an NIS+ environment (see passwd Command and “NIS+ Environment”), an administrator (a group member) with modify rights to a user's entry in the passwd table can use the passwd command to lock a password. An account with a locked password cannot be used. When a password is locked, the user will receive a Login incorrect message after each login attempt.

Keep in mind that locked passwords have no effect on users who are already logged in. A locked password only prevents users from performing those operations that require giving a password such as login, rlogin, ftp, or telnet.

Note also that if a user with a locked password is already logged in, and that user uses the passwd command to change passwords, the lock is broken.

You can use this feature to:

• Temporarily lock a user's password while that user is on vacation or leave. This prevents anyone from logging in as the absent user.

• Immediately lock one or more user passwords in the case of suspected security problem.

• Quickly lock a dismissed employee out of the system. This is quicker and easier than eliminating that user's account and is an easy way of preserving any data stored in that account.

• If you have assigned passwords to UNIX processes, you can lock those passwords. This allows the process to run, but prevents anyone from logging in as those processes even if they know the process password. (In most cases, processes would not be set up as NIS+ principals, but would maintain their password information in /etc files. In such a case you would have to run the passwd command in files mode to lock /etc stored passwords.)

To lock a password, use:

passwd -l username

Unlocking a Password in NIS+

To unlock a user's password, you simply change it. You can “change” it back to the exact same password that it was when it was locked. Or you can change it to something new.

For example, to unlock jody's password, you would enter:

station1% passwd jody

Managing Password Aging in NIS+

Password aging is a mechanism you can use to force users to periodically change their passwords. Password aging allows you to:

• Force a user to choose a new password the next time the user logs in. (See Forcing Users to Change Passwords in NIS+ for details.)

• Specify a maximum number of days that a password can be used before it has to be changed. (See Setting a Password Age Limit in NIS+ for details.)

• Specify a minimum number of days that a password has to be in existence before it can be changed. (See Setting Minimum Password Life in NIS+ for details.)

• Specify that a warning message be displayed whenever a user logs in a specified number of days before the user's password time limit is reached. (See Establishing a Password Warning Period in NIS+ for details.)

• Specify a maximum number of days that an account can be inactive. If that number of days pass without the user logging in to the account, the user's password will be locked. (See Specifying Maximum Number of Inactive Days for Users in NIS+ for details.)

• Specify an absolute date after which a user's password cannot be used, thus denying the user the ability to log in to the system. (See Password Privilege Expiration in NIS+ for details.)

Keep in mind that users who are already logged in when the various maximums or dates are reached are not affected by the preceding features. They can continue to work as normal.

Password aging limitations and activities are only activated when a user logs in or performs one of the following operations:

• login

• rlogin

• telnet

• ftp

These password aging parameters are applied on user-by-user basis. You can have different password aging requirements for different users. (You can also set general default password aging parameters as described in Managing Password Aging in NIS+.)

Forcing Users to Change Passwords in NIS+

There are two ways to force a user to change passwords the next time the user logs in:

Force change keeping password aging rules in effect

passwd -f username

Force change and turn off password aging rules

passwd -x 0 username

Setting a Password Age Limit in NIS+

The -max argument to the passwd command sets an age limit for the current password. In other words, it specifies the number of days that a password remains valid. After that number of days, a new password must be chosen by the user. Once the maximum number of days have passed, the next time the user tries to login with the old password a Your password has been expired for too long message is displayed and the user is forced to choose a new password in order to finish logging in to the system.

The max argument uses the following format:

passwd -x max username

Where:

• username is the login ID of the user

• max is one of the following values:

  • Greater than zero. Any number greater than zero sets that number of days before the password must be changed.

  • Zero (0). A value of zero (0) forces the user to change passwords the next time the user logs in, and it then turns off password aging.

  • Minus one (-1). A value of minus one (-1) turns off password aging. In other words, entering passwd -x -1 username cancels any previous password aging applied to that user.

For example, to force the user schweik to change passwords every 45 days, you would type the command:

station1% passwd -x 45 schweik

Setting Minimum Password Life in NIS+

The min argument to the passwd command specifies the number of days that must pass before a user can change passwords. If a user tries to change passwords before the minimum number of days has passed, a Sorry less than N days since the last change message is displayed.

The min argument uses the following format:

passwd -x max -n min username

Where:

• username is the login ID of the user

• max is the maximum number of days a password is valid as described in the section above

• min is the minimum number of days that must pass before the password can be changed

For example, to force the user eponine to change passwords every 45 days, and prevent him from changing it for the first 7 days you would type the command:

station1% passwd -x 45 -n 7 eponine

The following rules apply to the min argument:

• You do not have to use a min argument or specify a minimum number of days before a password can be changed.

• If you do use the min argument, it must always be used in conjunction with the -max argument. In other words, in order to set a minimum value you must also set a maximum value.

• If you set min to be greater than max, the user is unable to change passwords at all. For example, the command passwd -x 7 -n 8 prevents the user from changing passwords. If the user tries to change passwords, the You may not change this password message is displayed. Setting the min value greater than the max value has two effects:

  • The user is unable to change password. In this case, only someone with administer privileges could change the password. For example, in situations where multiple users share a common group password, setting the min value for that password greater than the max value would prevent any individual user from changing the group password.

  • The password is only valid for the length of time set by the max value, but the user cannot change it because the min value is greater than the max value. Thus, there is no way for the user to prevent the password from becoming invalid at the expiration of the max time period. In effect, this prevents the user from logging in after the max time period unless an administrator intervenes.

Establishing a Password Warning Period in NIS+

The warn argument to the passwd command specifies the number of days before a password reaches its age limit that users will start to seeing a Your password will expire in N days message (where N is the number of days) when they log in.

For example, if a user's password has a maximum life of 30 days (set with the -max argument) and the warn value is set to 7 days, when the user logs in on day 24 (one day past the warn value) the warning message Your password will expire in 7 days is displayed. When the user logs in on day 25, the warning message Your password will expire in 6 days is displayed.

Keep in mind that the warning message is not sent by Email or displayed in a user's console window. It is displayed only when the user logs in. If the user does not log in during this period, no warning message is given.

Keep in mind that the warn value is relative to the max value. In other words, it is figured backwards from the deadline set by the max value. Thus, if the warn value is set to 14 days, the Your password will expire in N days message will begin to be displayed two weeks before the password reaches its age limit and must be changed.

Because the warn value is figured relative to the max value, it only works if a max value is in place. If there is no max value, warn values are meaningless and are ignored by the system.

The warn argument uses the following format:

passwd -x max -w warn username

Where:

• username is the login ID of the user.

• max is the maximum number of days a password is valid as described on Setting a Password Age Limit in NIS+.

• warn is the number of days before the password reaches its age limit that the warning message will begin to be displayed.

For example, to force the user nilovna to change passwords every 45 days, and display a warning message 5 days before the password reaches its age limit you would type the command:

station1% passwd -x 45 -w 5 nilovna

The following rules apply to the warn argument:

• You do not have to use the warn argument or specify a warning message. If no warn value is set, no warning message is displayed prior to a password reaching its age limit.

• If you do use the warn argument, it must always be used in conjunction with the max argument. In other words, in order to set a warning value you must also set a maximum value.

You can also use Solaris Management Console to set a warn value for a user's password.

Turning Off Password Aging in NIS+

There are two ways to turn off password aging for a given user:

Turn off aging while allowing user to retain current password

passwd -x -1 username

Force user to change password at next login, and then turn off aging

passwd -x 0 username

This sets the max value to either zero or -1 (see Setting a Password Age Limit in NIS+ for more information on this value).

For example, to force the user mendez to change passwords the next time he logs in and then turn off password aging you would type the command:

station% passwd -x 0 mendez

You can also use Solaris Management Console to set this parameter for a user's password.

You can also use the nistbladm command to set this value. For example, to turn off password aging for the user otsu and allow her to continue using her current password, you would type:

station1% nistbladm -m `shadow=0:0:-1:0:0:0:0' [name=otsu],passwd.org_dir

For additional information on using the nistbladm command, see nistbladm Command.

Password Privilege Expiration in NIS+

You can set a specific date on which a user's password privileges expires. When a user's password privilege expires, that user can no longer have a valid password at all. In effect, this locks the user out of the system after the given date because after that date the user can no longer log in.

For example, if you specify an expire date of December 31, 1997, for a user named pete, on January 1, 1998 he will not be able to log in under that user ID regardless of what password he uses. After each login attempt he will receive a Login incorrect message.

Password Aging and Password Expiration in NIS+

Expiration of a user's password privilege is not the same as password aging.

• Password aging. A password that has not been changed for longer than the aging time limit is sometimes referred to as an expired password. But that password can still be used to log in one more time. As part of that last login process the user is forced to choose a new password.

• Expiration of password privilege. When a user's password privilege expires, the user cannot log in at all with any password. In other words, it is the user's permission to log in to the network that has expired.

Setting a Password Expiration Date in NIS+

Password privilege expiration dates only take effect when the user logs in. If a user is already logged in, the expiration date has no effect until the user logs out or tries to use rlogin or telnet to connect to another machine at which time the user will not be able to log in again. Thus, if you are going to implement password privilege expiration dates, you should require your users to log out at the end of each day's work session.

If you have Solaris Management Console tools available, do not use nistbladm to set an expiration date. Use Solaris Management Console tools because they are easier to use and provide less chance for error.

To set an expiration date with the nistbladm command:

nistbladm -m `shadow=n:n:n:n:n:n6:n' [name=login],passwd.org_dir

Where:

• login is the user's login ID

• n indicates the values in the other fields of the shadow column

• n6 is the date on which the user's password privilege expires This date is entered as a number of days since January 1, 1970 (see Table 16–2). n6 can be one of the following values:

  • Minus one (-1). A value of minus one (-1) turns off the expiration feature. If a user's password has already expired, changing this value to -1 restores the password. If you do not want to set any expiration date, type -1 in this field.

  • Greater than zero. A value greater than zero sets the expiration date to that number of days since 1/1/70. If you enter today's date or an earlier date, you immediately expire the user's password.

For example, to specify an expiration date for the user pete of December 31, 1995 you would type:

station1% nistbladm -m `shadow=n:n:n:n:n:9493:n' [name=pete],passwd.org_dir

All of the fields must be filled in with valid values.

Turning Off Password Privilege Expiration in NIS+

To turn off or deactivate password privilege expiration, you must use the nistbladm command to place a -1 in this field. For example, to turn off privilege expiration for the user huck, you would type:

station1% nistbladm -m `shadow=n:n:n:n:n:-1:n' [name=huck],passwd.org_dir

Or you can use the nistbladm command reset the expiration date to some day in the future by entering a new number of days in the n6 field.

Specifying Maximum Number of Inactive Days for Users in NIS+

You can set a maximum number of days that a user can go without logging in on a given machine. Once that number of days passes without the user logging in, that machine will no longer allow that user to log in. In this situation, the user will receive a Login incorrect message after each login attempt.

This feature is tracked on a machine-by-machine basis, not a network-wide basis. That is, in an NIS+ environment, you specify the number of days a user can go without logging in by placing an entry for that user in the passwd table of the user's home domain. That number applies for that user on all machines on the network.

For example, suppose you specify a maximum inactivity period of 10 days for the user sam. On January 1, sam logs in to both machine-A and machine-B, and then logs off both machines. Four days later on January 4, sam logs in on machine-B and then logs out. Nine days after that on January 13, sam can still log in to machine-B because only 9 days have elapsed since the last time he logged in on that machine, but he can no longer log in to machine-A because thirteen days have passed since his last log in on that machine.

Keep in mind that an inactivity maximum cannot apply to a machine the user has never logged in to. No matter what inactivity maximum has been specified or how long it has been since the user has logged in to some other machine, the user can always log in to a machine that the user has never logged in to before.

Do not set inactivity maximums unless your users are instructed to log out at the end of each workday. The inactivity feature only relates to logins; it does not check for any other type of system use. If a user logs in and then leaves the system up and running at the end of each day, that user will soon pass the inactivity maximum because there has been no login for many days. When that user finally does reboot or log out, he or she won't be able to log in.

If you have Solaris Management Console tools available, do not use nistbladm to set an inactivity maximum. Use Solaris Management Console tools because they are easier to use and provide less chance for error.

To set a login inactivity maximum, you must use the nistbladm command in the format:

nistbladm -m `shadow=n:n:n:n:n5:n:n' [name=login],passwd.org_dir

Where:

• login is the user's login ID

• n indicates the values in the other fields of the shadow column

• n5 is the number of days the user is allowed to go between logins. Inactive can be one of the following values:

  • Minus one (-1). A value of minus one (-1) turns off the inactivity feature. The user can be inactive for any number of days without losing login privileges. This is the default.

  • Greater than zero. A value greater than zero sets the maximum inactive period to that number of days.

For example, to specify that the user sam must log in at least once every seven days, you would type:

station1% nistbladm -m `shadow=n:n:n:n:n:7:n:n' [name=sam],passwd.org_dir

To clear an inactivity maximum and allow a user who has been prevented from logging in to log in again, use nistbladm to set the inactivity value to -1.

Specifying Password Criteria and Defaults in NIS+

The following subsections describe various password-related defaults and general criteria that you can specify.

/etc/defaults/passwd File

The /etc/defaults/passwd file is used to set four general password defaults for users whose nsswitch.conf file points to files. The defaults set by the /etc/defaults/passwd file apply only to those users whose operative password information is taken from /etc files; they do not apply to anyone using either NIS maps or NIS+ tables. An /etc/defaults/passwd file on an NIS+ server only affects local users who happen to be obtaining their password information from those local files. An /etc/defaults/passwd file on an NIS+ server has no effect on the NIS+ environment or users whose nsswitch.conf file points to either nis or nisplus.

The four general password defaults governed by the /etc/defaults/passwd file are:

• Maximum number of weeks the password is valid

• Minimum number of weeks the password is valid

• The number of weeks before the password becomes invalid that the user is warned

• The minimum number of characters that a password must contain

The following principles apply to defaults set with an /etc/defaults/passwd file:

• For users who obtain password information from local /etc files, individual password aging maximums, minimums and warnings set by the password command or Solaris Management Console override any /etc/defaults/passwd defaults. In other words, defaults set in the /etc/defaults/passwd file are not only applied to those users who do not have corresponding individual settings in their entries in their passwd table.

• Except for password length, all the /etc/defaults/passwd file defaults are expressed as a number of weeks. (Remember that individual password aging times are expressed as a number of days.)

• The MAXWEEKS, MINWEEKS, and WARNWEEKS defaults are all counted forward from the date of the user's last password change. (Remember that individual warn values are counted backwards from the maximum date.)

By default, /etc/defaults/passwd files already contain the entries:

MAXWEEKS=
MINWEEKS=
PASSLENGTH=

To implement an entry, simply type the appropriate number after the equal sign. Entries that do not have a number after the equal sign are inactive and have no effect on any user. Thus, to set a MAXWEEKS default of 4, you would change the /etc/defaults/passwd file to read:

MAXWEEKS=4
MINWEEKS=
PASSLENGTH=

Maximum Weeks

You can use the MAXWEEKS default in the /etc/defaults/passwd file to set the maximum number of weeks that a user's password is valid. To set a default maximum time period, type the appropriate number of weeks after the equal sign in the MAXWEEKS= line:

MAXWEEKS=N

Where N is a number of weeks. For example, MAXWEEKS=9.

Minimum Weeks

You can use the MINWEEKS default in the /etc/defaults/passwd file to set the minimum number of weeks that must pass before a user can change passwords. To set a default minimum time period, type the appropriate number of weeks after the equal sign on the MINWEEKS= line:

MINWEEKS=N

Where N is a number of weeks. For example, MINWEEKS=2.

Warning Weeks

You can add a WARNWEEKS default to the /etc/defaults/passwd file set the number of weeks prior to a password becoming invalid due to aging that user is warned. for example, if you have set the MAXWEEKS default to 9, and you want users to be warned two weeks before their passwords become invalid, you would set the MAXWEEKS default to 7.

There is no point in setting the WARNWEEKS default unless you also set a MAXWEEKS default.

Remember that WARNWEEKS are counted forward from the date of the user's last password change, not backwards from the MAXWEEKS expiration date. Thus, WARNWEEKS must always be less than MAXWEEKS and cannot be equal to or greater than MAXWEEKS.

A WARNWEEKS default will not work unless there is also a MAXWEEKS default.

To set the warning time period, type the appropriate number of weeks after the equal sign on the WARNWEEKS= line.

WARNWEEKS=N

Where Nis the number of weeks. For example, WARNWEEKS=1.

Minimum Password Length

By default, the passwd command assumes a minimum length of six characters. You can use the PASSLENGTH default in the /etc/defaults/passwd files to change that by setting the minimum number of characters that a user's password must contain to some other number.

To set the minimum number of characters to something other than six, type the appropriate number of characters after the equal sign in the PASSLENGTH= line:

PASSLENGTH=N

Where Nis the number of characters. For example, PASSLENGTH=7.

Password Failure Limits

You can specify a number-of-tries limit or an amount-of-time limit (or both) for a user's attempt to change passwords. These limits are specified by adding arguments when starting the rpc.nispasswdd daemon.

Limiting the number of attempts or setting a time frame provides a limited (but not foolproof) defense against unauthorized persons attempting to change a valid password to one that they discover through trial and error.

Maximum Number of Tries

To set the maximum number of times a user can try to change a password without succeeding, use the -a number argument with rpc.nispasswdd, where number is the number of allowed tries. (You must have superuser privileges on the NIS+ master server to run rpc.nispasswdd.)

For example, to limit users to no more than four attempts (the default is 3), you would type:

station1# rpc.nispasswdd -a 4

In this case, if a user's fourth attempt at logging in is unsuccessful, the message Too many failures - try later is displayed. No further attempts are permitted for that user ID until a specified period of time has passed.

Maximum Login Time Period

To set the maximum amount a time a user can take to successfully change a password, use the -c minutes argument with rpc.nispasswdd, where minutes is the number of minutes a user has to log in. (You must have superuser privileges on the NIS+ master server to run rpc.nispasswdd.)

For example, to specify that users must successfully log in within 2 minutes, you would type:

station1# rpc.nispasswdd -c 2

In this case, if a user is unable to successfully change a password within 2 minutes, the message is displayed at the end of the two-minute period. No further attempts are permitted for that user ID until a specified period of time has passed.

Chapter 17 Administering NIS+ Groups

This chapter describes NIS+ groups and how to administer them.

Some NIS+ security group tasks can be performed more easily with Solaris Management Console tools if you have them available.

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.

Solaris Groups and NIS+ Groups

The Solaris NIS+ environment defines three kinds of groups: UNIX groups, net groups, and NIS+ groups.

• UNIX groups. A UNIX group is simply a collection of users who are given additional UNIX access permissions. In an NIS+ namespace, UNIX group information is stored in the group table located in the org_dir directory object (group.org_dir). See Chapter 19, Administering NIS+ Tables for information on how to add, modify, or delete members of a UNIX group.

• Net groups. A net group is a group of machines and users that have permission to perform remote operations on other machines. In an NIS+ namespace, net groups information is stored in the netgroup table located in the org_dir directory object (netgroup.org_dir). See Chapter 19, Administering NIS+ Tables for information on how to add, modify, or delete members of a net groups.

• NIS+ groups. An NIS+ group is a set of NIS+ users that are assigned specific access rights to NIS+ objects, usually for the purpose of administering the namespace. NIS+ group information is stored in tables located in the groups_dir directory object.

NIS+ Groups

NIS+ groups are used to assign access rights to NIS+ objects to one or more NIS+ principles. These access rights are described in Chapter 11, NIS+ Security Overview. Information about NIS+ groups is stored in tables located in the NIS+ groups_dir directory object. Information about each group is stored in a table of the same name. For example, information about the admin group is stored in admin.groups_dir.

It is recommended practice to create at least one NIS+ group called admin. The admin NIS+ group is normally used to designate those users who are to have NIS+ access rights. You can name this group anything you want, but the NIS+ manual set assumes that the group with NIS+ administrator privileges is named admin. You can also create multiple NIS+ groups with different sets of users and different sets of rights.

Always use the nisgrpadm command to work with NIS+ group membership. You can also use the nisls and nischgrp commands on the group table. Do not use the nistbladm command on the group table.

For a complete description of NIS+ group-related commands and their syntax and options, see the NIS+ man pages.

Related NIS+ Administration Commands for Groups

The nisgrpadm command performs most group administration tasks but several other commands affect groups as well,

For a complete description of these commands and their syntax, and options, see the NIS+ man pages.

Do not use the nistbladm command to work with the NIS+ groups table.

NIS+ Group Member Types

NIS+ groups can have three types of members: explicit, implicit, and recursive; and three types of nonmembers, also explicit, implicit, and recursive. These member types are used when adding or removing members of a group as described in nisgrpadm Command.

NIS+ Member Types

• Explicit. An individual principal. Identified by principal name. The name does not have to be fully qualified if entered from its default domain.

• Implicit. All the NIS+ principals who belong to an NIS+ domain. They are identified by their domain name, preceded by the * symbol and a dot. The operation you select applies to all the members in the group.

• Recursive. All the NIS+ principals that are members of another NIS+ group. They are identified by their NIS+ group name, preceded by the @ symbol. The operation you select applies to all the members in the group.

NIS+ groups also accept nonmembers in all three categories: explicit, implicit, and recursive. Nonmembers are principals specifically excluded from a group that they otherwise would be part of.

NIS+ Nonmember Types

Nonmembers are identified by a minus sign in front of their name:

• Explicit-nonmember. Identified by a minus sign in front of the principal name.

• Implicit-nonmember. Identified by a minus sign, * symbol, and dot in front of the domain name.

• Recursive nonmember. Identified by a minus sign and @ symbol in front of the group name.

NIS+ Group Syntax

The order in which inclusions and exclusions are entered does not matter. Exclusions always take precedence over inclusions. Thus, if a principal is a member of an included implicit domain and also a member of an excluded recursive group, then that principal is not included.

Thus, when using the nisgrpadm command, you can specify group members and nonmembers as shown in Table 17–2.

Using niscat With NIS+ Groups

The niscat -ocommand can be used to list the object properties and membership of an NIS+ group.

Listing the Object Properties of an NIS+ Group

To list the object properties of a group, you must have read access to the groups_dir directory in which the group is stored. Use niscat -o and the group's fully qualified name, which must include its groups_dir subdirectory:

niscat -o group-name.groups_dir.domain-name

For example:

rootmaster# niscat -o sales.groups_dir.doc.com.
Object Name : sales
Owner : rootmaster.doc.com.
Group : sales.doc.com.
Domain : groups_dir.doc.com.
Access Rights : ----rmcdr---r---
Time to Live : 1:0:0
Object Type : GROUP
Group Flags :
Group Members : rootmaster.doc.com.
  topadmin.doc.com.
  @.admin.doc.com.
  *.sales.doc.com.

A better list of members is provided by the nisgrpadm -l command.

Several of the group's properties are inherited from the NIS_DEFAULTS environment variable, unless they were overridden when the group was created. The group flags field is currently unused. In the list of group members, the * symbol identifies member domains and the @ symbol identifies member groups.

nisgrpadm Command

The nisgrpadm command creates, deletes, and performs miscellaneous administration operations on NIS+ groups. To use nisgrpadm, you must have access rights appropriate for the operation.

The nisgrpadm has two main forms, one for working with groups and one for working with group members.

To create or delete a group, or to lists its members use these forms:

nisgrpadm -c group-name.domain-name
nisgrpadm -d group-name
nisgrpadm -l group-name

To add or remove members, or determine if they belong to the group use this form (where member... can be any combination of the six membership types listed in Table 17–2):

nisgrpadm -a group-name member...
nisgrpadm -r group-name member...
nisgrpadm -t group-name member...

All operations except create (-c) accept a partially qualified group-name. However, even for the -c option, nisgrpadm does not require the use of groups_dir in the group-name argument. In fact, it won't accept it.

Creating an NIS+ Group

To create an NIS+ group, you must have create rights to the groups_dir directory of the group's domain. Use the -c option and a fully qualified group name:

nisgrpadm -c group-name.
domainname

When you create a group, an NIS+ groups table with the name you have given is created in groups_dir. You can use nisls to confirm that the new group table now exists in groups_dir, and niscat to list the groups members listed in the table.

A newly created group contains no members. See Adding Members to an NIS+ Group for information on how to specify who belongs to a group.

The example below creates three groups named admin. The first is in the doc.com. domain, the second in sales.doc.com., and the third in manf.doc.com. All three are created on the master server of their respective domains.

rootmaster# nisgrpadm -c admin.doc.com.
Group admin.doc.com. created.
salesmaster# nisgrpadm -c admin.sales.doc.com.
Group admin.sales.doc.com. created.
manfmaster# nisgrpadm -c admin.manf.doc.com.
Group admin.manf.doc.com. created.

The group you create will inherit all the object properties specified in the NIS_DEFAULTS variable; that is, its owner, owning group, access rights, time-to-live, and search path. You can view these defaults by using the nisdefaults command (described in Chapter 15, Administering NIS+ Access Rights). Used without options, it provides this output:

rootmaster# nisdefaults
Principal Name : rootmaster.doc.com.
Domain Name : doc.com.
Host Name : rootmaster.doc.com.
Group Name :
Access Rights : ----rmcdr---r---
Time to live : 12:0:0
Search Path : doc.com.

The owner is listed in the Principal Name field. The Group Name of the owning group is listed only if you have set the NIS_GROUP environment variable. For example, assuming a C-shell, to set NIS_GROUP to net_admins.doc.com:

rootmaster# setenv NIS_GROUP net_admins.doc.com

You can override any of these defaults at the time you create the group by using the -D option:

salesmaster# nisgrpadm -D group=special.sales.doc.com.-c 
admin.sales.doc.com. Group admin.sales.doc.com. created.

Deleting an NIS+ Group

To delete an NIS+ group, you must have destroy rights to the groups_dir directory in the group's domain. Use the -d option:

nisgrpadm -d group-name

If the default domain is set properly, you don't have to fully-qualify the group name. However, you should check first (use nisdefaults), because you could unintentionally delete a group in another domain. The example below deletes the test.sales.doc.com. group.

salesmaster% nisgrpadm -d test.sales.doc.com.
Group `test.sales.doc.com.' destroyed.

Adding Members to an NIS+ Group

To add members to an NIS+ group you must have modify rights to the group object. Use the -a option:

nisgrpadm -a group-name members. . .

As described in NIS+ Group Member Types, you can add principals (explicit members), domains (implicit members), and groups (recursive members). You don't have to fully qualify the name of the group or the name of the members who belong to the default domain. This example adds the NIS+ principals panza and valjean, both from the default domain, sales.doc.com., and the principal makeba, from the manf.doc.com. domain, to the group top-team.sales.doc.com.

client% nisgrpadm -a Ateam panza valjean makeba.manf.doc.com.
Added panza.sales.doc.com to group Ateam.sales.doc.com
Added valjean.sales.doc.com to group Ateam.sales.doc.com
Added makeba.manf.doc.com to group Ateam.sales.doc.com

To verify the operation, use the nisgrpadm -l option. Look for the members under the Explicit members heading.

This example adds all the NIS+ principals in the doc.com. domain to the staff.doc.com. group. It is entered from a client in the doc.com. domain. Note the * symbol and the dot in front of the domain name.

client% nisgrpadm -a Staff *.doc.com.
Added *.doc.com. to group Staff.manf.doc.com.

This example adds the NIS+ group admin.doc.com. to the admin.manf.doc.com. group. It is entered from a client of the manf.doc.com. domain. Note the @ symbol in front of the group name.

client% nisgrpadm -a admin @admin.doc.com.
Added @admin.doc.com. to group admin.manf.doc.com.

Listing the Members of an NIS+ Group

To list the members of an NIS+ group, you must have read rights to the group object. Use the -l option:

nisgrpadm -l group-name

This example lists the members of the admin.manf.doc.com. group. It is entered from a client in the manf.doc.com. group:

client% nisgrpadm -l admin 
Group entry for admin.manf.doc.com. group:
 No explicit members
 No implicit members:
 Recursive members:
 @admin.doc.com.
 No explicit nonmembers
 No implicit nonmembers
 No recursive nonmembers 

Removing Members From an NIS+ Group

To remove members from an NIS+ group, you must have modify rights to the group object. Use the -r option:

nisgrpadm -r group-name members. . .

This example removes the NIS+ principals allende and hugo.manf.doc.com. from the Ateam.sales.doc.com group. It is entered from a client in the sales.doc.com. domain:

client% nisgrpadm -r Ateam allende hugo.manf.doc.com.
Removed allende.sales.doc.com. from group Ateam.sales.doc.com.
Removed hugo.manf.doc.com. from group Ateam.sales.doc.com.

This example removes the admin.doc.com. group from the admin.manf.doc.com. group. It is entered from a client in the manf.doc.com. domain:

client% nisgrpadm -r admin @admin.doc.com.
Removed @admin.doc.com. from group admin.manf.doc.com.

Testing for Membership in an NIS+ Group

To find out whether an NIS+ principal is a member of a particular NIS+ group you must have read access to the group object. Use the -t option:

nisgrpadm -t group-name members. . .

This example tests whether the NIS+ principal topadmin belongs to the admin.doc.com. group. It is entered from a client in the doc.com. domain.

client% nisgrpadm -t admin topadmin
topadmin.doc.com. is a member of group admin.doc.com.

This example tests whether the NIS+ principal jo, from the sales.doc.com. domain, belongs to the admin.sales.doc.com. group. It is entered from a client in the doc.com. domain.

client% nisgrpadm -t admin.sales.doc.com. jo.sales.doc.com. 
jo.sales.doc.com. is a member of group admin.sales.doc.com.

Chapter 18 Administering NIS+ Directories

This chapter describes NIS+ directory objects and how to administer them.

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.

NIS+ Directories

NIS+ directory objects are used to store information related to an NIS+ domain. For each NIS+ domain, there is a corresponding NIS+ directory structure. See Chapter 2, NIS+: An Introduction, for more information about NIS+ directories.

For a complete description of NIS+ directory-related commands and their syntax and options, see the NIS+ man pages.

Using the niscat Command With NIS+ Directories

The niscat -o command can be used to list the object properties of an NIS+ directory. To use it, you must have read access to the directory object itself.

Listing the Object Properties of an NIS+ Directory

To list the object properties of a directory, use niscat -o and the directory's name:

niscat -o directory-name

For example:

rootmaster# niscat -o doc.com.
Object Name : doc
Owner : rootmaster.doc.com.
Group :
Domain : Com.
Access Rights : r---rmcdr---r---
Time to Live : 24:0:0
Object Type : DIRECTORY
.
.

Using the nisls Command With Directories

The nisls command lists the contents of an NIS+ directory. To use it, you must have read rights to the directory object.

To display in terse format, use:

nisls [-dgLmMR] directory-name

To display in verbose format, use:

nisls -l [-gm] [-dLMR] directory-name

Listing the Contents of an NIS+ Directory – Terse

To list the contents of a directory in the default short format, use one or more of the options listed below and a directory name. If you don't supply a directory name, NIS+ will use the default directory.

nisls [-dLMR] directory-name

or

nisls [-dLMR]

For example, this instance of nisls is entered from the root master server of the root domain doc.com.:

rootmaster% nisls doc.com.:
org_dir
groups_dir

Here is another example entered from the root master server:

rootmaster% nisls -R sales.doc.com.
sales.doc.com.:
org_dir
groups_dir
groups_dir.sales.doc.com.: 
admin
org_dir.sales.doc.com.:
auto_master
auto_home
bootparams
cred
.

Listing the Contents of an NIS+ Directory – Verbose

To list the contents of a directory in the verbose format, use the -l option and one or more of the options listed below. The -g and -m options modify the attributes that are displayed. If you don't supply a directory name, NIS+ will use the default directory.

nisls -l [-gm] [-dLMR] directory-name

or

nisls -l [-gm] [-dLMR]

Here is an example, entered from the master server of the root domain doc.com.:

rootmaster% nisls -l
doc.com.
D r---rmcdr---r--- rootmaster.doc.com. date org_dir
D r---rmcdr---r--- rootmaster.doc.com. date groups_dir

nismkdir Command

This section describes how to add a non-root server to an existing domain using the nismkdir command. An easier way to do this is with the nisserver script as described in Chapter 4, Configuring NIS+ With Scripts

The nismkdir command creates a non-root NIS+ directory and associates it with a master server. (To create a root directory, use the nisinit -r command, described in nisinit Command. The nismkdir command can also be used to add a replica to an existing directory.

There are several prerequisites to creating an NIS+ directory, as well as several related tasks.

To create a directory, use:

nismkdir [-m master-server] \
 directory-name

To add a replica to an existing directory, use:

nismkdir -s replica-server \
 directory-name
nismkdir -s replica-server \
 org_dir.directory-name
nismkdir -s replica-server \
 groups_dir.directory-name

Creating an NIS+ Directory

To create a directory, you must have create rights to its parent directory on the domain master server. First use the -m option to identify the master server and then the -s option to identify the replica, use:

nismkdir -m master directory
nismkdir -s replica directory

Always run nismkdir on the master server. Never run nismkdir on the replica machine. Running nismkdir on a replica creates communications problems between the master and the replica.

This example creates the sales.doc.com. directory and specifies its master server, smaster.doc.com. and its replica, rep1.doc.com.. It is entered from the root master server.

rootmaster% nismkdir -m smaster.doc.com. sales.doc.com.
rootmaster% nismkdir -m smaster.doc.com. org_dir.sales.doc.com.
rootmaster% nismkdir -m smaster.doc.com. groups_dir.sales.doc.com.
rootmaster% nismkdir -s rep1.doc.com. sales.doc.com.
rootmaster% nismkdir -s rep1.doc.com. org_dir.sales.doc.com.
rootmaster% nismkdir -s rep1.doc.com. groups_dir.sales.doc.com.

The nismkdir command allows you to use the parent directory's servers for the new directory instead of specifying its own. However, this should not be done except in the case of small networks. Here are two examples:

The first example creates the sales.doc.com. directory and associates it with its parent directory's master and replica servers.

rootmaster% nismkdir sales.doc.com

The second example creates the sales.doc.com. directory and specifies its own master server, smaster.doc.com.

rootmaster% nismkdir -m smaster.doc.com. sales.doc.com.

Since no replica server is specified, the new directory will have only a master server until you use nismkdir again to assign it a replica. If the sales.doc.com. domain already existed, the nismkdir command as shown above would have made salesmaster.doc.com. its new master server and would have relegated its old master server to a replica.

Adding an NIS+ Replica to an Existing Directory

This section describes how to add a replica server to an existing system using the nismkdir command. An easier way to do this is with the nisserver script.

Keep in mind the following principles:

• Root domain servers reside in (are part of) the root domain.

• Subdomain servers reside in (are part of) the parent domain immediately above the subdomain in the hierarchy. For example, if a namespace has one root domain named prime and a subdomain named sub1:

  • The master and replica servers that serve the prime domain are themselves part of the prime domain because prime is the root domain.

  • The master and replica servers that serve the sub1 subdomain are also part of the prime domain because prime is the parent of sub1.

• While it is possible for a master or replica server to serve more than one domain, doing so is not recommended.

To assign a new replica server to an existing directory, use nismkdir on the master server with the -s option and the name of the existing directory, org_dir, and groups_dir:

nismkdir -s replica-server existing-directory-name
nismkdir -s replica-server org_dir. existing-directory-name
nismkdir -s replica-server groups_dir. existing-directory-name

The nismkdir command realizes that the directory already exists, so it does not recreate it. It only assigns it the additional replica. Here is an example with rep1 being the name of the new replica machine:

rootmaster% nismkdir -s rep1.doc.com. doc.com.
rootmaster% nismkdir -s rep1.doc.com. org_dir.doc.com.
rootmaster% nismkdir -s rep1.doc.com. groups_dir.doc.com.

Always run nismkdir on the master server. Never run nismkdir on the replica machine. Running nismkdir on a replica creates communications problems between the master and the replica.

After running the three iterations of nismkdir as shown above, you need to run nisping from the master server on the three directories:

rootmaster# nisping doc.com.
rootmaster# nisping org_dir.doc.com.
rootmaster# nisping group_dir.doc.com.

You should see results similar to these:

rootmaster# nisping doc.com.
Pinging replicas serving directory doc.com. :
Master server is rootmaster.doc.com.
 Last update occurred at Wed Nov 18 19:54:38 1995
Replica server is rep1.doc.com.
 Last update seen was Wed Nov 18 11:24:32 1995
 Pinging ... rep1.doc.com

It is good practice to include nisping commands for each of these three directories in the master server's cron file so that each directory is “pinged” at least once every 24 hours after being updated.

nisrmdir Command

The nisrmdir command can remove a directory or simply dissociate a replica server from a directory. (When a directory is removed or disassociated from a replica server, that machine no longer functions as an NIS+ replica server for that NIS+ domain.)

When it removes a directory, NIS+ first disassociates the master and replica servers from the directory, and then removes the directory.

• To remove the directory, you must have destroy rights to its parent directory.

• To dissociate a replica server from a directory, you must have modify rights to the directory.

If problems occur, see Removal or Dissociation of NIS+ Directory From Replica Fails.

Removing an NIS+ Directory

To remove an entire directory and dissociate its master and replica servers, use the nisrmdir command without any options:

nisrmdir directory-name
nisping domain

This example removes the manf.doc.com. directory from beneath the doc.com. directory:

rootmaster% nisrmdir manf.doc.com.
rootmaster% nisping doc.com.

Disassociating a Replica From an NIS+ Directory

To disassociate a replica server from a directory, you must first remove the directory's org_dir and groups_dir subdirectories. To do this, use the nisrmdir command with the -s option. After each of the subdirectories are removed, you must run nisping on parent domain.

nisrmdir -s replicanameorg_dir.domain
nisrmdir -s replicanamegroups_dir.domain
nisrmdir -s replicaname domain
nisping domain

This example disassociates the manfreplica1 server from the manf.doc.com. directory:

rootmaster% nisrmdir -s manfreplica1 org_dir.manf.doc.com.
rootmaster% nisrmdir -s manfreplica1 groups_dir.manf.doc.com.
rootmaster% nisrmdir -s manfreplica1 manf.doc.com.
rootmaster% nisping manf.doc.com.

If the replica server you are trying to dissociate is down or out of communication, the nisrmdir -s command returns a Cannot remove replicaname: attempt to remove a non-empty table error message. In such cases, you can run nisrmdir -f -s replicaname on the master to force the dissociation. Note, however, that if you use nisrmdir -f -s to dissociate an out-of-communication replica, you must run nisrmdir -f -s again as soon as the replica is back on line in order to clean up the replica's /var/nis file system. If you fail to rerun nisrmdir -f -s replicaname when the replica is back in service, the old out-of-date information left on the replica could cause problems.

nisrm Command

The nisrm command is similar to the standard rm system command. It removes any NIS+ object from the namespace, except directories and nonempty tables. To use the nisrm command, you must have destroy rights to the object. However, if you don't, you can use the -f option, which tries to force the operation in spite of permissions.

You can remove group objects with the nisgrpadm -d command (see Deleting an NIS+ Group), and you can empty tables with nistbladm -r or nistbladm -R (see Deleting an NIS+ Table).

To remove a nondirectory object, use:

nisrm [-if] object-name

Removing NIS+ Nondirectory Objects

To remove nondirectory objects, use the nisrm command and provide the object names:

nisrm object-name...

This example removes a group and a table from the namespace:

rootmaster% nisrm -i admins.doc.com. groups.org_dir.doc.com.
Remove admins.doc.com.? y
Remove groups.org_dir.doc.com.? y

rpc.nisd Daemon