4

Before you laugh at me and say, "If you want Active Directory, use Windows" or tell me to use Google, hear me out.

My company relies very heavily on AD. Nay, we are married to it at this point, and as a Fortune 10 company, that's not changing. However, we have a lot of *nix systems in our environment (mostly RHEL and SLES), and I have yet to find a good mechanism for integrating with Active Directory as an identity source. At the very least, I need something to provide the following:

  1. Authentication via AD credentials (letting a user in the door)
  2. Authorization once authenticated (granting a user access to areas of the system)
  3. Audit (being able to tie user actions back to their AD credentials)
  4. Support for AD groups (not just vanilla LDAP and having to add/remove individual users on systems)
  5. Not a duplicate/mirrored identity source based on a trust of AD (I don't need two huge systems)

The top solutions that I have found are as follows:

  1. Centrify
  2. PowerBroker Open (PBIS Open, formerly Likewise-Open)
  3. SSSD+SELinux

Centrify . . . is just ugly. I've never been a real fan. Also, for my company's needs, we can't use Centrify-Express, so it's not free, and there's no unlimited license. However, it's the best solution that we've found, and I'm desperate to find something else.

PBIS Open is what I'm leaning toward. It's what VMware uses in the backend of vShield, and it works pretty well. It only requires a few commands to get set up, it supports AD groups, and there's no secondary identity management system - it talks directly to AD. The only reason for me not going that route is that I like native solutions, and if there's a better way to do it that is already included in modern distros, I'm all for it.

SSSD+SELinux sounded great. It's nasty to set up, but it's flexible, native, and supported by most modern distros. The only thing it lacks (from what I understand) is support for AD groups. Many articles suggest leveraging FreeIPA or something similar to add this functionality, but upon further reading, this violates requirement 5 and basically creates a middle-man identity service. I'm not interested in basically duplicating AD or setting up trust to a secondary identity service.

Other kludge options I've tossed around include using Puppet (which we use) to push out /etc/password,shadow,group files to endpoints, but that requires development, it's incredibly indirect, and I could see something going south badly. A better option would be adding SSSD+SELinux to the Puppet idea. While it would simplify the disaster, it's still a disaster.

What am I missing, what are you using, and what is the "new hotness" that I haven't accounted for to solve the Linux AD integration headache?

Arthur Sommers
  • 69
  • 1
  • 5

6 Answers6

7

Your solutions here are either FreeIPA or Centrify/PowerBroker. FreeIPA is part of your standard RHEL subscription so there is already some savings in place.

FreeIPA can be run in a mode where all users and groups can come from Active Directory. You would only keep mapping of those users and groups to POSIX-specific environments in FreeIPA, like SUDO rules, public SSH keys, host-based access control definitions, SE Linux context assignments and so on. To do so you would need to map some of your AD users/groups to some groups in FreeIPA but that is not a duplication of the information, it is amending it with the parts that are not AD-specific.

The way FreeIPA implements compatibility with Active Directory is by presenting itself as an Active Directory-compatible forest, of sorts. It is enough to allow FreeIPA resources to be consumed by AD users via cross-forest trust but not enough to allow FreeIPA users to access Windows systems on the other side of the trust. You seem to be interested in the first part so this should be fine.

With FreeIPA 4.1 which is part of RHEL 7.1 beta already (hopefully, RHEL 7.1 will be out 'soon'), we have a powerful mechanism to keep the overrides for AD users and groups in FreeIPA and SSSD is capable to discover all of them on per-server granularity.

abbra
  • 1,025
  • 5
  • 8
5

I would really like to hear what you mean by "real AD groups" when talking about SSSD. The newer versions of SSSD don't require the groups to have POSIX attributes and mostly read the group memberships from TokenGroups if the AD provider is used.

Also, in RHEL-7.1 (upstream 1.12+), the SSSD gained the capability to do access control checks using GPO policies.

Feel free to come and write to the sssd-users list if you have a specific question.

jhrozek
  • 1,320
  • 6
  • 5
  • I suppose the terminology is "Active Directory Security Groups:" https://technet.microsoft.com/en-us/library/cc781446(v=ws.10).aspx From what I have found (and from a RH rep, but he could have been wrong), SSSD doesn't support them. Likewise and Centrify do. I'm not sure if other solutions do. – Arthur Sommers Feb 27 '15 at 21:53
  • 1
    "Security Groups" are simply predefined groups that have special meaning for predefined resource types. Like the Backup Operators group has ability to back up and restore files so any member of this group will have this ability. In case of UNIX systems there are no predefined groups like that on a global scheme. However, one can define such groups and map access to them depending on your specific environment and software in use as there seems to be quite a variety among commercial and Open source backup tools (again, just as an example, to continue an analogy). – abbra Mar 01 '15 at 14:31
  • So, in our environment, we have groups down to the team level. For instance, if I need to grant an entire team access to one of our Windows servers, I just grant permission to "domain\team_group." We're good about removing users from groups when they switch teams, so it's far easier than managing individual access to resources since groups are dynamic. – Arthur Sommers Mar 04 '15 at 00:07
2

The Redhat offering is covered well here:
Common wisdom about Active Directory authentication for Linux Servers?

In my recent installations, this has been done via SSSD (built-in) and ldap or sssd.conf group filters.

What exactly do your Linux users need to do on the systems?

Community
  • 1
ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • It *does* sound like SSSD is the solution here. Not sure why or where SELinux should factor in here, though. For auditing I'd rather suggest https://github.com/a2o/snoopy. – daff Feb 25 '15 at 01:53
0

I use the Open Source version of PBIS. In version 6, I found that if I was not logging on to a machine for a while (like months), when I would log on, it would time out. At least it was the case for many machines. I haven't had that issue with version 8.

I found PBIS good enough. It allowed me to set the options I cared about (default home dir, assume domain for logon, set group with access, etc).

I never tried anything else. But I can say I'm happy with PBIS.

There is a Puppet module to install it (my version of it: https://github.com/etlweather/puppet-pbis ).

ETL
  • 6,443
  • 1
  • 26
  • 47
0

what about winbind + samba + kerberos?

  • Authentication via AD credentials (letting a user in the door)

checked

  • Authorization once authenticated (granting a user access to areas of the system)

checked

  • Audit (being able to tie user actions back to their AD credentials)

/var/log/secure? checked

  • Support for AD groups (not just vanilla LDAP and having to add/remove individual users on systems)

it allows both ad groups or ad user in local groups, checked

  • Not a duplicate/mirrored identity source based on a trust of AD (I don't need two huge systems)

freeipa is not required, checked

whattimeisit
  • 9
  • 1
0

i'm using Winbind + Kerberose as well and works fine for years, but now i'm migrating all to Pbis as i've been using it on some machines for years as well and i'm satisfied with it. but as you i like to have native solutions as well, there for i will start testing sssd integrations as mentioned in this document from RedHat. https://www.redhat.com/en/files/resources/en-rhel-intergrating-rhel-6-active-directory.pdf

it has different scenarios of AD Integration.

Jasem Elayeb
  • 1