Centrify's Solution for NIS Migration

Transcription

1 WHITE PAPER CENTRIFY CORP. Centrify's Solution for NIS Migration APRIL 2008 Leveraging Centrify s DirectControl and Zone Technology to Simplify NIS Migration ABSTRACT Sun Microsystem s Network Information Service (NIS, originally known as Sun Yellow Pages) has been the primary choice for managing Unix identity information in a networked environment for many years. Unfortunately, NIS has several shortcomings in the areas of security, manageability, and network dependency, and its successor, NIS+, was never widely accepted as a standard. Increasingly, NIS has proven unable to pass stringent security guidelines for user account management and access control, both from a simple IT best practices perspective and from a regulatory compliance perspective. This fact, combined with Sun's end-of-life announcement for NIS and NIS+, has prompted corporate security and compliance managers and IT administrators to look for a solution to replace NIS with a solution that is secure, manageable, and cost-effective. This white paper examines the challenges of migrating NIS deployments to a central repository, and explains in detail how a combination of Microsoft Active Directory and Centrify DirectControl can deliver a cost-effective solution that strengthens security while improving IT efficiency.

2 Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Centrify Corporation. Centrify may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Centrify, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property Centrify Corporation. All rights reserved. Centrify and DirectControl are trademarks of Centrify Corporation in the United States and/or other countries. Microsoft, Active Directory, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. [WP ] 2008 CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE II

3 Contents 1 Introduction About Network Information Service Limitations of NIS Alternatives to NIS How the Centrify NIS Solution Works in a NIS Environment Using the Centrify DirectControl Network Information Service Understanding the Servicing of NIS Client Requests Importing and Creating Additional NIS Maps Importing Network Information from Existing NIS Maps Creating New Network NIS Maps in Active Directory Creating Generic Custom Maps Maintaining Map Records in Active Directory Managing Automounts without Using NIS Discontinuing Use of Legacy NIS Servers Migrating NIS Clients Migration Approaches Example of Using NIS Clients with DirectControl Agents Example of Migrating Users Gradually Example of Complete Removal of NIS from the Enterprise How to Contact Centrify CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE III

4 1 Introduction Most CIOs and IT managers will say that security is the number one issue they have to deal with in keeping their company s IT systems running smoothly. Security is a broad term that applies to computing systems, people, applications, data, physical access and policies virtually every aspect of modern computing. In prioritizing their efforts, many IT managers are first concentrating on getting control over systems and people. As a recent Goldman Sachs security survey of IT managers at Fortune 1000 organizations found, Identity and Access Management is a top priority for spending. "As Identity and Access Management (IAM) solutions help limit the number of individuals who have access to sensitive materials as well as recording who accessed what, it is not surprising to see IAM solutions scoring highly in our survey for the third time running, with 78% of respondents expecting to increase spending in the area over the next 12 months." The survey reflects the fact that achieving a consistent, repeatable regimen for managing user accounts and controlling access to systems remains an unsolved challenge for many IT managers. Most organizations have deployed a variety of operating system platforms, each with its own methods of storing user account information and of using that information for authentication, authorization, accounting, and access control purposes. One of the most common and pressing security issues that IT managers have been forced to address in recent years is the Network Information Services (NIS) infrastructure that they have relied upon to manage their Unix and Linux environments. Unfortunately, NIS has proven unable to pass stringent guidelines for user account management and access control, both from a simple IT best practices perspective and from a regulatory compliance perspective. As IT managers build a strategy for replacing NIS, their first requirement is frequently to migrate the user account information held in NIS into a single, centralized repository. The benefits of a centralized repository are easily understood because they address not only security concerns but also the corresponding need to control expenses by simplifying IT infrastructure and streamlining IT operations. For a good overview of the benefits of adopting a single repository, see the Centrify white paper Centrify's Solution For Migrating Unix Directories To Active Directory. This white paper examines the challenges of migrating NIS deployments to a central repository, and explains in detail how a combination of Microsoft Active Directory and Centrify DirectControl can deliver a cost-effective solution that strengthens security while improving IT efficiency. 2 About Network Information Service This section provides some background on NIS for those who are unfamiliar with NIS or who want to learn more about how NIS works. This section is not comprehensive, but explains key concepts and definitions used in this white paper CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE 1

