- Evolution of Solaris Naming Services
- NIS and Files Coexistence
- NIS and DNS Coexistence
- Solaris Naming Service Switch
- Solaris Naming Service Switch Architecture
- NIS Architecture Overview
- NIS Client Server Architecture
- How NIS Clients Bind to the NIS Server
- NIS Maps
- NIS High Availability Architecture Features
- NIS+ Architecture Overview
- NIS+ Client Server Architecture
- How NIS+ Clients Bind to the NIS+ Server
- NIS+ Tables
- NIS+ Interaction with DNS
- NIS+ High Availability Architecture Features
- Solaris DNS Architecture Overview
- DNS Client Architecture
- DNS Server Architecture
- DNS High Availability Features
- LDAP Architecture Overview
- LDAP Information Model
- LDAP Naming Model
- LDAP Functional Model
- LDAP Security Model
- LDAP Replication
- Comparison with Legacy Naming Services
This chapter is from the book
This chapter is from the book
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.
){kind=link}
FIGURE 2-7 NIS+ Security Process
As shown in FIGURE 2-7, the following steps take place:
The client sends a request for access to the namespace along with its credentials.
The server authenticates the client's request by examining the sender's credentials.
The server examines the object's definition to determine access rights granted to the sender, or principal, as it is called.
The server then determines the class of principal: Owner, Group, World, or Nobody.
The server determines access rights granted to the principal's class.
If the access rights granted to the principal's class match the type of operation, the operation is performed.