How NIS client requests are processed

If you have decided to maintain a NIS environment, on either an ongoing or temporary basis, you can use the Centrify Network Information Service to replace existing NIS servers and the Access Manager console to migrate NIS map data to Active Directory.

The Centrify Network Information Service (adnisd) can run on any computer that has the adclient agent service installed. Computers that need access to the information stored in Active Directory can then be configured as NIS clients that send their NIS queries to the computer where both the adclient and adnisd service run.

When adnisd receives a request from the NIS client, it checks its local cache of map data, then responds to the client that made the request. The local cache of map data is generated from the map data adnisd receives from Active Directory.

The following figure provides a simplified view of operation.

Explicitly-defined and derived maps

Within the local cache, there are two types of maps: explicitly-defined maps and derived maps. Explicitly-defined maps are NIS maps imported into Active Directory from an existing NIS domain, imported from text files, or created manually using the Centrify Access Manager console. Derived maps are maps that are automatically generated from the information stored in Active Directory. Derived maps access the same data as the explicitly-defined maps using different keys. For example, the user and group maps in the local cache are not retrieved directly from Active Directory, but are generated based on the users and groups that have been enabled for the local computer’s zone.

The maps derived from the zone information are passwd.byname, passwd.byuid, group.byname, and group.bygid. These automatically generated maps are placed in the local cache, and can then be used to look up or authenticate users by user name or by UID value, and groups by group name or by GID value. The Centrify Network Information Service also generates derived maps for explicitly-defined network maps that are stored in Active Directory. If adnisd finds a NIS map defined in Active Directory with a name it recognizes, such as netgroup or services, it automatically derives related maps. For example, a netgroup map will automatically generate the netgroup.byhost and netgroup.byuser maps. A services base map will generate the services.byname and services.byservicename maps.

Accessing NIS maps in the local cache

Periodically, the adnisd process connects to Active Directory through the adclient process to locate updates to explicitly-defined NIS maps. It then synchronizes the local cache of NIS map data to mirror any changes detected in Active Directory. After polling Active Directory for updates to explicitly-defined maps, the adnisd process retrieves all users and groups in the current zone from adclient, and generates the derived maps for user and group information.

In essence, the computer where both adclient and adnisd run acts as the NIS server for the local computer’s zone. The NIS clients on the network communicate with adnisd using Remote Procedure Calls (RPC) sent to the NIS port on the Centrify-managed computer. The adclient process is responsible for all communication with Active Directory and maintains its own separate cache of data from which adnisd can derive the user and group information for the zone. The adnisd process then stores all of the explicitly-defined and derived maps in its own local cache of map data (in most cases, /var/centrifydc/nis/*). Because adnisd always responds to NIS client requests using the data in its local cache, it can respond even when Active Directory is not available.

The following figure provides a simplified summary of operation.

Note:   The adnisd process cannot be used with any legacy NIS servers in a NIS domain. It can only be used in conjunction with Active Directory and the Centrify UNIX agent.