NIS vs LDAP Gateway

NIS vs LDAP Gateway

NIS Gateway is a software which uses LDAP as its information source while permitting  existing NIS clients to transparently use LDAP to resolve user, group and host information.

LDAP Gateway does the opposite. It translates and/or caches NIS entries and provides LDAP clients to transparently use NIS information.

Penrose can be configured as an LDAP Gateway to NIS servers, perhaps the only implementation that is available on the market - someone correct me if I am wrong. The NIS translation can be done in a real-time or through a persistence/caching layer, such as a Fedora Directory Server. In cached mode, Penrose is acting as a synchronization agent.  The primary data is still being mastered in NIS server so the administration/changes of the data still need to be done via NIS.

Avoiding “Bigbang” Migration from NIS to LDAP

You are probably asking. NIS is deprecated and no longer supported by Sun, so why are we still keeping NIS ? if the data still resides in NIS, what is the point of all of this then ?

There are still quite a few organizations out there that still use NIS as their primary authentication and identity stores. Most of them have hundreds, thousands or sometimes tens of thousands machines which still rely on multiple NIS servers. Migrating all of these NIS clients into LDAP clients can’t be done overnight  (”bigbang” migration).

Virtual Directory as an LDAP gateway is designed to help the system adminstrator to avoid this “bigbang” migration.

One needs to understand the challenges of migrating to an LDAP infrastructure.

• “If It’s Not Broken, Don’t Fix it” attitude. The reality is NIS does work well. We know a very large enterprise company who can’t completely switch to LDAP because their operational team doesn’t know how to scale their LDAP infrastructure to handle thousands of LDAP clients. So they are still sticking with NIS despite the fact that they might not pass an internal security audit.

• LDAP is hard. The concept of LDAP is not as easily grokked as database technology. Furthermore, this type of migration is considered a high-risk/mission critical project. Somebody will be fired if something goes wrong that cause their operations to halt. System Administrator has to be familiar with LDAP technology inside out to perform this type of large scale migration.

You might ask why can’t you just dump NIS entries,  import it into a directory server and stick a NIS gateway in front of the directory server ? Well, there are two problems that we see with this approach.

1. Before you cut-over to LDAP, NIS server is still the primary and authoritative identity. If there is an imperfection with your NIS entries such as conflicted UID/GID, namespace collision, etc., you will be forced to clean the NIS entries before you can export it to a directory server. The clean-up processes are the most manual and challenging efforts. If you have multiple NIS servers/domains, you’ll be forced to analyze all of the NIS entries across all of NIS servers/domains. By the time you are done with the analysis, there is a good chance someone may have changed the NIS entries and reintroduced yet another conflict. It is like trying to shoot a moving target.
2. The communication between NIS client and NIS Server is not secure. Thus, sticking a NIS Gateway in front of LDAP server won’t fix this issue. The goal of moving to LDAP is not having the clients to communicate any information to the servers without a proper authorization and  secure channel (LDAP SSL/TLS is more secure than YP’s clear text)

With the imminent release of Penrose 2.0, we will be providing tools and processes that can help you move out of NIS to LDAP in a gradual fashion. So stay tuned!

To be continued…