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.
Sir i like to know howi install vlc video player on linux systems i tried many times but empty hand!!
ReplyDeletePankaj,
ReplyDeleteYou are doing a great job. Keep posting the new it knowledge.
Abdullah Kamal
please refer for installing VLC
ReplyDeletehttp://www.youtube.com/watch?v=-Uql96eLe0w