Reading time: 2 minutes
Nested netgroups for fun and profit
Imagine you have several hundred systems to manage. The systems are for separate projects and each project has different teams of admins and only assigned admins should be able to log into the system (and at best only be seen on the system). However it should be easy to setup, just be configured on a central system. This is what i came up with.
Obviously the solution for a central system can be adressed with LDAP. Nobody sets up a new NIS Environment today ;)
I wasn’t really keen to configure netgroups directly in LDAP, so i created a file representing this:
The idea is that you group users (ngt*) into working groups (wg*), which are connected to projects (proj*)which are connected to servers (client1 and client2 are the hostnames of two Solaris 11.4 VMs, client is used in the sense of ldap clients). For each server there is a top-level netgroup named like the server.
The structure of our organization as represented by the template would be like
How the users are put into this group is up to the structure you want. There is no necessity to have a netgroup for each server, but it makes the movement of the server to a new admin team easier without touching the server, as you are not bound to any grouping that you have done in the past.
Essentialy you have to do one step on the server. The rest is done in LDAP.
Import the template into the server. By the way, you can use the ldapaddent command to import other preexisting nameservice files like /etc/passwd into the ldap as well. Please consult the man page for this task.
The representation of our template in LDAP looks like this.
Afterwards you have to add the following line to /etc/pam.d/others
Please keep in mind, that you need to add this line as well into PAM services that already have account lines as
others is only active when a PAM service has not its own configuration for a section. If you don’t do this, thee service won#t use that line above which is needed to bring this configuration to work.
Now we do the one step that connects the server to the the nested netgroup and thus to the whole idea.
This is the only place where you have to do something on the client. Everything else is done on the LDAP server. The last line must be an @ followed with the name of the host as explained before. You never change this. The assignment of users is done by nesting other groups into the netgroup with the name of the server.
Let’s check this ngtc2u1 is member of working group 2 (wg2) which is member of Projekt 2 (proj2) which is member of the netgroup for client2.
ngtc1u1 isn’t part of netgroup client2 or a nested netgroup inside of the netgroup client2 and thus shouldn’t be able to login to the system.
When you have logged into the system, you are able to su into a different user of the same netgroup client2 (or a nested one).
Try the same again with a user outside of this netgroup and it won’t work.