5

Issue: Centralized user management and user permission mangement of user access needs for resources (access to services, home directories, joining to local user groups, file system permissions, etc.) on Linux servers by way of group membership within Active Directory.

Background: We have a number of Linux servers, some CentOS and others Ubuntu, that are used for development, web hosting, database hosting, PXE serving, etc. We also have a centralized Active Directory envrionment where all users are added into and provided with group memberships at the time of joining the organization.

Example: Bob and Alice join the organization, they get added into their appropriate groups within AD, and now they have access to SSH or MySQL on one or more of our Linux servers. Once Bob leaves, we remove him from the AD group(s) and he no longer has access to the Linux servers for SSH, MySQL, etc.

Notes: How does one approach such a task? Is there a set of utilities available within Linux already that will allow this type of operation? The access we need to grant to a user is going to be dependant upon the user group memberships that they are a member of from Active Directory. For example, everyone within the AD Group of Development will need to have SSH access, MySQL access, and a home directory on the Linux versioning server 1 and 2. Everyone that is within the AD group of systems administrator will need to have SSH access and SU permissions for all of the Linux servers, etc. I have looked through a number of the existing articles on serverfault and have not found anything that matches up to the needs listed here.

John
  • 2,276
  • 7
  • 44
  • 60

3 Answers3

5

There are two basic techniques I'm aware of --

Method One: Microsoft's Identity Management for UNIX - This allows you to expose ActiveDirectory as a NIS server.
This works with pretty much any *NIX flavor out there (they all support NIS), and has all the benefit (and drawbacks) of NIS. It is also officially supported by Microsoft, which means you have someone to call if stuff breaks.

Method Two: pam_ldap/nss_ldap (or similar, newer systems).
This works with any modern *NIX flavor capable of authenticating against LDAP directories, and may be included by default with Ubuntu and CentOS these days. It is a bit more robust/modern than the NIS-like hackery in Method One, but less likely to be officially supported by Microsoft.

Both of these techniques require you to extend AD Users and Groups to be POSIX Users & Groups respectively so that there are usable POSIX UIDs and GIDs for your *NIX systems -- Microsoft provides this capability in Active Directory.
An added benefit to Method Two above is that you can further extend the users to enable you to use the OpenSSH LDAP Public Key patch, which lets you store SSH keys in LDAP and eliminates the task of synchronizing authorized_keys files around your network.

voretaq7
  • 79,879
  • 17
  • 130
  • 214
  • These are excellent ideas and good information. We operate an AD environment within a delegated IT infrastructure. As such, we do not have the ability to add or extend AD in some of the manners that you mention. I wish we could, since the OpenSSH LDAP Public Key patch looks pretty awesome. I will read some more about the other items you mention. Thanks again for the info. – John Sep 12 '11 at 17:05
  • You pretty much *must* extend the AD accounts as I described above - there is no other way I'm aware of to provide the information *NIX systems need (specifically: UID, GID, Home Directory, Login Shell) as they are not part of a Windows account's standard attribute set. Extending the AD schema in this way is, as I noted, officially supported by Microsoft so there should be no issue getting that approved. The alternative is maintaining separate POSIX databases and just hooking LDAP for authentication which is a mess... – voretaq7 Sep 12 '11 at 17:21
  • Additional helpful reading: the Developer Support Services for UNIX blog @ http://blogs.technet.com/b/dsix/ – voretaq7 Sep 12 '11 at 17:21
3

From what I'm reading here, you want to have all the other typical Linux things stored in the typical linux fashion, and just have group membership come from AD?

Most of the examples you can find will talk about doing pulling from AD/LDAP (maybe kerberos auth and LDAP for all the user), it sounds like you just want LDAP for group stuff. If I'm wrong, you'll need to also do some PAM stuff.

Depending on exactly what version (it changed with CentOS/RHEL between version 5 and 6), you can use "nss_ldap" or "sssd" for this. sssd is newer. It's hard to say which is more flexible, since they seem to be flexible in different ways. sssd seems more flexible about configuring particular pieces to come from particular sources, while nss_ldap seems more flexible about the LDAP schema being used. You'll need the appropriate packages installed. sssd-client, sssd-tools, sssd, libnss-sss, libnss-ldap and/or nss_ldap. (the authentication stuff is pam_ldap or sssd)

There will need to be some unique numeric ID on the groups in AD. Basically, you'll need to pull the entire definition of the group from AD via LDAP, not just the group membership (entire group definition is basically name, unique numeric id and membership). It may be possible to avoid this with sssd and configure it to look up group ids in files and group membership from LDAP. Really the right thing is to extend the AD schema with the appropriate UNIX extensions so that it has the RFC2307 or RFC2307bis user/group data.

In /etc/nsswitch.conf you'll need group: files ldap or group: files sss. You may want to put "files" second instead of first.

nss_ldap ("ldap" in nsswitch.conf) is configured via /etc/ldap.conf and documented in the nss_ldap package. You'll need to set uri, binddn, bindpw, nss_base_group, pam_member_attribute, nss_map_objectclass group, nss_map_attribute.

sssd is configured via /etc/sssd/sssd.conf. Concentrate on the nss and id_provider stuff, not the pam and auth_provider stuff. Read the sssd.conf, sssd-ldap and sssd manpages. You'll need to configure a "domain" and configure some "ldap_group" stuff instide of it along with the basic id_provider and ldap_uri type stuff.

Note: I run both nss_ldap and sssd stuff against an OpenLDAP environment currently. It's been yearssince I used nss_ldap/pam_ldap with an AD environment.

It may also be worth looking into what Samba can do. It's typically used d for file/print sharing, but the logon stuff and domain controller stuff might be able to be configured for what you need.

freiheit
  • 14,544
  • 1
  • 47
  • 69
  • For the groups, it looks like the only unique numbers that I see are the objectGUID and the objectSID. I am thinking that these are not what you were talking about when you wanted a unique ID. – John Sep 12 '11 at 21:34
  • @John: I don't know AD's schema well enough to answer. Are they integers between 1000 and 2^31? (or at least 200 and 2^32)? Are they unique? Do they ever change for a given group? – freiheit Sep 12 '11 at 21:52
  • Example of objectGUID: {E0F399D4-4DEA-4567-9FD0-6739DEB76F80} ... Example of objectSID: S-1-5-21-3222061595-732799848-2956756862-154377 .. It appears that they are unique per group. – John Sep 12 '11 at 21:58
  • @John: Unique but not really integers. And definitely too big. – freiheit Sep 12 '11 at 22:02
1

Take a look at Likewise Open (Or now called PowerBroker Identity Services Open Edition). I have used Likewise open in a previous job and worked out great with Samba and our devs.

xeon
  • 3,806
  • 18
  • 18