Migration Example: NIS to Active Directory
Given the inherent security limitations in NIS and the fact that the technology has been effectively end-of-lifed, many organizations are looking to migrate away from NIS to a modern LDAP directory. The following example discusses how to migrate from NIS to Microsoft Active Directory leveraging Centrify DirectControl and goes into specific migration approaches.
How the Centrify NIS Solution Works in a NIS Environment
Replacing NIS with a combination of Active Directory and Centrify DirectControl is an excellent choice because many of the key features that IT managers are looking for are included with Active Directory and the Centrify DirectControl Agent. Centrify makes it easy to migrate a legacy NIS-based infrastructure to a modern LDAP- and Kerberos-based directory infrastructure that works across a heterogeneous environment comprised of Windows, Unix, Linux and Mac systems. In addition, the security risks are greatly reduced when the legacy NIS environment is replaced with Active Directory as the central repository of identity information and the Centrify DirectControl Agent (adclient) serves as the "client" requesting information.
Active Directory and Centrify DirectControl provide more secure authentication, authorization, and directory services than NIS by using the existing features in Active Directory and using Centrify DirectControl Zone technology for authorization and the DirectControl Agent for authentication. Once a machine is joined to an Active Directory domain and placed in a DirectControl Zone, the Unix machine Name Service Switch configuration file, nsswitch.conf (AIX has a similar feature), is modified so that account lookup requests are passed to Active Directory through the Centrify DirectControl Agent, effectively bypassing the NIS client and server environment for password authentications.
It may not be possible to completely replace NIS, or in large organizations there may be many NIS domains that require a phased approach. The following should be considered in any NIS migration of any size:
- Legacy NIS Servers. It may be necessary to keep a legacy NIS server that is configured with network information, such as netgroup or automount maps, to make available in response to client requests initially during a migration.
- Applications. Some applications may require access to a NIS server because they send requests directly to the NIS port and expect a NIS process to be listening there.
- Network Attached Storage Devices and Legacy Systems. Devices such as Network Attached Storage devices or computers with older operating systems for which there is no DirectControl Agent may also need access to information normally stored in NIS maps. Those devices or computers cannot join an Active Directory domain, but are capable of submitting NIS client requests. In these cases, a NIS server may be the only option for providing authentication and look-up services.
Using the Centrify DirectControl Network Information Service
Computers, devices, or applications that require access to a NIS server, on either an ongoing or temporary basis, can use the Centrify DirectControl Network Information Service to replace existing NIS servers.
To support computers and applications that are capable of submitting NIS client requests to a NIS server, DirectControl provides its own Network Information Service server. The DirectControl Network Information Service (adnisd) is an optional addition to the Centrify DirectControl Agent and can be installed on one or more DirectControl-managed computers as needed.
Once installed and running, the DirectControl Network Information Service functions like a standard NIS server, but it responds to NIS client requests using the information stored in Active Directory, including any information imported from passwd and group NIS maps or from /etc/passwd and /etc/group files. When the NIS client is remote from the DirectControl Network Information Service, it has some of same security limitations as a standard NIS server, but it provides encrypted authentication and directory service to computers where the Centrify DirectControl Agent cannot be installed.
The DirectControl Network Information Service is very useful in environments where a phased migration is planned from existing NIS servers and clients or when the environment includes legacy systems that cannot migrate or upgrade to support the DirectControl Agent. The figure below shows how the DirectControl Network Information Service works when the NIS client is a remote machine.
The DirectControl NIS Architecture. The DirectControl-managed NIS client requests information from the DirectControl Network Information Service running within its Zone. The DirectControl Network Information Service retrieves the information from its local cache and returns it to the client. Periodically, the DirectControl Network Information Service sends a request to Active Directory for updated NIS maps for the DirectControl Zone to which it belongs.
All user and group information is either found in cache or sent over encrypted LDAP connections, and user authentication is handled by Kerberos. The end result is that Unix authentication leverages Active Directory. This allows NIS password hashes to be replaced with protected Kerberos authentication in a phased approach.
The DirectControl Network Information Service cannot be used with any legacy NIS servers in the same NIS domain. It can be used only in conjunction with Active Directory and the DirectControl-managed systems. The legacy server expects other servers to be either a master or a slave. The DirectControl Network Information Service does not support master-slave legacy NIS servers.
Understanding the Servicing of NIS Client Requests
Together, the DirectControl Agent and DirectControl Network Information Services perform the role of a legacy NIS server and gateway for data stored in Active Directory. The NIS clients on the network communicate with the DirectControl Network Information Service using Remote Procedure Calls (RPC) sent to the NIS port on the DirectControl-managed computer. The DirectControl Agent is responsible for all communication with Active Directory and maintains its own separate cache of data from which the DirectControl Network Information Service can derive the user and group information for the DirectControl Zone.
When the DirectControl Network Information Service receives a request from the NIS client, it checks its local cache of map data and then responds to the client that made the request.
The local cache of map data is generated from the map data the DirectControl Network Information Service receives from Active Directory. Within the local cache, there are two types of maps:
- Explicitly-defined maps are NIS maps imported into Active Directory from an existing NIS domain or from text files, or created manually using the DirectControl Administrator Console.
- Derived maps are maps that are automatically generated from information stored in Active Directory. Derived maps access the same data 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.
Periodically, the DirectControl Network Information Service connects to Active Directory to locate updates to explicitly defined NIS maps. It then synchronizes its 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 DirectControl Network Information Service retrieves all users and groups in the current Zone from adclient, and generates the derived maps for user and group information.
The DirectControl Network Information Service also generates derived maps for explicitly defined maps when possible. If the DirectControl Network Information Service finds a NIS map defined in Active Directory with a name it recognizes as a common map name, such as netgroup or service, it automatically derives related maps; for example, the netgroup.byhost and netgroup.byuser for the netgroup map or services.byname and services.byservicename for the services map.
The DirectControl Network Information Service stores all of the explicitly defined and derived maps in its own local cache of map data (in most cases, /var/centrifydc/nis/*). Because the DirectControl Network Information Service always responds to NIS client requests using the data in its local cache, it can respond even when Active Directory is not available.
Importing and Creating Additional NIS Maps
Using the Centrify DirectControl administrator console, NIS maps can be imported from legacy NIS servers or new network maps can be created. Network information can be imported from standard NIS maps, such as automount, automaster, and netgroup databases.
In addition to the user and group information, the DirectControl Network Information Service can be used to service NIS client requests for network information or to make information from custom maps available.
Custom maps can be created as key/value pairs stored in a DirectControl Zone in Active Directory. The passwd.* and group.* maps are derived automatically from the information stored in Active Directory for the Zone. Therefore, these derived maps include account information for any passwd and group NIS maps or configuration files that have been imported and migrated to Active Directory using the Import from Unix wizard in the DirectControl Administrator Console.
Importing Network Information from Existing NIS Maps
The DirectControl Administrator Console's import wizard can be used to import network information from standard NIS maps such as automount, netgroup, and automaster into the DirectControl Zone that will serve the NIS map data. There are also options to connect directly to the NIS server and domain directly or to import the information from a text file.
Creating New Network NIS Maps in Active Directory
If the maps cannot be imported from existing NIS maps, then new maps can be created by adding the appropriate information directly to Active Directory using the DirectControl Administrator Console. Once the information is added to Active Directory, the DirectControl Network Information Service will read the maps from Active Directory and store them in its local cache and make the information available to NIS clients. This can also be used to create netgroup, automaster, and automount network maps.
Creating Generic Custom Maps
Generic maps can be created and published for any type of custom information that needs to be made available to NIS clients. Generic custom maps consist of a simple key/value format and optional comments. Generic maps can also be used to manually create standard NIS maps that consist of key/value pairs.
Maintaining Map Records in Active Directory
Once NIS maps are stored in Active Directory, they must be maintained to ensure the changes in the records in Active Directory are reflected in the local map cache that the Centrify DirectControl Network Information Service uses to respond to NIS client queries. The DirectControl Administrator Console can be used to manually add, edit, or delete individual map records for any map. The specific fields available in each record, and which fields are required and which are optional, depend on the type of map this is being edited. For example, the fields in an auto.master map entry are different from the fields in a netgroup map entry.
Managing Automounts without Using NIS
Automount information stored in Active Directory can be accessed through the DirectControl Network Information Service or directly through an LDAP request that bypasses the DirectControl Network Information Service.
Centrify has an alternative to using the DirectControl Network Information Service, with an optional adauto.pl script to get automount data (the script is located in the /usr/share/centrifydc/etc directory). The adauto.pl script gets mount point information directly from Active Directory using LDAP. With the adauto.pl script, the automount of the home directories will be performed by using the information from NIS maps without requesting them from the DirectControl Network Information Service.
The adauto.pl script uses the information stored in the auto.home NIS map for the DirectControl Zone the local computer is a member of. After the script is added to the automount configuration, the automounter program invokes the script and passes it the user name of the user logging on. The adauto.pl script then uses the ldapsearch command to retrieve the mount point information from Active Directory and returns the path to the remote home directory for the user logging on. The automounter will then attempt to connect to that home directory.
Discontinuing Use of Legacy NIS Servers
Once the NIS maps are stored in Active Directory, incremental updates of the NIS data stored in Active Directory can be done by using the DirectControl Administrator Console. Updates made are then propagated to all of the DirectControl Network Information Service servers automatically.
For each NIS domain, the DirectControl Network Information Service deployed across the enterprise replaces the legacy NIS servers without changing NIS client configurations to complete the migration to Active Directory for secure, centralized directory service.
Migrating NIS Clients
If the DirectControl Agent can be installed on the NIS client machine, a secure authentication will take place directly through Active Directory, and NIS maps will be requested and loaded using the DirectControl Network Information Service.