Centralized Authorization Using a Directory Service, Part II

Get a handle on administering who can log in where, with a proven, reliable centralized directory.
Slave Server Configuration

NIS slave servers are NIS clients that redistribute the maps they receive from the NIS master server to other NIS clients. Make sure the newest portmap, ypserv, ypbind and yp-tools RPMs are installed on all your slave server machines. The first step in configuring an NIS slave server is to configure it as an NIS client. See the next section for how to do this.

Once the NIS client is configured, start it with:

# service ypbind start

On your NIS master server, add the name of the new NIS slave server to the file /var/yp/ypservers and run the following commands:

# cd /var/yp
# /usr/lib/yp/makedbm ypservers

You also need to change the definition of NOPUSH in the file /etc/YP/Makefile on your NIS master server from true to false in order to get updated NIS maps pushed from your master server to your slave server(s).

Back on your new NIS slave server, initialize the slave server with:

# /usr/lib/yp/ypinit -s nismaster

where nismaster is the name of your NIS master server. This needs to be the fully qualified domain name (FQDN) if your DNS returns the FQDN for a name lookup. Copy the file /var/yp/securenets from your NIS master server over to the new slave server, and start the new NIS slave server with:

# service ypserv start

Remember to update your disaster recovery plan to reflect the new dependency of your NIS slave server on your NIS master server.

Client Configuration

Install the latest ypbind, yp-tools and portmap RPMs on all your clients. Edit the file /etc/yp.conf to tell the client about your NIS server:

ypserver nismaster.example.com

Add a line for each of your slave servers as well, if you have some. Use a random order for these servers on your clients to get somewhat even load balancing over all available servers.

Add a line to /etc/sysconfig/network to define the NIS domain of the client:


and set the NIS domainname with the command:

# domainname nis.example.com

Start the portmapper with:

# service portmap start

and the NIS client with:

# service ypbind start

on each client.

The command ypwhich should now output the NIS server to which this client has bound.

Use the ypcat command to check the content of your NIS maps. For example:

% ypcat passwd

Next, you have to tell all lookups on your client to use NIS. This is done in the name service switch configuration file /etc/nsswitch.conf(5). Change the passwd, group and netgroup entries to:

passwd:       compat
group:        files nis
netgroup:     nis

This defines the search order for group lookups: start with the local /etc/group file and then try an NIS lookup. Netgroups come only from NIS. I return to the compat entry for passwd later.

The name service caching dæmon nscd(8) sometimes has problems updating its internal cache. The effect is that changes in an NIS map are not visible on a particular client. Restarting nscd on that machine is the only solution to this problem.

Typical Usages

Two commands you should be familiar with to query information from NIS are ypcat(1) and ypmatch(1). ypcat prints values of all keys in an NIS map. The command ypcat passwd prints all entries in your NIS passwd map. ypmatch prints the values of one or more keys from an NIS map; ypmatch jane passwd outputs the passwd entry for account jane.

NIS Group Map

A typical use of the NIS group map is to allow file sharing between multiple users. This works with local files as well as with files in NFS. Here is how to set it up. Let's say you have two users (this technique works for any number of users) with the following passwd map entries:




Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Part I Please

shann's picture

can you post the link for the Part I of this article?

thanks & regards


Pasamio's picture

Central Authentication with Kerberos 5
http://www.linuxjournal.com/article/7336 (Part I)

Centralized Authorization Using a Directory Service
http://www.linuxjournal.com/article/7334 (Part II)

AFS - A Secure Distributed Filesystem
http://www.linuxjournal.com/article/7521 (Part III)

Was a bit confusing since the article titles are all different.

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
On Demand
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot