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

[Stephen Gallagher]

> On Oct 7, 2014, at 5:05 AM, Stef Walter <stefw at gnome.org> wrote:
> 
> -----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?
> 

SSSD will not have any issue with it.  There is a chance that the SSSDConfig Python API will, though. The easiest thing to do might be to just ask the SSSDConfig API if it recognizes the option and use it if so. Is there an easy way to call out to Python code?


> Stef
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iEYEARECAAYFAlQzrNcACgkQe/sRCNknZa8UAgCgnmFKddZ/GHmViMw5uBKXYGIj
> ejYAoKO08Hb3bWtCEbGiWKQmP/jtjRyH
> =6JX5
> -----END PGP SIGNATURE-----
> _______________________________________________
> Authentication mailing list
> Authentication at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/authentication