22.5 About NIS Authentication

22.5.1 About NIS Maps
22.5.2 Configuring an NIS Server
22.5.3 Adding User Accounts to NIS
22.5.4 Enabling NIS Authentication

NIS stores administrative information such as user names, passwords, and host names on a centralized server. Client systems on the network can access this common data. This configuration allows to move from machine to machine without having to remember different passwords and copy data from one machine to another. Storing administrative information centrally, and providing a means of accessing it from networked systems, also ensures the consistency of that data. NIS also reduces the overhead of maintaining administration files such as /etc/passwd on each system.

A network of NIS systems is an NIS domain. Each system within the domain has the same NIS domain name, which is different from a DNS domain name. The DNS domain is used throughout the Internet to refer to a group of systems. an NIS domain is used to identify systems that use files on an NIS server. an NIS domain must have exactly one master server but can have multiple slave servers.

22.5.1 About NIS Maps

The administrative files within an NIS domain are NIS maps, which are dbm-format files that you generate from existing configuration files such as /etc/passwd, /etc/shadow, and /etc/groups. Each map is indexed on one field, and records are retrieved by specifying a value from that field. Some source files such as /etc/passwd have two maps:

passwd.byname

Indexed on user name.

passwd.byuid

Indexed on user ID.

The /var/yp/nicknames file contains a list of commonly used short names for maps such as passwd for passwd.byname and group for group.byname.

You can use the ypcat command to display the contents of an NIS map, for example:

# ypcat - passwd | grep 500
guest:$6$gMIxsr3W$LaAo...6EE6sdsFPI2mdm7/NEm0:500:500::/nethome/guest:/bin/bash
Note

As the ypcat command displays password hashes to any user, this example demonstrates that NIS authentication is inherently insecure against password-hash cracking programs. If you use Kerberos authentication, you can configure password hashes not to appear in NIS maps, although other information that ypcat displays could also be useful to an attacker.

For more information, see the ypcat(1) manual page.

22.5.2 Configuring an NIS Server

NIS master servers act as a central, authoritative repository for NIS information. NIS slave servers act as mirrors of this information. There must be only one NIS master server in an NIS domain. The number of NIS slave servers is optional, but creating at least one slave server provides a degree of redundancy should the master server be unavailable.

