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

[Stef Walter]

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

Sure:

python -c "my code"

:)

Stef