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:
- 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.
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.
Additional resources on NIS limitations:
› Centrify blog entry on NIS Migration› Centrify chalktalk on NIS limitations and NIS Migration