Thanks, Jakub...
On Sun, Sep 13, 2015 at 09:38:30PM +0200, Jakub Hrozek wrote:
> On 13 Sep 2015, at 01:09, Ray Van Dolson <rvandolson(a)esri.com> wrote:
>
> Trying to finalize a standard setup for access control and finding
> there are numerous options for group or username based access control.
> I'm using the ad access_provider (2012 R2 servers).
>
Hi Ray, thanks for the very nice summary. I think we should add it to
our upstream AD client howto!
> - ad_access_filter
> + Pros: Pretty powerful. I can do nested groups with the proper
> syntax. Good speed?
Umm, can you? I always thought the memberof attribute in AD's user
entry was single-level? What configuration are you using?
Here's an example:
ad_access_filter = DOM:domain.com:(|(memberOf:1.2.840.113556.1.4.1941:=CN=IO Network
Admins,OU=Distribution Groups,OU=Managed
Objects,DC=domain,DC=com)(memberOf:1.2.840.113556.1.4.1941:=CN=ISTUnix,OU=Security
Groups,OU=Managed Objects,DC=domain,DC=com))
Sorry for the long line. Per MS[1], this should walk the object's
ancestors... seems to work well for me. You can see how this could get
hairy though.
> - Cons: Configurations can get pretty ugly (especially with the
> nested group ldap syntax) and complex all on one very long
> line. Must be in the sssd.conf file so can't have thing
> separated easily per-machine or per role that a machine may
> participate in.
>
> - simple_allow_groups (with access_provider = simple)
> + Pros: Simple. Readable config.
> - Cons: Not sure? Maybe some performance limitations as compared
> to ad_access_filter? Don't believe supports nested group
> membership.
>
It does. The biggest difference is that the ad_access_filter is
applied on the LDAP entry itself. In contrast, the simple provider
first resolves the group memberships, saves them to the cache and
then evaluates the cached entry.
You're right that at the moment, the simple access provider can be a
little slower, unless ignore_group_members is set to true.
> - pam_access (actually, not sure if this one works, but in theory it
> should)
Yes, I don't see a reason it shouldn't. I know several users tried this option.
> + Pros: Could externalize / customize per machine or per Ansible
> role more easily due to ability to easily use multiple
> external include files.
You can also set access per netgroup etc.
> - Cons: Not sure. Another layer in the process so potentially adds
> some delay and complexity.
>
Right.
I
> - SSH's AllowGroups (should work with sssd-ad I believe?)
> +Pros: Simple.
> +Cons: Only works w/ SSH (maybe not a big deal for my use case).
> Unsure on speed.
I would guess the performance would be similar to sssd's simple
access provider. ssh would retrieve the list of GIDs the user is a
member of with getgrouplist() and then convert the gid into name with
getgrgid() which is cca what the simple access provider is using.
>
> - ad_gpo_access_control (no idea how this one works but sounds
> powerful)
> +Pros: In theory means everything is managed centrally in AD GPO.
Yes, this is the biggest win.
> +Cons: I've never tried it so don't know. :-)
I would say the biggest con is that it's complex code that is not as
well tested as the other options simply because it has not been
around as long as the others. There are some bugs that were fixed in
upstream only. But I would encourage you to try this option and
report bugs!
That's what I was thinking. Younger code base = more adventure. :)
What SSSD version on what OS are you running?
Running wahtever comes with RHEL6 -- mostly (as of right now that's
1.12.4).
We do have a mix of RHEL5 (shrinking), RHEL7 (growing) and Ubuntu 15.04
LTS (the latter seems to have only 1.11.7).
>
> Maybe I am missing some good alternatives above? Right now am using
> ad_access_filter mostly and planning to use Ansible's templating system
> to manage per host or service roles. Could get complex if we end up
> needing to do customizations on a per machine basis in certain cases...
>
> Thanks,
> Ray
Ray
[1]
https://msdn.microsoft.com/en-us/library/aa746475%28v=vs.85%29.aspx