6

I am currently running an OpenLDAP Server managing my Linux Users as posixaccount and posixgroup elements like so:

dn: cn=shellinger,ou=groups,dc=company,dc=com
cn: shellinger
gidNumber: 5001
objectClass: posixGroup
objectClass: top

dn: cn=shellinger,ou=people,dc=company,dc=com
cn: Simon Hellinger
uid: shellinger
uidNumber: 5001
gidNumber: 5001
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: top
...

Right now, aside of primary groups, Linux Group membership is managed locally on each machine. This works but I think defeats the purpose of centralized user management.

What I think I want is to assign my users different sets of groups depending on what machine they log on. Generally my users have useful business on all my machines, so I believe log-in restrictions (based on the host or a certain group) are too coarse grained for my use case. I want to restrict what they can do on each machine, not if they can log in at all; and in my mindset that translates to what Linux groups they are in.

Also, these groups (and as such, permissions) can be vastly different for each user on each machine, a person with superuser permissions on one machine can be a regular user on the next.

In my layman terms this sounds like role-based group-assignment, but after throwing my whole LDAP vocabulary at Google and serverfault I still can't seem to get my head around this.

Summing it up, the questions are: Is my usecase valid? Am I going about this the right way? Should I manage Linux groups in LDAP at all?

1 Answers1

4

In general, group membership should be managed centrally, just like users.

However, when you talk about users needing to be superuser permissions, it makes me think that you're managing wheel for su on each machine separately. This is acceptable, but a bit tedious, especially if you have multiple servers that should all behave the same way.

You could change the group used by pam_wheel or have multiple pam_wheel entries (with different options each time in /etc/pam.d/su, but a better alternative is to use sudo and integrate that with your LDAP. Sudo will give you finer-grain control per server, and LDAP will distribute it appropriately.

Some distributions separate sudo and sudo-ldap.

84104
  • 12,905
  • 6
  • 45
  • 76
  • Great advice! One thing I'm still unclear about: Would you manage *all* group memberships (system-groups and all) in ldap? I resorted to managing only those groups I created myself, such as smb or svn, in LDAP, as these are the ones most likely to need tweaking. – Simon Hellinger Oct 16 '13 at 09:43
  • @SimonHellinger I personally think all is a bit much. It would require `group sss files` or `group ldap files` in `nsswitch.conf` in order to get the first match. Also, I think some groups don't belong in ldap at all, for instance the root group. Also video, cdrom, etc. make more sense as part of `/etc/security group.conf` limited by tty. You'll have to use your own judgement on where to draw the line, but the general idea is to do what makes your life easier while still being secure and being intelligible to your co-admins and/or successor. – 84104 Oct 16 '13 at 16:52
  • I think it's all a bit clearer now, thanks to your explanations. Probably a lot of trial and error still involved in configuring the system, but that's how you learn, they say. Thanks again! – Simon Hellinger Oct 16 '13 at 17:41