5 Network Information Service (NIS), originally called Yellow Pages (YP), provides centralized storage and distribution of information that needs to be known throughout the network. The information accessed is stored in files called maps. NIS has a master-slave architecture: data can be updated only in a central, master server, where all maps are maintained. Slaves can handle client requests for map access, but the slaves can make no changes to the maps. Changes are made only at the master server, and then distributed through the master NIS server to the slaves. NIS is implemented through several daemons that handle NIS requests: ypserv on the server side, and ypbind on the client side. Updated maps can be transferred to NIS slaves either manually (using yppush) or automatically through ypxfrd (NIS slaves check timestamps on the master and update their maps as needed). In a typical NIS environment, the NIS server is used to centrally manage a set of database maps that correspond to the system configuration files that are commonly found on Unix systems such as the /etc/passwd, /etc/group, secret authentication hashes in /etc/shadow, /etc/hosts, and /etc/services files for a set of computers that make up a NIS domain. Each NIS map corresponds to a specific configuration file, such as the /etc/passwd or /etc/hosts file, and consists of a set of keys and values, and a version number for the data. When computers on the network require information stored in NIS maps, they send a NIS client request to query for the information. Each client computer that needs access to the information in the NIS database maps runs the ypbind process to identify and connect to the NIS server best suited to respond to its request. When the NIS server receives a request, it replies with the appropriate information from its set of NIS maps. Defining netgroups allows an enterprise to restrict access to hosts, NFS access and administrators by checking permissions when processing requests for remote mounts, remote logins, and remote shells in a NIS domain. The main database for netgroups is stored on the NIS master server in the /etc/netgroup file. For remote mounts, the information in netgroup is used to classify machines; for remote logins and remote shells, it is used to classify users. NIS clients can use netgroups to include the map entries for the members of a netgroup in the password file, /etc/passwd. The automount map, called auto.master, is typically used to share home directories on a NFS file share. The automount daemon reads the auto.master map to find out which directory to mount either at login or when a file is touched in the directory. A script can be used instead to mount a directory instead of what should be mapped. Communication between NIS servers and clients is based on the Remote Procedure Call (RPC) protocol, which uses the External Data Representation (XDR) standard and Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE 2

6 2.1 Limitations of NIS Although NIS can be very efficient in responding to queries for network information, it is not a secure mechanism for providing authentication and authorization services. For example: If NIS clients use the broadcast service to locate NIS servers on the network, intruders can easily introduce their own NIS server with their own privileged accounts. Once a client binds to the rogue NIS server, the intruder can gain access to that client and perform unauthorized operations. The NIS server s only security policy is the securenets setting. The securenets setting identifies which NIS clients to accept queries from. If an intruder impersonates a client that the securenets setting allows the NIS server to accept, he can download all of the NIS data. Even if an intruder fails the securenets test, he could potentially inspect all of the NIS requests and decode the data to gain access. Netgroups are not effective when they are used for transparent access across the network utilizing rlogin and rsh. Syntax errors in /etc/netgroup files (,,) will allow all users and machines trusted access. If NIS is used for authentication, password hashes are sent around the network in clear text and can be easily captured and cracked, making client systems vulnerable. NIS performs no authentication at the RPC level; any machine on any network could easily create a fake RPC reply simply by pretending to be the NIS server 2.2 Alternatives to NIS Sun's end-of-life announcement for NIS and NIS+ support, and the recommendation to use LDAP, have given system administrators a need to deploy new network services or leverage existing directory deployments. As a recent Linux.com article observed: Sun is pushing LDAP as the replacement, but no two LDAP clients are implemented the same way. Sun doesn t talk to an LDAP server like a Linux machine does, or an AIX or HP- UX machine does for that matter. Every one of these platforms has one issue or another. For Linux, nobody appears to have written the client-side code to properly handle netgroups for all the things you might use netgroups for. For Sun, there's no start_tls implementation. NetApp just barely knows what LDAP is. Some within the Unix community believe that migrating to an LDAP server such as OpenLDAP, IBM SecureWay, Novell's edirectory, or Sun's SunONE directory server is the way to go. Many organizations favor using Microsoft s Active Directory and Group Policy system, which has been an integral part of Windows since the release of Windows 2000 Server. Active Directory is typically already deployed for managing Windows systems and users, and organizations have already invested considerable time and resources to set up a secure and robust domain controller infrastructure, and to create IT workflow and provisioning systems to manage user accounts. Thus, many organizations 2008 CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE 3

7 are turning to Active Directory as the logical and cost-effective directory from which to manage more of their enterprise. 3 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 Kerberosbased 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 CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE 4

8 3.1 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 DirectControlmanaged computers as needed. It 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. DirectControl Zone DirectControl-Managed NIS Clients NIS Cache Microsoft Active Directory DirectControl-Managed Server w/ DirectControl Network Information Service 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. 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 also a DirectControl-managed system, a secure directory service is provided through authenticated and encrypted connections between Active Directory and the DirectControl Network Information Service, and from the DirectControl Network Information Service to the NIS clients. When the NIS client is not managed by DirectControl (for example, on legacy systems not supported by DirectControl or during a phased migrations), it has 2008 CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE 5

9 some of the same security limitations as a standard NIS environment, with an authenticated and encrypted connection only between Active Directory and the DirectControl Network Information Service. All user and group information is either found in cache or retrieved 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. 3.2 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 2008 CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE 6

10 name or by GID value. By default, the password hash in the passwd map is not populated because DirectControl does not need it for authentication. 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. 3.3 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 2008 CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE 7