To configure an NIS master or slave server:

  1. Install the ypserv package:

    # yum install ypserv 
  2. Edit /etc/sysconfig/network and add an entry to define the NIS domain, for example:

    NISDOMAIN=mynisdom
  3. Edit /etc/ypserv.conf to configure NIS options and to add rules for which hosts and domains can access which NIS maps.

    For example, the following entries allow access only to NIS clients in the mynisdom domain on the 192.168.1 subnet:

    192.168.1.0/24: mynisdom : * : none
    * : * : * : deny

    For more information, see the ypserv.conf(5) manual page and the comments in /etc/ypserv.conf.

  4. Create the file /var/yp/securenets and add entries for the networks for which the server should respond to requests, for example:

    # cat > /var/yp/securenets <<!
    255.255.255.255 127.0.0.1
    255.255.255.0   192.168.1.0
    !
    # cat /var/yp/securenets 
    255.255.255.255 127.0.0.1
    255.255.255.0   192.168.1.0

    In this example, the server accepts requests from the local loopback interface and the 192.168.1 subnet.

  5. Edit /var/yp/Makefile:

    1. Set any required map options and specify which NIS maps to create using the all target, for example:

      all:
      passwd group auto.home
      # hosts rpc services netid protocols mail \
      # netgrp shadow publickey networks ethers bootparams printcap \
      # amd.home auto.local. passwd.adjunct \
      # timezone locale netmasks

      This example allows NIS to create maps for the /etc/passwd, /etc/group, and /etc/auto.home files. By default, the information from the /etc/shadow file is merged with the passwd maps, and the information from the /etc/gshadow file is merged with the group maps.

      For more information, see the comments in /var/yp/Makefile.

    2. If you intend to use Kerberos authentication instead of NIS authentication, change the values of MERGE_PASSWD and MERGE_GROUP to false:

      MERGE_PASSWD=false
      MERGE_GROUP=false
      Note

      These settings prevent password hashes from appearing in the NIS maps.

    3. If you configure any NIS slave servers in the domain, set the value of NOPUSH to false:

      NOPUSH=false

      If you update the maps, this setting allows the master server to automatically push the maps to the slave servers.

  6. Configure the NIS services:

    1. Start the ypserv service and configure it to start after system reboots:

      # service ypserv start
      # chkconfig ypserv on

      The ypserv service runs on the NIS master server and any slave servers.

    2. If the server will act as the master NIS server and there will be at least one slave NIS server, start the ypxfrd service and configure it to start after system reboots:

      # service ypxfrd start
      # chkconfig ypxfrd on

      The ypxfrd service speeds up the distribution of very large NIS maps from an NIS master to any NIS slave servers. The service runs on the master server only, and not on any slave servers. You do not need to start this service if there are no slave servers.

    3. Start the yppasswdd service and configure it to start after system reboots:

      # service yppasswdd start
      # chkconfig yppasswdd on

      The yppasswdd service allows NIS users to change their password in the shadow map. The service runs on the NIS master server and any slave servers.

  7. Configure the firewall settings:

    1. Edit /etc/sysconfig/network and add the following entries that define the ports on which the ypserv and ypxfrd services listen:

      YPSERV_ARGS="-p 834"
      YPXFRD_ARGS="-p 835"

      These entries fix the ports on which ypserv and ypxfrd listen.

    2. Allow incoming TCP connections to ports 111 and 834 and incoming UDP datagrams on ports 111 and 834 from the local network:

      # iptables -I INPUT -s subnet_addr/prefix_length -p tcp \
        -m state --state NEW -m tcp -–dport 111 -j ACCEPT
      # iptables -I INPUT -s subnet_addr/prefix_length -p tcp \
        -m state --state NEW -m tcp -–dport 834 -j ACCEPT
      # iptables -I INPUT -s subnet_addr/prefix_length -p udp \
        -m udp -–dport 111 -j ACCEPT
      # iptables -I INPUT -s subnet_addr/prefix_length -p udp \
        -m udp -–dport 834 -j ACCEPT
      # service iptables save

      where subnet_addr/prefix_length specifies the network address, for example 192.168.1.0/24.

      portmapper services requests on TCP port 111 and UDP port 111, and ypserv services requests on TCP port 834 and UDP port 834.

    3. On the master server, if you run the ypxfrd service to support transfers to slave servers, allow incoming TCP connections to port 835 and incoming UDP datagrams on port 835 from the local network:

      # iptables -I INPUT -s subnet_addr/prefix_length -p tcp \
        -m state --state NEW -m tcp -–dport 835 -j ACCEPT
      # iptables -I INPUT -s subnet_addr/prefix_length -p udp \
        -m udp -–dport 835 -j ACCEPT
      # service iptables save
    4. Allow incoming UDP datagrams from the local network on the port on which yppasswdd listens:

      # iptables -I INPUT -s subnet_addr/prefix_length -p udp \
        -m udp -–dport `rpcinfo -p | gawk '/yppasswdd/ {print $4}'` -j ACCEPT
      Note

      Do not save this rule. The UDP port number that yppasswdd uses is different every time that it restarts.

    5. Edit /etc/rc.local and add the following line:

      iptables -I INPUT -s subnet_addr/prefix_length -p udp \
        -m udp -–dport `rpcinfo -p | gawk '/yppasswd/ {print $4}'` -j ACCEPT

      This entry creates a firewall rule for the yppasswdd service when the system reboots. If you restart yppasswdd, you must correct the iptables rules manually unless you modify the /etc/init.d/yppasswdd script.

  8. After you have started all the servers, create the NIS maps on the master NIS server:

    # /usr/lib64/yp/ypinit -m
    
    At this point, we have to construct a list of the hosts which will run NIS
    servers.  nismaster is in the list of NIS server hosts.  Please continue to add
    the names for the other hosts, one per line.  When you are done with the
    list, type a <control D>."
          next host to add:  nismaster
          next host to add:  nisslave1
          next host to add:  nisslave2
          next host to add:  ^D
    
    The current list of NIS servers looks like this:
    
    nismaster
    nisslave1
    nisslave2
    
    Is this correct?  [y/n: y]  y
    We need a few minutes to build the databases...
    ...
    localhost has been set up as a NIS master server.
    
    Now you can run ypinit -s nismaster on all slave server.

    Enter the host names of the NIS slave servers (if any), type Ctrl-D to finish, and enter y to confirm the list of NIS servers. The host names must be resolvable to IP addresses in DNS or by entries in /etc/hosts.

    The ypinit utility builds the domain subdirectory in /var/yp and makes the NIS maps that are defined for the all target in /var/yp/Makefile. If you have configured NOPUSH=false in /var/yp/Makefile and the names of the slave servers in /var/yp/ypservers, the command also pushes the updated maps to the slave servers.

  9. On each NIS slave server, run the following command to initialize the server:

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

    where nismaster is the host name or IP address of the NIS master server.

    For more information, see the ypinit(8) manual page

