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

[Stef Walter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

Stef

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlQyhQYACgkQe/sRCNknZa+r2gCggVisJjXb9+mOKmWhbaXWEH7V
clAAoJhOboWOHuYurTOCYCMD9Xa2NwoH
=+hk3
-----END PGP SIGNATURE-----