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

[Stephen Gallagher]

On Mon, 2014-10-06 at 14:03 +0200, Stef Walter wrote:
> On 06.10.2014 14:02, Stephen Gallagher wrote:
> > 
> > 
> > 
> > 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.
> 
> Ah I see. Agreed.



I don't see a reason to add "allow-any-login" at this point. It seems to
me that "trust the domain" and "use this whitelist" are probably
sufficient at this point.

I've attached a completely different (and much simpler...) patch that
ensures that 'ad_access_gpo_access_control = enforcing' no matter what
(since if we use 'realm permit <user>', this argument will just be
ignored).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Enable-GPO-enforcement-for-AD-provider.patch
Type: text/x-patch
Size: 1417 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/authentication/attachments/20141006/0d0a8781/attachment.bin>
-------------- 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/0d0a8781/attachment.sig>