Starting with Bullseye, the NIS system has undergone major changes. The traditional setup, which is based on the NIS client broadcasting on the local network to discover an NIS server, is no longer the default. Whether you're installing a new Debian system or upgrading from a previous release, if you plan to use NIS, you should read these notes and plan accordingly.

This is a copy of the NIS How-to on Debian from the Bullseye nis package. It's available locally as /usr/share/doc/nis/nis.debian.howto.gz if the package is installed.


This HOWTO describes:

  1. How to setup a NIS client-only system

  2. How to configure your system to use NIS for users, groups and hosts

  3. How to setup a NIS master server

  4. Shadow passwords

  5. How to setup a NIS slave server

  6. How to setup a NIS server for broadcast

  7. The /etc/default/nis configuration file

  8. NIS security considerations

How to setup a local NIS client

How to configure your system to use NIS for users, groups and hosts

How to setup a master NIS server

Shadow passwords

Libc6 has real shadow support for NIS builtin. It works like you would expect; export the shadow map from the NIS server and just use it. The shadow map should be built with the "-s" (secure) option to makedbm. This is automatic in all modern /var/yp/Makefile files.

Note that if you use the shadow password file you need to add "plus" entries (as in 2.2) to both /etc/passwd and /etc/shadow. Make sure you use the correct format; the passwd and shadow files have different fields.

On the master server the /var/yp/Makefile file needs to include the shadow file in the "all:" target. If you're using the sample /var/yp/Makefile this is done automatically - it autodetects /etc/shadow and builds/exports it if it exists.

How to setup a NIS slave server

How to setup NIS server for broadcast

Talking about NIS setup, the Debian 10+ default NIS server configuration prevents the clients being able to work in broadcast mode (its default). You have a couple of alternatives: either specifying an explicit server IP address in /etc/yp.conf on the NIS client (i.e. not use broadcasting), or add -r to rpcbind daemon on - at least - one of the NIS servers.

That could be done as follows:

echo "OPTIONS=-w -r" >>/etc/default/rpcbind
systemctl daemon-reload

on the server(s), before running any client ypbind. This can also be used on each server in order to configure it as a client of itself: in that case, the best thing to do is usually using the loopback address in /etc/yp.conf. Finally - even if not mandatory - it is often convenient in small networks having most/all clients even acting as slave servers, because that would render the net more resilient against temporary master unavailability.

The /etc/default/nis configuration file

The Debian system traditionally provided a set of configuration environment variables in /etc/default/nis. That is now totally optional, but still useful if default values need to be overriden for some reasons. The NISSERVER and NISCLIENT vars are still there, but are not used anymore when using systemd services. The traditional sysv init scripts are provided as courtesy scripts for people who still use init and they still use the two variables for historical reasons. So, both ypserv and ypbind-mt come with their init scripts for each daemon. The alternative would be renaming the S link in K link in /etc/rcX.d for each YP service not in use.

As consequence, the nis courtesy package could also be not installed at all on new boxes, because the only truly useful stuff it provides is this document :-)

NIS security considerations

Note that NIS allows all clients to download users' shadow passwords in encrypted mode, in merged or not merged form. The only other form of protection is that provided by listing allowed client IPs in /var/yp/securenets. This is intrinsecally a weak form of security, so NIS should be used as is only in trustable networks, well protected by intruders. Eventually, it is possibile to use NIS with Kerberos to avoid the use of system shadow passwords for authentication and use Kerberos tickets instead, which adds one more layer of complexity to the system and implies that the admin needs to keep two different databases in sync. This is not conceptually different from what can be done with a LDAP+Kerberos setup, but for using libnss-nis instead of libnss-ldap.