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

Sumit Bose sbose at redhat.com
Wed Apr 16 06:59:20 UTC 2014


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

> 
> Thanks,
> Yassir.
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list