11 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 CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE 8

12 3.3.5 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. 3.4 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. 3.5 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. 4 Migration Approaches There are multiple ways of approaching an existing NIS environment using the Centrify NIS migration features of DirectControl and the DirectControl Network Information Service. Customers have implemented NIS in many ways within their own organization to use some or all of the features of NIS CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE 9

13 4.1 Example of Using NIS Clients with DirectControl Agents An organization has an existing NIS environment, and wants to do authentication with Active Directory and keep standard NIS maps and custom maps used by an in-house application on NIS. A simple approach is to install the Agents on the NIS clients for authentication to Active Directory and use the DirectControl Network Information Service to serve the maps. The following steps can be performed: 1. Create a DirectControl Zone in Active Directory with the same name as the NIS domain. 2. Install the Centrify DirectControl Agent on all NIS client machines. 3. Join each NIS client machine to Active Directory and add them to the DirectControl Zone. 4. Import all the users and groups into Active Directory using the DirectControl Administrator Console. 5. Import all NIS maps into the Active Directory using the DirectControl Administrator Console. 6. Schedule down time, and stop the legacy NIS servers. 7. Install the DirectControl Agent on the NIS servers. 8. Join the NIS servers to the Active Directory domain and add them to the DirectControl Zone. 9. Install and start the DirectControl Network Information Service (adnisd) on the NIS servers. All users will use their Active Directory credentials to authenticate to Active Directory, but get maps from the DirectControl Network Information Service via normal NIS requests. All user accounts are managed in Active Directory. 4.2 Example of Migrating Users Gradually An organization with an existing NIS environment wants to do authentication with Active Directory and keep standard NIS maps and custom maps used by an in-house application on NIS, but wants to migrate the users over time to Active Directory. This approach is similar to the previous example. The DirectControl Agent is installed on the NIS clients for authentication to Active Directory, but the users are not placed in the DirectControl Zone so that they can continue to use NIS authentication if they have not been migrated to Active Directory. The following steps can be performed: 1. Create a DirectControl Zone in Active Directory with the same name as the NIS domain CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE 10

14 2. Install the DirectControl Agent on all the NIS client machines. This can be done before any users are migrated to Active Directory for the machines they use. 3. Join each NIS client machine to the Active Directory domain and add them to the DirectControl Zone. NSS switch should be configured something like this: passwd centrifydc files nis OR passwd compat (if +/- is used) passswd_compat centrifydc files nis At this point, all users are still authenticating against the existing NIS servers since no uses have been added to the zone. 4. Import all the users and groups into Active Directory using the DirectControl Administrator Console, but leave them in a pending state. This means a user or group is not in the DirectControl Zone until they are accepted. As soon as a user is accepted into the Zone, they will immediately begin authenticating using their Active Directory credentials. The groups should not be added until all the NIS users have been enabled in the Zone. The group membership and other maps will continue to be served by NIS until the user migration is complete. Users will use their Active Directory credentials to authenticate to Active Directory and have their account managed by Active Directory if they were migrated, but get maps from the legacy NIS server via normal NIS requests. All other users will continue to use their NIS credentials to login and get maps from the legacy NIS server using normal NIS requests. During the user migration, it is also a good idea to change the password prompt using DirectControl s Group Policy feature (which extends Active Directory Group Policy to non-microsoft systems) so that users know what machines require their Active Directory password and which require their NIS password. After all of the users are migrated to Active Directory: 5. Add all of the groups to the DirectControl Zone using the DirectControl Administrator Console. 6. Import all NIS maps into Active Directory using the DirectControl Administrator Console. 7. Install the DirectControl Agent on the NIS servers. 8. Join the NIS servers to the Active Directory domain and add them to the DirectControl Zone. 9. Schedule down time, and stop the legacy NIS servers CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE 11

15 10. Install and start the DirectControl Network Information Service (adnisd) on the NIS servers. 11. Modify NSS switch to remove nis from the passwd and group lines. All users will use their Active Directory credentials to authenticate to Active Directory, but get maps from the DirectControl Network Information Service using normal NIS requests. All user accounts, group membership, and map entries are managed in Active Directory. 4.3 Example of Complete Removal of NIS from the Enterprise An organization wants to completely remove NIS from its environment in a phased approach. An analysis is needed 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 of individual clients can be done in a phased migration or at the same time as the standard NIS map migration until NIS is no longer needed. 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 CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE 12

16 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, 2008 CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE 13

17 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. 5 How to Contact Centrify North America (And All Locations Outside EMEA) Centrify Corporation 444 Castro St., Suite 1100 Mountain View, CA United States Europe, Middle East, Africa (EMEA) Centrify EMEA Asmec Centre Merlin House Brunel Road Theale, Berkshire, RG7 4AB United Kingdom Sales: +1 (650) Sales: Enquiries: Web site: info@centrify.com CENTRIFY CORPORATION. ALL RIGHTS RESERVED. PAGE 14