On 2019-02-08 18:06, Michal Židek wrote:
> On 2/8/19 3:13 PM, Emil Petersson wrote:
>> Hi,
>>
>> I am trying to configure Active Directory integration with SSSD. AD
>> is running on 2016, and my clients are CentOS 7.6, running SSSD
>> 1.16.2-13.el7.
>>
>> I want to control client access using AD GPO.
>>
>> The issue I'm seeing is that any user is allowed to log on to the
>> client, regardless if they are allowed by a GPO or not.
>>
>> The clients were successfully joined to AD by running:
>> realm join --user=username
>> --computer-ou='OU=Linux,OU=Servers,OU=XXX,DC=XXX,DC=XXX,DC=net'
>>
xxx.xxx.net
>>
>> The client sssd.conf looks like this:
>>
>> [sssd]
>> domains =
xxx.xxx.net
>> config_file_version = 2
>> services = nss, pam
>> full_name_format = %1$s
>> default_domain_suffix =
xxx.xxx.net
>>
>> [
domain/xxx.xxx.net]
>> debug_level = 9
>> ad_domain =
xxx.xxx.net
>> krb5_realm =
XXX.XXX.NET
>> realmd_tags = manages-system joined-with-samba
>> cache_credentials = True
>> id_provider = ad
>> krb5_store_password_if_offline = True
>> default_shell = /bin/bash
>> ldap_id_mapping = True
>> use_fully_qualified_names = True
>> fallback_homedir = /home/%u@%d
>> access_provider = ad
>> ad_gpo_access_control = enforcing
>> dyndns_update = false
>>
>> When trying to log in with an unauthorized user, I get the following
>> output from SSSD debug:
>>
>> [ad_gpo_perform_hbac_processing] (0x4000): allow_key:
>> SeRemoteInteractiveLogonRight
>> [ad_gpo_perform_hbac_processing] (0x4000): deny_key:
>> SeDenyRemoteInteractiveLogonRight
>> [parse_policy_setting_value] (0x0400): No value for key
>> [SeRemoteInteractiveLogonRight] found in gpo result
>> [ad_gpo_access_check] (0x0400): RESULTANT POLICY:
>> [ad_gpo_access_check] (0x0400): gpo_map_type: Remote Interactive
>> [ad_gpo_access_check] (0x0400): allowed_size = 0
>> [ad_gpo_access_check] (0x0400): denied_size = 3
>> [ad_gpo_access_check] (0x0400): denied_sids[0] =
>> S-1-5-21-1107582786-1995068826-2594897426-4406
>> [ad_gpo_access_check] (0x0400): denied_sids[1] =
>> S-1-5-21-1107582786-1995068826-2594897426-4281
>> [ad_gpo_access_check] (0x0400): denied_sids[2] =
>> S-1-5-21-1107582786-1995068826-2594897426-4021
>> [ad_gpo_access_check] (0x0400): CURRENT USER:
>> [ad_gpo_access_check] (0x0400): user_sid =
>> S-1-5-21-1107582786-1995068826-2594897426-5609
>> [ad_gpo_access_check] (0x0400): group_sids[0] =
>> S-1-5-21-1107582786-1995068826-2594897426-5611
>> [ad_gpo_access_check] (0x0400): group_sids[1] =
>> S-1-5-21-1107582786-1995068826-2594897426-513
>> [ad_gpo_access_check] (0x0400): group_sids[2] =
>> S-1-5-21-1107582786-1995068826-2594897426-5612
>> [ad_gpo_access_check] (0x0400): group_sids[3] = S-1-5-11
>> [ad_gpo_access_check] (0x0400): POLICY DECISION:
>> [ad_gpo_access_check] (0x0400): access_granted = 1
>> [ad_gpo_access_check] (0x0400): access_denied = 0
>> [ad_gpo_access_done] (0x0400): GPO-based access control successful.
>>
>> I'm not understanding what's happening here. It's as if my test user
>> is allowed by default. Could this be due to a PAM config?
>>
>> I was expecting to be denied login until I've explicitly setup a GPO
>> to allow login :)
>>
>> Any help is much appreciated!
>> _______________________________________________
>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
>> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>>
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
>>
>>
>
> (ok, one more time now with the sssd-users list included :) )
>
> I think the implicit access granted is given when no policy applicable
> to the user is found. There is option to change this to implicit
> deny with:
> ad_gpo_implicit_deny = True
>
> This is relatively new option not sure if it is available for your
> version (see 'man sssd-ad' if the option is available).
>
> If you add at least one "allow" GPO rule that applies to the user
> (but does not list the user as allowed user, for example
> if there is only Administrator allowed), then the user
> would be denied access (the implicit allow would not
> apply).
>
> I see some deny rules were found, but those only say that
> this user is not among those with denied access.
>
> Michal
Thank you Michal, this explains the behaviour I'm seeing!
The reason for my issues was that my GPO use Security Filtering with
Computer objects in them. This is unsupported, as stated in the man page
as well as on
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
.
Do you know if there are plans for implementing support for GPO's with
Security Filtering on computer object in future versions of SSSD?
Thanks!
It is currently not planned for any near future release. But
we do track it here:
As with everything it comes down to priority and this does not
have any at the moment.
Michal