Home > Articles > Operating Systems, Server > Solaris

This chapter is from the book

How NIS+ Clients Bind to the NIS+ Server

Unlike NIS, which does not authenticate its clients, NIS+ implements the notion of credentials. Two types of credentials exist in the NIS+ world:

  • User credentials
  • Workstation credentials

The process of creating credentials is quite complex and is beyond the scope of this book. Essentially, the process creates a private/public key pair and stores it in a secure area. During authentication only the public key is passed between the sender and the receiver. Data encrypted with one's private key can be decrypted with one's public key.

Unlike NIS client requests, NIS+ servers perform authentication to see who is sending the request, then authorize that user to perform specific types of access such as read, write, or modify. To gain access to the NIS+ tables, users must provide their credentials, that is in the form of UID@domainname. The exchange of credentials is protected by public and private key encryption. If the user is logged in as root, then additional credentials that identify the workstation must also be provided.

FIGURE 2-7 summarizes the NIS+ security process.

FIGURE 2-7 NIS+ Security Process

As shown in FIGURE 2-7, the following steps take place:

  1. The client sends a request for access to the namespace along with its credentials.

  2. The server authenticates the client's request by examining the sender's credentials.

  3. The server examines the object's definition to determine access rights granted to the sender, or principal, as it is called.

  4. The server then determines the class of principal: Owner, Group, World, or Nobody.

  5. The server determines access rights granted to the principal's class.

  6. If the access rights granted to the principal's class match the type of operation, the operation is performed.

  • + Share This
  • 🔖 Save To Your Account