JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
System Administration Guide: Naming and Directory Services (NIS+)
search filter icon
search icon

Document Information


Part I About Naming and Directory Services

1.  Name Service Switch

Part II NIS+ Setup and Configuration

2.  NIS+: An Introduction

3.  NIS+ Setup Scripts

4.  Configuring NIS+ With Scripts

5.  Setting Up the NIS+ Root Domain

6.  Configuring NIS+ Clients

7.  Configuring NIS+ Servers

8.  Configuring an NIS+ Non-Root Domain

9.  Setting Up NIS+ Tables

Part III NIS+ Administration

10.  NIS+ Tables and Information

11.  NIS+ Security Overview

12.  Administering NIS+ Credentials

NIS+ Credentials

How NIS+ Credentials Work

NIS+ Credentials and Credential Information

NIS+ Authentication Components

How NIS+ Principals Are Authenticated

NIS+ Credentials Preparation Phase

NIS+ Login Phase - Detailed Description

NIS+ Request Phase - Detailed Description

DES Credential in NIS+

DES Credential Secure RPC Netname

DES Credential Verification Field in NIS+

How the DES Credential in NIS+ Is Generated

Secure RPC Passwords and the Login Password Problem in NIS+

Cached Public Keys Problems in NIS+

Where Credential-Related Information Is Stored in NIS+

NIS+ cred Table in Detail

Creating NIS+ Credential Information

nisaddcred Command

NIS+ Credential-Related Commands

How nisaddcred Creates NIS+ Credential Information

LOCAL NIS+ Credential Information

DES Credential Information in NIS+

Secure RPC Netname and NIS+ Principal Name

Creating NIS+ Credential Information for the Administrator

Creating Credential Information for NIS+ Principals

For NIS+ User Principals - Example

Using a Dummy Password and chkey in NIS+ - Example

Creating Credential Information in Another NIS+ Domain - Example

For NIS+ Machines - Example

Administering NIS+ Credential Information

Updating Your Own NIS+ Credential Information

Removing NIS+ Credential Information

13.  Administering NIS+ Keys

14.  Administering Enhanced NIS+ Security Credentials

15.  Administering NIS+ Access Rights

16.  Administering NIS+ Passwords

17.  Administering NIS+ Groups

18.  Administering NIS+ Directories

19.  Administering NIS+ Tables

20.  NIS+ Server Use Customization

21.  NIS+ Backup and Restore

22.  Removing NIS+

23.  Information in NIS+ Tables

24.  NIS+ Troubleshooting

A.  NIS+ Error Messages

About NIS+ Error Messages

Common NIS+ Namespace Error Messages

B.  Updates to NIS+ During the Solaris 10 Release

Solaris 10 and NIS+



How NIS+ Credentials Work

Note - 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.


Caution - 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.

NIS+ Authentication Components

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

How NIS+ Principals Are Authenticated

There are three phases to the authorization process:

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:

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.