Directory Services #

OpenBSD can be used for both servers and clients of databases containing user credentials, group information and other network-related data. Of course, you could use various directory services on OpenBSD. But YP is the only one that can be accessed directly using standard C-library functions like getpwent(3), getgrent(3), gethostbyname(3) and so on. Thus, if you keep your data in a YP database, you do not need to copy it to local configuration files like master.passwd(5) before you can use it, for example to authenticate system users.

YP is a directory service compatible with Sun Microsystems NIS (Network Information System). See yp(8) for an overview of the available manual pages. Be careful, some operating systems contain directory services bearing similar names but all the same being incompatible, for example NIS+.

To use directory services other than YP, you either need to populate local configuration files from the directory, or you need a YP frontend to the directory. For example, you can use the sysutils/login_ldap port when you choose the former, while the ypldap(8) daemon provides the latter.

For some applications, simply synchronizing a small number of configuration files among a group of machines using tools like rdist(1), cron(8), scp(1) or rsync (available from ports) constitutes an easy and robust alternative to a full-blown directory service.

YP Security Considerations #

For compatibility reasons, all security features built into the OpenBSD implementation of YP are switched off by default. Even when they are all switched on, the NIS protocol is still inherently insecure for two reasons: All data, including sensitive data like password hashes, is transmitted unencrypted across the network, and neither the client nor the server can reliably verify each other’s identity. Thus, before setting up any YP server, you should consider whether these inherent security flaws are acceptable in your context. In particular, YP is inadequate if potential attackers have physical access to your network. Anybody gaining root access to any computer connected to your network segments carrying YP traffic can bind your YP domain and retrieve its data. In some cases, passing YP traffic through SSL or IPSec tunnels might be an option.

Setting Up a YP Server #

A YP server serves a group of clients called a “domain.” You should first select a domain name; it can be an arbitrary string and need not be related in any way to DNS domain names. Choosing a random name like “Eepoo5vi” can marginally improve security, though the effect is mostly in security by obscurity. In case you need to maintain several distinct YP domains, it’s probably better to choose descriptive names like “sales,” “marketing” and “research” in order to forestall system administration errors caused by obscurity. Also note that some versions of SunOS require using the host’s DNS domain name, so your choice might be restricted in a network including such hosts. Use the domainname(1) utility to set the domain name, and put it into the defaultdomain(5) file to have it automatically set at system startup time.

# echo "puffynet" > /etc/defaultdomain
# domainname `cat /etc/defaultdomain`

Initialize the YP server using the interactive command:

# ypinit -m

At this point, it is not necessary to specify slave servers yet. To add slave servers, you can rerun ypinit(8) later, using the -u option. Setting up at least one slave server for each domain is useful to avoid service interruptions. For example, should the master server ever go down or lose network connectivity, client processes trying to access YP maps block indefinitely until they receive the requested information. Thus, YP service interruptions typically render the client hosts completely unusable until YP is back to service. Decide where to store the source files to generate your YP maps from. Keeping the server configuration separate from the served configuration helps to control which information will be served and which won’t, so the default /etc often isn’t the best choice.

The only inconvenience caused by changing the source directory is that you will not be able to add, remove and modify users and groups in the YP domain using utilities like user(8) and group(8). Instead, you will have to edit the configuration files with a text editor.

To define the source directory, edit the file /var/yp/domainname/Makefile and change the DIR variable, e.g.

DIR=/etc/yp/src/puffynet

Consider customizing other variables in /var/yp/domainname/Makefile. See Makefile.yp(8) for details. For example, even in case you use the default source directory /etc, you do not usually need all accounts and groups existing on the server on all your client hosts. In particular, not serving the root account and thus keeping root’s password hash confidential is often beneficial to security. Review the values of MINUID, MAXUID, MINGID and MAXGID and adjust them to you needs.

If all your YP clients run OpenBSD or FreeBSD, exclude the encrypted passwords from the passwd maps by setting UNSECURE="" in /var/yp/domainname/Makefile.

The former practice of editing the template file /var/yp/Makefile.yp is no longer recommended. Changes to that file affect all domains initialized after the change, but do not affect domains initialized before the change, so this is error-prone either way: You both risk that the intended changes do not take effect, and you risk to forget about them and have them affect other domains later which they were never intended for.

Create the source directory and populate it with the configuration files you need. See Makefile.yp(8) to learn which YP maps require which source files. For the format of the individual configuration files, refer to passwd(5), group(5), hosts(5) and so on, and look at the examples in /etc.

Create the initial version of your YP maps using the commands

# cd /var/yp
# make

Do not worry about error messages from yppush(8) right now. The YP server is not yet running. YP uses rpc(3) (remote procedure calls) to communicate with clients, so it is necessary to enable portmap(8). To do so, use rcctl(8).

# rcctl enable portmap
# rcctl start portmap

Consider using either the securenet(5) or the ypserv.acl(5) security feature of the YP server daemon. But be aware that both of these only provide IP based access control. Thus, they only help as long as potential attackers have neither physical access to the hardware of the network segments carrying your YP traffic nor root access to any host connected to those network segments. Finally, start the YP server daemon:

# rcctl enable ypserv
# rcctl start ypserv

To test the new server, consider making it its own client, following the instructions in the first part of the next section. In case you don’t want the server to use its own maps, you can disable the client part after the test with the following commands:

# rcctl stop ypbind
# rcctl disable ypbind

Remember that each time you change a file sourced by a YP map, you must regenerate your YP maps.

# cd /var/yp
# make

This updates all database files in /var/yp/domainname, with one exception: The file ypservers.db, listing all YP master and slave servers associated with the domain, is created directly from ypinit -m and modified exclusively by ypinit -u. In case you accidentally delete it, run ypinit -u to recreate it from scratch.