[Authentication] [PATCHES] Add realmd support for configuring the AD GPO access-control

Stephen Gallagher sgallagh at redhat.com
Mon Oct 6 05:02:05 PDT 2014




On Mon, 2014-10-06 at 14:00 +0200, Stef Walter wrote:
> On 06.10.2014 13:57, Stephen Gallagher wrote:
> > 
> > 
> > 
> > On Mon, 2014-10-06 at 07:51 +0200, Stef Walter wrote:
> >> On 02.10.2014 15:29, Stephen Gallagher wrote:
> >>> Patch 0001: Adds a routine to get a string from the
> >>> realmd.conf with a default value if it's not present.
> >> 
> >> Hmmm, I think defaults should be placed in 
> >> /usr/lib64/realmd/realmd-defaults.conf or 
> >> /usr/lib64/realmd/realmd-distro.conf, rather than in the code.
> >> 
> >> Was there a special reason for changing this?
> >> 
> > 
> > Mostly, I was trying to work around the potential .rpmsave
> > problem, but I realize on second look that the defaults are
> > actually in /usr not /etc, so they wouldn't be vulnerable to this
> > issue.
> > 
> >>> Patch 0002: Add the "enforce-gpo" option to the
> >>> [active-directory] section and use it to set the
> >>> ad_gpo_access_control setting in sssd.conf
> >> 
> >> Not sure what this does exactly, but I'm assuming it controls the
> >> HBAC setting for SSSD. In realmd, the choice whether to use
> >> domain provided HBAC is controlled via the 'realm permit ...'
> >> options (and related DBus interface), and not via a default in
> >> the configuration file.
> >> 
> > 
> > Well, it controls a trinary state: disabled, permissive or
> > enforcing. This is in addition to the other two access-control
> > features in the AD provider: account-lock and ldap-filter.
> > 
> > If you'd prefer that realmd just simply always set it to
> > 'enforcing' mode if 'realm permit -a' has been specified, I can do
> > that and update the patch accordingly.
> 
> I think that makes sense.
> 
> Related: I guess we don't have a command-line option for
> "allow-any-login" which would map to "permissive" in your trinary
> state ... I wouldn't be against such an option though.


Actually, that could map to either 'permissive' or 'disabled' and I'd
argue that 'disabled' would make more sense. 'permissive' goes through
all of the logic to do an enforcing check and then logs the result
instead of actually respecting it. That's a lot of overhead for anything
but a testing or migration case, I think.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/authentication/attachments/20141006/94ea6f3e/attachment.sig>


More information about the Authentication mailing list