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

Simo Sorce simo at redhat.com
Tue Apr 15 19:03:55 UTC 2014


On Tue, 2014-04-15 at 20:25 +0200, Jakub Hrozek wrote:
> On Tue, Apr 15, 2014 at 01:13:32PM -0400, Yassir Elley wrote:
> > 
> > 
> > ----- 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.
> 
> You're right, although a x.1 version usually follows x.0 in no more than
> a month.
> 
> Alternatively, we could enable this warning for pre-release versions and
> make the switch to GPO enforcing in x.0, but I'm not sure how many users
> actually run the pre-releases (short of Rawhide users..)
> 
> > 
> > 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?
> 
> I was thinking 1.12.0 would be 'no' and 1.12.1 would be 'yes'. 1.12.0
> should be what F-21 ships with and 1.12.1 would be delivered as an update
> to F-21. I'm not sure about RHEL 7.1, but I suppose we'd have 1.12.1
> or 1.12.2 in 7.1 (and I'm not making any prediction on RHEL the product
> now. I'm just a random dude who happens to have a .redhat.com address).

This would change behavior midrelease, it is not nice, I would say
1.12.0 ships in permissive mode by default, and 1.13.0 switches to
enforcing by default.

Interested users can always manually switch to enforcing on their own,
there is no need to rush this onto them.

> > * 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).
> 
> I agree. The order was not a good idea, a boolean is much simpler to
> understand. If the ad_acess_filter was defined, it should have been used
> without any additional 'order'..
> 
> > 
> > * We should agree upon a name for the options field. How about "ad_enforce_gpo_hbac"= {True, False}?
> 
> Is HBAC a term that would be easily understood by AD admins? I
> understand it, but I know what it means from working on IPA..
> 
> What about ad_access_enforce_gpo?

why the ad_ prefix ?

gpo_access_control = disabled|permissive|enforcing

> > * 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?)
> 
> I was thinking FATAL_FAILURE. I think a syslog message is probably an
> overkill.

It is not a failure, let alone fatal.
It should be something that gets logged in the security log however, so
whatever ends up there by default is fine.

This is auditing, we shouldn't use *debug* messages for this.

Simo.

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




More information about the sssd-devel mailing list