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

Yassir Elley yelley at redhat.com
Wed Apr 16 19:56:32 UTC 2014



----- Original Message -----
> On Tue, Apr 15, 2014 at 07:05:10PM -0400, Yassir Elley wrote:
> > 
> > 
> > ----- Original Message -----
> > > 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.
> > > 
> > > --
> > 
> > Hi Sumit,
> > 
> > As you know, the gpo-ldap patch you reviewed does not actually perform an
> > access control check (it only determines which GPOs are applicable to the
> > policy target). Enforcing the access control requires retrieval of files
> > via SMB, which will be in a subsequent gpo-smb patch. As such, I am
> > thinking that it would make more sense to postpone implementation of this
> > config option until the gpo-smb patch, at which time the config option can
> > actually be tested. Do you agree?
> 
> Well, the config option can be tested by watching the log files even
> now.  But I think it is ok to add them with your next round of patches
> since the current one will "only" go to master. But please note that
> people still might have issues with it because failures in the GPO code
> will lead to access denied.
> 
> I you prefer you can send the patch for the new option in a separate
> patch as well.
> 
> bye,
> Sumit
> 

Actually, I agree that it may be useful to disable gpo settings. As such, I will include the config option with this patch. "Disabled" mode will not perform any gpo processing, while "permissive" mode and "enforcing" mode *will* perform gpo processing (which doesn't currently include any enforcement). Once the gpo-smb patch is complete (i.e. once gpo evaluation and enforcement are implemented), the semantics for the gpo_access_control_mode config option will be:
* "disabled":   no gpo evaluation or gpo enforcement
* "permissive": gpo evaluation, but no gpo enforcement (if access would be denied, syslog message is output)
* "enforcing":  both gpo evaluation and gpo enforcement (if access is denied, access is denied!)

Regards,
Yassir.



More information about the sssd-devel mailing list