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

Simo Sorce simo at redhat.com
Tue Apr 15 19:44:13 UTC 2014


On Tue, 2014-04-15 at 21:23 +0200, Jakub Hrozek wrote:
> On Tue, Apr 15, 2014 at 03:03:55PM -0400, Simo Sorce wrote:
> > > 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.
> 
> I realize changing a default in a minor release is not great, but 1.13
> will be at least 6 months from 1.12, realistically a year later..what is
> the point of a cool feature like GPO if nobody will use it?
> 
> > 
> > Interested users can always manually switch to enforcing on their own,
> > there is no need to rush this onto them.
> 
> I think most users will use whatever realmd sets up..I'm not sure, but
> is it still the simple access provider? Should we consider changing the
> default to 'ad' when we switch the GPO feature to 'enforcing' ?

If it is cool people will use it, also nobody will prohib Fedora/other
distro's to change the distro default.

So if 1.13.0 is not out yet when F22 ship, F22 can still just turn it
on.

> > > > * 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
> 
> This would sound like GPO is supported (or planned to be supported) by
> all backends. Compare entry_cache_timeout with ldap_search_timeout.

uhmm ok ad_gpo_access_control is ok as well, I think it is quite clear
that GPO is an AD specific technology, but I may be biased from years of
mental association :-)
 
> > > > * 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.
> 
> Fine, whatever is better visible to the admin. I was just trying to think
> as the poor locked out admin "Oh sssd denied access? tail
> /var/log/sssd/*.log".

Nothing prevent us from also emitting a debug message I guess, but
normally sssd debug logs are not enabled, and the system log is a better
place for these kind of messages.

Simo.

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




More information about the sssd-devel mailing list