Netgroups: Not Just for NIS Anymore
Netgroups are not the same as normal POSIX groups. For one thing, netgroups don't have to have anything at all to do with users. You can have netgroups that represent groups of hosts as well. This feature, however, also comes with a slight increase in complexity in terms of how netgroups are defined. With a normal group, you have a record in your NIS group map or /etc/group file that indicates the group name, a password (which is usually not used in many environments), the numeric group ID, and then a comma-delimited list of users that belong to the group. A typical POSIX group entry looks like this:
Netgroups, on the other hand, are defined as "triples" in a netgroup NIS map, or in an LDAP directory; three fields, representing a host, user and domain -- in that order. All three are optional. Let's have a look:
trustusr (-,steve,) (-,jonesy,)
trusthost (deathstar,-,) (falcon,-,)
The "trustusr" netgroup consists of two users, steve and jonesy. We know that they are users because the names are in the middle field of the triple. The "trusthost" netgroup consists of two hosts, deathstar and falcon. We know that they're both hosts because their names are in the first field. The last field in a netgroup triple is reserved for a domain name. If you're using NIS, your clients bind to a domain, and this field becomes more meaningful. For users storing the triples in an LDAP directory, you don't bind to a domain, so this field doesn't need to be used.
Let's have a quick look at a couple of areas where netgroups can be put to effective use. Of course, if you're an administrator who is making the slow, painful migration from NIS to LDAP, one clear benefit to using netgroups is not having to reconfigure all of the clients that [are defined in them?], but there are many others.
The TCP Wrappers configuration files
The /etc/hosts.allow and hosts.deny files support a package called TCP Wrappers that helps administrators define a fairly robust security configuration for a given host. TCP Wrappers lets you can monitor and filter incoming requests for several network services. The software essentially intercepts connection attempts, checks the attributes of the connection (source, service, user, etc.) against the configuration files, and allows or denies connections accordingly. TCP Wrappers configuration can get somewhat complex, and is outside the scope of this article. If you need help with it, you can enter the shell command
man 5 hosts_access.
Let's look at typical host.allow and hosts.deny files that don't use netgroups and compare them to an equivalent hosts.allow that does. The typical files look something like:
ALL:192.168.2.,192.168.3.,.linuxlaboratory.org EXCEPT badhost.linuxlaboratory.org, opus, willy
Our hosts.allow file says to allow access to the finger daemon and portmap to anyone. However, there are apparently other daemons running on this machine, and the only hosts allowed to access these other services are (in order):
- Any host in the 192.168.2 or 192.168.3 subnets.
- Any host in the linuxlaboratory.org domain (except for badhost), and
- hosts "opus" and "willy."
That's a lot of typing, with a lot of room for typos, it takes a lot of parsing to read it. This configuration also leaves some room for extra hosts to get by who you had no intention of giving access to. For example, if you add a new host to the linuxlaboratory.org domain, it automatically has access to all the services on this machine.
How about making a host netgroup that contains only the hosts that need access to all of the services, and referencing that in the hosts.allow file? Here's what it might look like:
You'll recognize opus and willy from the original hosts.allow file. The other hosts are those in the linuxlaboratory.org domain that need access to all services available on this machine. Now we can rewrite that nasty ALL line in our hosts.allow file:
This is much easier to read, has less room for typos, and is a more restrictive security policy, since hosts have to be explicitly added to the netgroup to gain access, instead of inheriting access by virtue of their existence in something as large as a whole domain.
Netgroups and "compat mode"
Compat mode (short for "compatibility") lets you add NIS/NIS+ compatibility to an /etc/passwd or /etc/shadow file. It's pretty neat stuff, and netgroups make it especially cool.
Let's look at how to use netgroups and compat mode. First, define a user netgroup in LDAP or NIS or files -- whichever you use -- that contains only our most trusted users:
Next, we put an entry for this netgroup into our /etc/passwd file. Here's what the line looks like:
This effectively adds all of the users in the trustme netgroup to the /etc/passwd file. Now we just set up our /etc/nsswitch.conf file to use compat mode, which is what supports the parsing of the "+@" syntax in the /etc/passwd file:
passwd: files compat
In the first line, we tell the system we're using files with compat mode to look up passwd information on a user. The second line tells us which naming service the compat mode information request is to be sent to. In our case, having
files compat allows for a root account that's local to each machine and lives in the /etc/passwd file, while still allowing us to make use of an LDAP server for non-local accounts which are centrally maintained.
This is not an exhaustive list of uses for netgroups. They can be used for other things as well, not the least of which are things like your NFS exports file and other fields of your nsswitch file. Since netgroups have been around since the last Ice Age, many utilities at the system level already know what they are. Currently Linux has, by far, the best support for requesting netgroups from an LDAP server. The libraries that do the heavy lifting for Linux (OpenLDAP and PADL's nss_ldap) can also be installed on most Unix flavors -- good news for those of us in heterogenous environments!