[SSSD] [PATCH] AD: LDAP component of GPO-based access control

Yassir Elley yelley at redhat.com
Tue Apr 15 01:51:29 UTC 2014


----- Original Message ----- 

> On Mon, 2014-04-14 at 17:01 -0400, Yassir Elley wrote:
> >
> > ----- Original Message -----
> > > On Fri, Apr 11, 2014 at 06:32:05PM -0400, Yassir Elley wrote:
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > On Thu, Apr 03, 2014 at 12:30:17PM -0400, Yassir Elley wrote:
> > > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > >
> > > > > Hi,
> > > > >
> > > > > I've read the patches and did some basic tests. You can find my
> > > > > review
> > > > > comments in-line below. I had to add some NULL-checks to make my
> > > > > tests
> > > > > work, see details below as well.
> > > >
> > > > Thanks for the thorough review. Much appreciated!
> > > >
> > > > >
> > > > > In general I think you should add an option to disable the GPO checks
> > > > > to
> > > > > be able to resolve regressions in existing setups.
> > > >
> > > > I'm not sure I understand this comment. What do you mean by "existing
> > > > setups"? If you mean GPO-unaware setups, then the GPO code should not
> > > > break any existing regressions. If it did, we would want to know about
> > > > it,
> > > > right?
> > >
> > > There might be setup where the GPO would in theory apply to a Linux
> > > client running SSSD but since we didn't support it before access was
> > > always granted. If now the GPO is evaluated a user might be rejected
> > > although he was able to log in before. In this case it should be
> > > possible to disable the GPO check to return the previous behaviour
> > > without completely disabling access control.
> > >
> >
> > For disabling the GPO checks, do you want me to add a disable option
> > to the sssd config, or do you want me to add a disable-FEATURE flag to
> > the configure script?

> shouldn;t we enable it with something like access_provider = gpo
> (which would make gpo checks disabled by default as the default access
> provider is 'permit')

> Simo.

The idea has been to include GPO-based HBAC checks as one of the checks performed by the AD access provider. In other words, "access_provider = ad" would first check for AD account expiration, then the ad access filter, and then the GPO checks (stopping as soon as one of the conditions fails, of course). Asking an admin to specify "access_provider=gpo" would result in only the GPO-based checks being performed, which is probably not what is desired in AD environments (i.e. they want all of the checks performed). 

If the Allow/Deny Logon Locally policy settings have *not* been configured in AD, then the default behavior is to permit access, which will therefore not result in a regression. However, because we are using *existing* AD policy settings, it is quite possible that an admin may have already configured GPO-based HBAC policy settings in AD (pre sssd-gpo implementation), which were not being enforced on Linux hosts (b/c there was no sssd-gpo implementation). For example, a GPO that denies Logon access to user "yelley" might already be linked to the domain (and therefore should be applicable to all hosts in the domain), but the Linux hosts in that domain would not be capable of enforcing it. With the arrival of the sssd-gpo implementation, the GPO linked to the domain will suddenly take effect and could deny user "yelley" access to Linux hosts that "yelley" previously had access to (resulting in an unexpected regression). Since the criteria for which policy settings should apply to which hosts is typically based on site/domain/ou (and not on operating system), it is unlikely that the admin would want different HBAC rules for Linux hosts and different HBAC rules for non-Linux hosts, although it is possible. 

As I mentioned, this is only an issue b/c we are using existing AD policy settings. One solution would to use a new AD policy settings folder to hold Linux-specific settings, in which case there would be no ambiguity as to admin intent. Alternatively, I think we should enforce GPO-based HBAC by default for the AD Provider, since this is probably the common case, and since it provides seamless integration with AD GPO without requiring any sssd configuration changes. If desired, we can a "gpo_access_check = False" config option to allow admins to opt-out. An opt-in model is less desirable b/c it is a less likely use case and b/c "opting in" would require a configuration change on each Linux host in the domain. 

Regards, 
Yassir. 



More information about the sssd-devel mailing list