NIS (nee YP) appears to be immortal. It's almost 30 years old, and it is still in widespread use today. Sure, you could point to many other protocols and services in current use that are as old or older, but NIS is somewhat of an oddity in that it's an authentication mechanism that has been ostensibly supplanted numerous times in numerous ways, yet still hangs on in Unix shops the world over. Depending on the environment, this could be good or bad.
For those unfamiliar with NIS, let's do a little primer. NIS was developed by Sun in 1985 to facilitate a central authentication and authorization mechanism for networked Unix systems. It can also handle other tasks, such as centralizing the administration of network share mounts, host names, and other network configuration data. Essentially, anything that can be condensed into a text file can be shared via NIS.
[ InfoWorld's Paul Venezia reveals the 9 traits of the veteran Unix admin. | Prove your expertise with the free OS in InfoWorld's Linux admin IQ test round 1 and round 2. | Track the latest trends in open source with InfoWorld's Open Sources blog and Technology: Open Source newsletter. ]
Thus, a NIS server can provide any information relevant to a networked Unix system by distributing text files to requesting systems. On a master NIS server, you define your files, or maps, and populate them with relevant data. You will have a passwd file, a groups file, perhaps an automount file, and so forth. You then publish those maps to the server, point your other systems to that server, and tell them to use those maps for various tasks.
This means that when someone logs into a Unix system via NIS, their credentials are checked against the passwd map, which in most cases has the encrypted password strings readily visible. Their group permissions are checked here as well, and they are permitted or denied login based on that information. While logged into the system, users can readily view those maps too. You can also use shadow passwords with NIS, but this is somewhat of a lost cause, because it's still possible to view the maps as they're transmitted over the wire. A better practice is to encourage and enforce strong passwords.
NIS has obvious security challenges. However, the other options for central Unix authentication are not without their own challenges. The best modern method is using LDAP with or without Kerberos. However, many shops still running NIS inherited it from the days of yore, and re-architecting their entire authentication mechanism is challenging at best, especially considering the user identity and NFS storage issues that will crop up.
Another option is to authenticate to Microsoft's Active Directory. This is only useful in mixed infrastructures, and there are a few ways to do it. The first is to implement Microsoft's own NIS server, but then your NIS master is a Windows server, which makes many Unix/Linux admins feel unclean. Another way is through LDAP authentication to Active Directory, but this too can be an uphill battle depending on the size and spread of the Unix environment. For many organizations, the Unix/Linux and Microsoft sides of the house are completely separate, in which case using Active Directory for Unix/Linux authentication doesn't makes much sense either.
I suppose you could use NIS+, but anyone who's worked with it can tell you it was a reasonably good idea executed so poorly that it's best to forget it ever happened. Even though NIS+ "succeeded" NIS in 1992, you'll find much more widespread support for NIS than NIS+ could ever dream of. Even Sun/Oracle gear neglects to include NIS+ support in many cases, and NIS+ was officially removed from Solaris in version 11.1.
While NIS has strikes against it, we also need to take into consideration that it works, and it works well. It's a small, clean service that is easily made redundant, and it ties in easily with just about any flavor of Unix you can find. In a greenfield environment, NIS would definitely not be the go-to solution. But in a mostly trusted environment, such as Unix/Linux development shops with many workstations and compute/compile servers, NIS is the answer -- the security risks are minimal, the setup is simple, and the function is solid. Many of these environments have tightly coupled infrastructures that carry the weight of years, and they rely heavily on information distributed via NIS that would be challenging to replicate with any other mechanism. And let's face it -- LDAP configuration is hugely more complex than NIS configuration.
So NIS lives on, resolutely distributing maps, supporting legacy and modern systems alike, too archaic and simple to live, but too simple and useful to die.
This story, "Why Sun's NIS will never die," was originally published at InfoWorld.com. Read more of Paul Venezia's The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.