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

Simo Sorce simo at redhat.com
Tue Apr 15 03:51:30 UTC 2014


On Mon, 2014-04-14 at 21:51 -0400, Yassir Elley wrote:
> ----- 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). 

TBH I do not think account expiration has anything to do with access
checks, and should be done unconditionally, regardless of what the
access_provider is, it has more to do with the auth_provider than
anything else.

> 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).

Understood, but not a problem, the default provider is 'permit' at the
moment.

>  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).

It is not a regression, it is an explicit access control check the
admins imposed, it is quite correct to respect those policies.
The bug is that we are not controlling them now, and the solution is
simple, the admin changes the policy (or disables GPO checks).

>  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. 

And they can do that by moving Linux machines to a different OU, let's
not try to work around what domain policies dictate.

> 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. 

If you want to disable GPO checks you should set access_provider =
permit, if you want them the access_provider = gpo, that's how the
system architecture would make you do it if you follow current SSSD
design and I do not see a reason to deviate.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list