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

Yassir Elley yelley at redhat.com
Tue Apr 15 17:13:32 UTC 2014



----- Original Message -----
> On Tue, Apr 15, 2014 at 10:03:35AM -0400, Simo Sorce wrote:
> > On Tue, 2014-04-15 at 10:16 +0200, Jakub Hrozek wrote:
> > > On Mon, Apr 14, 2014 at 11:51:30PM -0400, Simo Sorce wrote:
> > > > >  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).
> > > 
> > > The problem is that we can lock out users completely by fixing the bug.
> > > In principle, I agree with you, I just think there should be a
> > > transition period where we warn loudly that with the next version
> > > account X wouldn't be allowed to log in, go fix your access control
> > > scheme.
> > 
> > Ok so what you are proposing essentially is to have a gpo_enforcing
> > yes/no option
> > 
> > with yes we block the user
> > with no we do not but loudly complain it will be blocked
> > 
> > we start with a default of gpo_enforcing = no, and later we change the
> > default to yes.
> 
> Yes, pretty much.
> 
> I just wonder if it would make sense to follow exactly the model LDAP
> provider has and have an 'order' option that would default to 'expire,
> filter' currently and later when we enable GPOs would turn into 'expire,
> gpo, filter'. But that's probably too much complexity.
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> 

This seems like a reasonable compromise, although it may delay deployment until the version in which gpo_hbac is enforced by default. The alternative, of course, is to enable it by default and have the "loud complaining" be denied access!! :) Just kidding.

I have a few comments/questions about the proposal:

* When we are talking about setting the default to "no", and changing the default to "yes" in the next version, what do we mean by "next version"? Are we talking sssd version (1.11.x=no, 1.12.x=yes), fedora version (f21=no, f22=yes), rhel version (rhel 7.1=no, rhel 7.2=yes), something else?

* Since one of the goals of having an AD provider is to simplify configuration for AD environments (as compared to the LDAP provider), I think that using the 'order' option might undermine that goal (by introducing complexity).

* We should agree upon a name for the options field. How about "ad_enforce_gpo_hbac"= {True, False}?

* When we talk about "loudly complaining", is this simply a log message with high priority? If so, how high should it be (FATAL_FAILURE? CRIT_FAILURE? OP_FAILURE?)

Regards,
Yassir.







More information about the sssd-devel mailing list