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 <[email protected]> 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. _______________________________________________ sssd-users mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-users