Note

If you update any of the source files on the master NIS server that are used to build the maps, use the following command on the master NIS server to remake the map and push the changes out to the slave servers:

# make -C /var/yp

22.5.3 Adding User Accounts to NIS

Note

This procedure assumes that:

Warning

NIS authentication is deprecated as it has security issues, including a lack of protection of authentication data.

To create an account for an NIS user on the NIS master server:

  1. If the NIS master server does not already export the base directory of the users' home directories, perform the following steps on the NIS master server:

    1. Create the base directory for user directories, for example /nethome:

      # mkdir /nethome
    2. Add an entry such as the following to /etc/exports:

      /nethome    *(rw,sync)

      You might prefer to restrict which clients can mount the file system. For example, the following entry allows only clients in the 192.168.1.0/24 subnet to mount /nethome:

      /nethome    192.168.1.0/24(rw,sync)
    3. Use the following command to export the file system:

      # exportfs -i -o ro,sync *:/nethome
    4. If you have configured /var/yp/Makfile to make the auto.home map available to NIS clients, create the following entry in /etc/auto.home:

      *    -rw,sync    nissvr:/nethome/&

      where nissvr is the host name or IP address of the NIS server.

  2. Create the user account:

    # useradd -b /nethome username

    The command updates the /etc/passwd file and creates a home directory on the NIS server.

  3. Depending on the type of authentication that you have configured:

    • For Kerberos authentication, on the Kerberos server or a client system with kadmin access, use kadmin to create a principal for the user in the Kerberos domain, for example:

      # kadmin -q "addprinc username@KRBDOMAIN"

      The command prompts you to set a password for the user, and adds the principal to the Kerberos database.

    • For NIS authentication, use the passwd command:

      # passwd username

      The command updates the /etc/shadow file with the hashed password.

  4. Update the NIS maps:

    # make -C /var/yp

    This command makes the NIS maps that are defined for the all target in /var/yp/Makefile. If you have configured NOPUSH=false in /var/yp/Makefile and the names of the slave servers in /var/yp/ypservers, the command also pushes the updated maps to the slave servers.

Note

A Kerberos-authenticated user can use either kpasswd or passwd to change his or her password. An NIS-authenticated user must use the yppasswd command rather than passwd to change his or her password.

22.5.4 Enabling NIS Authentication

