This is every SysAdmin's nightmare of things to do. Basically we want to control who has access to which hosts. As simple it may sound, the problem is to find a scalable and low maintenance(mgmt. overhead) solution. We use bcfg2 for Config Mgmt much like Cfengine & puppet.

Some ways:

  1. Netgroups is very scalable but comes with a huge mgmt overhead. Maintaining hosts, group of hosts, user netgroups(separate from ldpa groups) seems like a very big burden, but is doable.

  2. ldap.conf (go to the post by jmozdzen on 1st July) and LDAp based access control. We could template the ldap.conf for each host and create a group with hostname and members as users. But the downside is you cannot specify ldap group(team of users) for access but only individually.

  3. sshd_config restriction. But that doesn't work if the users log in natively.

  4. Host attribute check. By un-commenting pam_check_host_attr in ldap.conf and add the hostname to each user works well, but automation is not easy.

Anybody has a different approach to this problem and that scales well and automated?


I use something similar to your "Option 2" -- an LDAP (pam_ldap/nss_ldap) setup where each class of server has a group in LDAP (db, web, etc.), and the members of that group are allowed to log in to that class of server. This is about the same overhead as netgroups, but it works well because our user lists are relatively static (you have access to a list of machines, and that access is pretty much forever).

We don't allow console logins for LDAP users (only the emergency service & root accounts can log in locally, and those passwords are carefully guarded), so the ldap-specific restrictions only need to be applied to sshd in our case.

  • +1 : You can use LDAP + PAM to control access. OpenSSH can also use PAM. – Stefan Lasiewski Jul 13 '10 at 18:02
  • Thanks, Can you post the schema for hostclass in ldap & what attribute do you use for group member?(I have uniquememeber). – Prashanth Sundaram Jul 13 '10 at 18:22
  • There is no schema for "host class" - it is a logical/administrative construct. Our LDAP structure defines an OU called LoginACLs, with a sub-OU for each site, and groupOfUniqueNames entities in each site for each "server class". Access control is enforced by pam_ldap's pam_groupdn directive (we use uniquemember as the membership attribute) Users and Groups are global in my case: Just because you can't log in doesn't mean you shouldn't exist (you may own files because of an NFS mount) – voretaq7 Jul 13 '10 at 18:36
  • We also have serverclasses and using that would greatly reduce the number of groups to manage and logic behind is simple: Users accessing all DB hosts are same with minor exceptions. Thanks for the feedback. – Prashanth Sundaram Jul 13 '10 at 19:20
  • Exceptions are the only real killer here: As far as I'm aware there's no way to one-off a user like there is in NIS (I could be wrong though -- I didn't look too hard since we disallow one-offs as a mater of company policy so I don't have to support that use case ;) – voretaq7 Jul 14 '10 at 16:44

Another interesting approach is suggested in OpenLDAP's nssov module. See the README for details.

  • 1
    Is that OpenLDAP/slapd specific? I am using 389 Directory. From what the [homepage][1] says it is a LDAP way of looking up flat files like /etc/aliases, hosts etc. Glancing at README looks like a Dn like this 'cn=<service>+uid=<user>,cn=<hostname>,cn=pam,cn=auth' and a regex match is sought. I like this approach but, looks like it is Double beef burger, tasty but hard to digest. Implementing flat files lookup is much simpler without the nslcd.conf, just use PADL migration tools and change nsswitch.conf to ldap. Any more feedback is welcome. [1]: arthurdejong.org/nss-pam-ldapd – Prashanth Sundaram Jul 19 '10 at 15:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.