I was recently asked for my opinion on options for adding access control, or, more specifically, host-level authorization for users connecting to Linux systems. All the systems in question are a variety of CentOS, and all of them are configured to use LDAP for authentication and authorization via the pam_ldap and nss_ldap modules.

The Problem

In a default configuration, pam_ldap and nss_ldap will make user and group accounts in LDAP act just like user and group accounts in /etc/passwd, /etc/shadow and /etc/group. If it is present, it’s a valid account for the system. In the general case, this is a good thing, and simplifies the configuration of your systems. Things get complicated, however, when you only want a subset of users to be allowed to log in to specific machines. Traditionally, the method for doing this has been to force pam_ldap to examine the LDAP entry for the user trying to authenticate, and only allow the authentication to succeed if some attribute of the user’s object matches a configured value. The host attribute of the account objectclass is a great one to use, but if your user objects are based on person or inetOrgPerson, and you’re doing the right thing and have strict schema checking, you can’t use it. You’d either have to violate your schema and disable checking, or violate your schema and add the extensibleObject objectclass, which is basically a schema-valid end-around to schema checking.

There are similar tradeoffs for other object attributes you might choose for utilizing for access control, especially considering that you can only use attributes that exist in your users’ LDAP objects, and not outside them. While it certainly can be done, and I have done it in LDAP implementations before, there’s never a truly clean way to implement the policy, and changes to the policy induces the risk of breaking the host’s LDAP configuration entirely.

A Good Solution

In the case I was most recently asked about, the only way to gain access to the system is via SSH. The application stack which the hosts run either doesn’t do any user authentication, or handles it itself. Taking a step back from LDAP, then, there is an easier way to do access restrictions: the OpenSSH daemon’s AllowUsers and AllowGroups configuration directives.

Utilizing the capabilities of OpenSSH takes one piece of complexity out of the already complex LDAP client configuration, and moves it into a service that is a lot easier to repair should something go wrong. This is especially true if you are utilizing a configuration management (CM) system like CFEngine, Puppet or Chef, where the ability of the CM to do anything might completely hinge upon the system user and group databases being intact. A configuration error that causes people to not be able to log in via SSH is less serious than all of your systems user and group records disappearing, which can completely unhinge your system.

Finally, utilizing OpenSSH’s AllowUsers and AllowGroups let’s you manage access to hosts simply by modifying group memberships of users, which can be easily done in LDAP with tools such as my personal favorite, the LDAP Account Manager. This nicely avoids the possibility of having to write your own management tool for access control to add/delete/modify attributes that aren’t easily handled by existing tools, or may not even be visible to those tools. Saving time and effort is key to sanity as a systems administrator, and this will save you a lot.

The best part, though, is that this method works regardless of whether you use LDAP, NIS/NIS+, rdist /etc/passwd and friends from a master copy, or any other method of pushing user and group account data out to your hosts. On top of that, there’s nothing saying you can’t layer this on top of LDAP ACLs, too, for that extra bit of paranoia.

Loose Ends

There are, however, some downsides to doing access control via OpenSSH. The first is that it only applies to OpenSSH. This may seem like a statement of the obvious, but it’s important to point out. Other services you may be running, which also rely on LDAP for authentication and authorization, will not be beholden do your policies configured for OpenSSH. Again, it may seem like I’m simply re-stating the obvious, but consider:

• Do you run an FTP server with user accounts?
• Do you run an IMAP or POP service?,
• Do you run SMTP AUTH?

Those are just three examples, but any service you provide that performs user auth and does so via PAM, SASL (backed by PAM) or directly with LDAP would need to have it’s own ACLs in place if you don’t want all your LDAP users to have access.

With that in mind, however, if your needs are simple, use a simple tool, and get the job done with less stress.

Happy hacking!