To enable NIS authentication for an NIS client by using the Authentication Configuration GUI:

  1. Install the yp-tools and ypbind packages:

    # yum install yp-tools ypbind
  2. Run the Authentication Configuration GUI:

    # system-config-authentication
  3. Select NIS as the user account database and enter values for:

    NIS Domain

    The name of the NIS domain. For example: mynisdom.

    NIS Server

    The domain name or IP address of the NIS server. For example, nissvr.mydom.com.

  4. Select either Kerberos password or NIS password for authentication.

  5. If you select Kerberos authentication, enter values for:

    Realm

    The name of the Kerberos realm.

    KDCs

    A comma-separated list of Key Distribution Center (KDC) servers that can issue Kerberos ticket granting tickets and service tickets.

    Admin Servers

    A comma-separated list of Kerberos administration servers.

    Alternatively, you can use DNS to configure these settings:

    • Select the Use DNS to resolve hosts to realms check box to look up the name of the realm defined as a TXT record in DNS, for example:

      _kerberos.mydom.com    IN TXT "MYDOM.COM"
    • Select the Use DNS to locate KDCs for realms check box to look up the KDCs and administration servers defined as SVR records in DNS, for example:

      _kerberos._tcp.mydom.com      IN SVR 1  0 88  krbsvr.mydom.com
      _kerberos._udp.mydom.com      IN SVR 1  0 88  krbsvr.mydom.com
      _kpasswd._udp.mydom.com       IN SVR 1  0 464 krbsvr.mydom.com
      _kerberos-adm._tcp.mydom.com  IN SVR 1  0 749 krbsvr.mydom.com
  6. Click Apply to save your changes.

    Warning

    NIS authentication is deprecated as it has security issues, including a lack of protection of authentication data.

Figure 22.4 shows the Authentication Configuration GUI with NIS selected as the user account database and Kerberos selected for authentication.

Figure 22.4 Authentication Configuration of NIS with Kerberos Authentication

The figure shows the Authentication Configuration GUI with NIS selected as the user account database and Kerberos selected for authentication.


You can also enable and configure NIS or Kerberos authentication by using the authconfig command.

For example, to use NIS authentication, specify the --enablenis option together with the NIS domain name and the host name or IP address of the master server, as shown in the following example:.

# authconfig --enablenis --nisdomain mynisdom \
  --nisserver nissvr.mydom.com –-update

The --enablenis option configures /etc/nsswitch.conf to enable the system to use NIS for information services. The --nisdomain and --nisserver settings are added to /etc/yp.conf.

For more information, see the authconfig(8), nsswitch.conf(5), and yp.conf(5) manual pages.

For information about using Kerberos authentication with NIS, see Section 22.6.3, “Enabling Kerberos Authentication”.

22.5.4.1 Configuring an NIS Client to Use Automount Maps

If you have configured an automount map for auto.home in NIS, you can configure an NIS client to mount the users' home directories when they log in.

To configure an NIS client to automount users' home directories:

  1. Install the autofs package:

    # yum install autofs 
  2. Create an /etc/auto.master file that contains the following entry:

    /nethome      /etc/auto.home
  3. Verify that the auto.home map is available:

    # ypcat -k auto.home
    *    -rw,sync    nfssvr:/nethome/&

    In this example, the map is available. For details of how to make this map available, see Section 22.5.3, “Adding User Accounts to NIS”.

  4. If the auto.home map is available, edit the file /etc/auto.home to contain the following entry:

    +auto.home

    This entry causes the automounter to use the auto.home map.

  5. Restart the autofs service, and configure the service to start following a system reboot:

    # service autofs restart
    # chkconfig autofs on

    The autofs service creates the directory /nethome. When a user logs in, the automounter mounts his or her home directory under /nethome.

    If the owner and group for the user's files are unexpectedly listed as the anonymous user or group (nobody or nogroup) and all_squash has not been specified as a mount option, verify that the Domain setting in /etc/idmapd.conf on the NFS server is set to the DNS domain name. Restart the NFS services on the NFS server if you change this file.