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

[Stef Walter]

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

On 06.10.2014 21:05, Stephen Gallagher wrote:
> 
> 
> 
> 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.

Ok.

> 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).

Does sssd barf if you put a parameter it doesn't recognize in the
config file? If so, we would need to somehow account for this and or
have a specific sssd version requirement, no?

Stef

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

iEYEARECAAYFAlQzrNcACgkQe/sRCNknZa8UAgCgnmFKddZ/GHmViMw5uBKXYGIj
ejYAoKO08Hb3bWtCEbGiWKQmP/jtjRyH
=6JX5
-----END PGP SIGNATURE-----