On Mon, Sep 14, 2015 at 03:23:23PM +0200, Jakub Hrozek wrote:
On Mon, Sep 14, 2015 at 06:06:34AM -0700, Ray Van Dolson wrote:
> 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.
Ah, matching rule in filter, yes, good idea!
I wonder if there's any additional load on the servers? I think we had
similar reports back when we tried to use this feature for initgroup
lookups..but it's a long time ago, so I forgot the details..
>
> >
> > > - 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.
> > >
[...]
> > 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).
It's actually 1.12.4 + patches, which is very close to 1.12.5 upstream.
>
> We do have a mix of RHEL5 (shrinking), RHEL7 (growing) and Ubuntu 15.04
> LTS (the latter seems to have only 1.11.7).
7.1 might have some gotchas, it's a bit behind 6.7 actually.
There is no GPO support on either Ubuntu or RHEL-5.
Thank you!
As of right now am leaning towards using pam_access with an eye towards
the native GPO integration (once it becomes broadly available on the
bulk of our supported platforms).
Main reason being that it's eas(y|ier) for me to set up separate
per-role access files which can be more easily managed by Ansible
rather than simulating the same with templates and the more noisy LDAP
syntax. Just not a fan of needing to touch the main sssd.conf file
every time we need to push out an ACL change......
.. may backtrack on this if we discover significant performance
advantages to going the LDAP route (potential service-side impacts
aside :).
Ray