LDAP VS NIS

LDAP versus NIS

NIS is only designed for Unix platforms, and is not suitable as a centralized data administration tool in heterogeneous networks.

Unlike NIS, the LDAP service is not restricted to pure Unix networks. Windows servers (from 2000) support LDAP as a directory service.

The LDAP principle can be applied to any data structure that needs to be centrally administered. A few application examples are:

•  Replacement for the NIS service
• Mail routing (postfix, sendmail)
•  Address books for mail clients, like Mozilla, Evolution, and Outlook
• Administration of zone descriptions for a BIND9 name server
•  User authentication with Samba in heterogeneous networks

Ldap is much more secure than nis.

Anyone on a client machine can run 'ypcat passwd' and get all users' password hashes in NIS. There's a special mode called c2secure that implements shadow files so that password hashes are hidden to all but the root user. This is great, but breaks many things. If a program doesn't have access to the password hashes, it can't authenticate users. For example, if you're using Apache, running as user www, and use PAM authentication, that can't work with c2security. Workarounds exist, but involve calling a setuid program to run as root and perform the authentication.

In LDAP, authentication of users and machine access is very secure. For machines, the LDAP client can be configured to need a certificate before it's allowed access. User authentication is done by binding to the LDAP server as the user, over SSL. If the bind succeeds, the user's password was good, and he is authenticated. The great news is that most applications support LDAP authentication mechanisms.

Some Scenarios to Consider

 Say we have a Solaris and Linux mixed environment, where home directories are obviously going to be different. In NIS, we simply engineer the building of the auto.homedirs (or whatever you call it) map to generate different entries for the Linux domain's automounter maps, so that home directories are in different locations.

In LDAP we have a few way to go about this. The client can bind to a different place in the tree, so that its searches for information start in a Linux-centric location. To accomplish this, other information like People (password information) needs to exist in each sub tree as well. So we're back to having to engineer a way to manage duplicate information, and propagate it when changes occur. Alternatively, we could implement this Linux branch of the tree to use referrals for all "global" information.

An LDAP referral is pointer to another place, put simply. Referrals can be used to make this sort of LDAP design feasible: Linux automounter entries are unique, but People refers to a global one.

Another issue arises with netgroups and limiting access to certain machines. In Linux and Solaris, you can limit password entries by using a "+@netgroup" in the /etc/passwd or shadow file instead of just allowing everyone to exist with a "+" at the end of the file. OpenLDAP, by default, does not have a notion of netgroups, but the Sun LDAP server does have an object type: nisNetgroupTriple. If netgroups are used, you'll either be importing foreign schemas into OpenLDAP or you'll need to run Sun's LDAP server. The Fedora Directory Server is based on Sun's, so that's another viable option.

The LDAP client configuration file controls essentially everything. You will define the LDAP server, where the base DN is located, SSL information, and optionally search filters. In the NIS example we gave, separate domains had different password files, built (trimmed) from a global password file of all users. Concocting this sort of environment isn't straightforward in LDAP, if you want to avoid duplicating information.

This line in ldap_client_file (Solaris) or ldap.conf (Linux) specifies how nsswitch passwd entries are found:

NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=People,dc=example,dc=com?one

We can specify that ou=People is actually someplace different, if we were duplicating information or had completely separate People in each container. But to use a global People entry, allowing one password for all types of machines, something else has to happen. People frequently ask how something like this is possible, and the answer is actually simple: add an attribute to each Person, and check that attribute as a search filter in the client configuration.

An example is that different departments in a company or university have Unix machines, and cross-departmental logins aren't allowed. Using a university example, let's say we want CS users to login to a group of machines, but not ECE users. In the People attribute, the schema can be extended to have a 'dept' field. The LDAP client file's service search description uses a search filter to check that the user has this attribute:

 NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=people,dc=xcat,dc=pdx,dc=edu?sub?dept=CS

If the user who attempts to login doesn't have the attribute dept=CS, they won't exist, since the search would fail.

These are a few of the major high-level issues I've personally experienced with a NIS to LDAP conversion. All in all, the work put into LDAP pays off tremendously. Linux clients are happier, it's easier to manage, and it's secure. LDAP authentication is possible directly from PHP, Ruby, Perl and pretty much all other languages and applications in existence. The LDAP learning curve shouldn't be a deterrent.