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