Example of Complete Removal of NIS from the Enterprise
An organization wants to completely remove NIS from their environment in a phased approach. An analysis is need of how each NIS domain across the enterprise is currently running. Users can be migrated either before, during or after NIS clients are joined to the domain. In all cases, authentication migration can be performed separately or at the same time as the standard NIS map migration and finally not used. Here are the major migration milestones to remove NIS from the enterprise:
Phase 1. Analyze Existing NIS domains
- Are there secure connections between the NIS clients and NIS server?
- Is it an isolated network?
- Is a test environment available and can it just be de-commissioned?
- What applications have custom maps?
- Are there network appliances that use NIS authentication?
- Does the network appliance support Kerberos?
- Does the network appliance support LDAP with a starting base DN?
- Does the network appliance support Active Directory authentication?
- What are the costs for replacing legacy network appliances?
Phase 2. Migrate the Users to Use their Active Directory Credentials
- Create a DirectControl Zone in Active Directory with the same name as the NIS domain.
- Install the DirectControl Agent on all the NIS clients where possible.
- Join the NIS clients to Active Directory and add them to the DirectControl Zone.
- Import the users and groups and standard NIS maps into Active Directory using the DirectControl Administrator Console.
- Install the DirectControl Agent on the NIS servers.
- Join the NIS servers to Active Directory and add them to the DirectControl Zone.
- Schedule down time, and stop the legacy NIS servers.
- Install and start the DirectControl Network Information Service (adnisd) on the NIS servers.
Phase 3. Replace Standard NIS Maps
- Use Centrify scripts to decommission automount map.
- Replace the netgroups map.
- Create Active Directory groups to manage pam/allow and pam/deny settings.
- Create DirectControl Zones and add machines and users to them.
- Set up any Active Directory groups needed as filters for access to different groups of computers in another DirectControl Zone. (DirectControl provides tools such as its ZoneGen utility to help with this task.)
- Decommission legacy maps such as rpc, services, and netid.
Phase 4. Decommission Custom NIS Maps
- Modify or re-write applications that use legacy NIS data to use a standard LDAP interface to retrieve the information from Active Directory.
- Modify or re-write applications that use legacy NIS data to use a database or other technologies based upon the application.
Phase 5. Remove NIS Servers
- If all maps can be removed then NIS servers are no longer used.
- If standard maps cannot be eliminated, another alternative is to use DirectControl's Group Policy.
- Add the needed maps to Active Directory sysvol and then use the DirectControl Group Policy feature to copy those files to the machines that require the maps.
- Make sure that NSS switch has files specified and remove nis.
NIS servers can be removed earlier depending on what maps an organization is using. It can vary from one NIS domain to another within an organization. Like any migration. it takes time and careful planning, but it is possible to accomplish the removal of NIS.
These recommendations also work for NIS+ where possible. If the NIS+ domain can run in NIS compatibility mode, then the DirectControl Network Information Service can be used as part of the migration. If the NIS+ domain cannot be in NIS compatibility mode, then using Active Directory groups, along with DirectControl Zone technology and DirectControl utilities, a migration can be performed using the steps mentioned in the general guidelines of this white paper.
In summary, Centrify provides product, process, and tools to help customers perform NIS migrations according to their requirements.