Why Migrate?

According to the Gartner Group "more Gartner clients are moving away from NIS because of poor support and weak security for data in transit on networks" (Gartner report ID Number: G00149425). This section discusses the limitations of NIS in more detail and explore some alternatives.

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:

Because of these security issues, NIS deployments frequently fail general IT security requirements or specific SOX, PCI or other audits.

Besides security issues, NIS also has maintenance and manageability issues. NIS database maintenance is done by hand editing data files on a NIS master, and then using a combination of Makefiles and scripts to generate various maps and load that data into the NIS master server. There is no mechanism to change a single value in a map without reloading the entire map again. In addition, NIS map information is frequently stored separately from the central directory service, which means organizations need provisioning and synchronization systems to manage accounts, passwords, etc. Delays or holes in provisioning, account maintenance, and deprovisioning procedures can lead to orphan accounts and users with out-of-date access rights.

NIS also has network dependency issues. Any NIS system administrator knows that a NIS client machine can take hours to boot when the NIS server is unavailable. The NIS interface to DNS via nsswitch can cause every user, group and host lookup to hang up to 15 minutes before recovering.

Finally, both NIS and NIS+ are effectively "end-of-lifed" by Sun (NIS+ explicitly so, NIS by the focus of migrating NIS to LDAP), meaning that an investment in NIS carries support and maintenance risks.

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 notes: "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 are turning to Active Directory as the logical and cost-effective directory from which to manage more of their enterprise.