Bug 1944665

Summary: No gpo found and ad_gpo_implicit_deny set to True still permits user login
Product: Red Hat Enterprise Linux 8 Reporter: ttuffin
Component: sssdAssignee: Sumit Bose <sbose>
Status: CLOSED ERRATA QA Contact: Dan Lavu <dlavu>
Severity: high Docs Contact:
Priority: unspecified    
Version: 8.3CC: atikhono, dlavu, grajaiya, jhrozek, lslebodn, mzidek, pbrezina, sbose, tscherf
Target Milestone: rcKeywords: Triaged, ZStream
Target Release: ---Flags: pm-rhel: mirror+
Hardware: All   
OS: Linux   
Whiteboard: sync-to-jira
Fixed In Version: sssd-2.5.0-1.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1945656 (view as bug list) Environment:
Last Closed: 2021-11-09 19:47:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1945656    
Attachments:
Description Flags
gpo_policy_report none

Description ttuffin 2021-03-30 12:49:57 UTC 
Description of problem:
During testing of bz 1837020 on RHEL7 and RHEL8 I noticed that it is possible to login as any domain user when absolutely no GPO is applied to an OU and ad_gpo_implicit_deny is set to True.

I believe this differs slightly to bz 1868387 and bz 1837020 due to:
- bz 1837020 is caused when no applicable GPO's are found after cse filtering has taken place.
- bz 1868387 has applicable GPO's rules but none with an allow rule.
- Whereas this bug occurs when no GPO is applied to an OU in GPMC, without any cse filtering taking place.

I believe this is a corner-case since applying absolutely no GPO would be rare, but it does open up a possibility for unauthorised access to RHEL hosts due to misconfiguration with AD Group Policies. 


Version-Release number of selected component (if applicable):
sssd-2.3.0-9.el8.x86_64


How reproducible:
Always


Steps to Reproduce:
Tested against Windows Server 2019 build 17763

1. Join RHEL8 host to AD. Set `ad_gpo_implicit_deny = True` in sssd.conf and restart sssd.
2. In ADUC create new OU and move RHEL8 computer object to new OU.
3. Open GPMC, navigate to new OU and set Block Inheritance.
4. Ensure that no GPO's are set to enforcing. Checking the OU in GPMC should show no linked or inherited GPO's.
5. Try to login to RHEL8 host as AD user. Login works for any domain user.
6. In GPMC set any GPO to enforced, e.g. Default Domain Policy (it doesn't seem to matter if GPO has sssd specific settings defined)
7. Try to login to RHEL8 host again. Login should fail (as expected, for regular users).

Actual results:

When no GPO's are applied, access is granted unexpectedly:
(2021-03-30 12:41:47): [be[herge.local]] [ad_gpo_process_gpo_send] (0x0040): no gpos found
(2021-03-30 12:41:47): [be[herge.local]] [ad_gpo_process_gpo_done] (0x0400): No GPOs found that apply to this system.
(2021-03-30 12:41:47): [be[herge.local]] [ad_gpo_access_done] (0x0400): GPO-based access control successful.


When any GPO is applied, access is denied as expected:
(2021-03-30 12:40:42): [be[herge.local]] [ad_gpo_access_check] (0x0400):  access_granted = 0
(2021-03-30 12:40:42): [be[herge.local]] [ad_gpo_access_check] (0x0400):   access_denied = 0
(2021-03-30 12:40:42): [be[herge.local]] [ad_gpo_perform_hbac_processing] (0x0040): GPO access check failed: [1432158236](Host Access Denied)
(2021-03-30 12:40:42): [be[herge.local]] [ad_gpo_cse_done] (0x0040): HBAC processing failed: [1432158236](Host Access Denied}
(2021-03-30 12:40:42): [be[herge.local]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.

Expected results:
Whilst having no GPO's applied to a system in an AD domain is highly unlikely, it still allows unauthorised access to a RHEL8 host due to misconfiguration with Group Policies. I expect sssd to cover this scenario when `ad_gpo_implicit_deny` has been set to True.


Additional info:
This also occurs in RHEL7 running sssd-1.16.5-10.el7_9.7.x86_64.

My lab's sssd.conf:
[sssd]
full_name_format = %1$s
domains = herge.local
config_file_version = 2
services = nss, pam

[domain/herge.local]
ad_domain = herge.local
krb5_realm = HERGE.LOCAL
realmd_tags = manages-system joined-with-adcli
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
debug_level = 6
ad_gpo_implicit_deny = True
Comment 1 Sumit Bose 2021-03-30 13:50:55 UTC 
Hi,

thanks for the rigid testing, this is indeed a case which wasn't considered. I wonder if you can re-run your test with the build from http://brew-task-repos.usersys.redhat.com/repos/scratch/sbose/sssd/2.3.0/9.el8_3sb1/ ?

bye,
Sumit
Comment 2 ttuffin 2021-03-30 14:18:30 UTC 
Hi Sumit,

I re-ran my tests with this build and it appears the issue is resolved:

(2021-03-30 14:12:16): [be[herge.local]] [ad_gpo_process_gpo_send] (0x0040): no gpos found
(2021-03-30 14:12:16): [be[herge.local]] [ad_gpo_process_gpo_done] (0x0400): No GPOs found that apply to this system.
(2021-03-30 14:12:16): [be[herge.local]] [ad_gpo_process_gpo_done] (0x0400): No applicable GPOs have been found and ad_gpo_implicit_deny is set to 'true'. The user will be denied access.
(2021-03-30 14:12:16): [be[herge.local]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.

[root@ttuffin-vm-4 ~]# uname -r
4.18.0-240.el8.x86_64

[root@ttuffin-vm-4 ~]# rpm -qa | grep sssd
sssd-common-2.3.0-9.el8_3sb1.x86_64
sssd-krb5-2.3.0-9.el8_3sb1.x86_64
sssd-ipa-2.3.0-9.el8_3sb1.x86_64
sssd-nfs-idmap-2.3.0-9.el8.x86_64
python3-sssdconfig-2.3.0-9.el8_3sb1.noarch
sssd-client-2.3.0-9.el8_3sb1.x86_64
sssd-krb5-common-2.3.0-9.el8_3sb1.x86_64
sssd-ad-2.3.0-9.el8_3sb1.x86_64
sssd-ldap-2.3.0-9.el8_3sb1.x86_64
sssd-2.3.0-9.el8_3sb1.x86_64
sssd-common-pac-2.3.0-9.el8_3sb1.x86_64
sssd-proxy-2.3.0-9.el8_3sb1.x86_64
sssd-kcm-2.3.0-9.el8_3sb1.x86_64

Cheers,
Thomas
Comment 4 Sumit Bose 2021-03-30 15:44:32 UTC 
(In reply to ttuffin from comment #2)
> Hi Sumit,
> 
> I re-ran my tests with this build and it appears the issue is resolved:
> 
> (2021-03-30 14:12:16): [be[herge.local]] [ad_gpo_process_gpo_send] (0x0040):
> no gpos found
> (2021-03-30 14:12:16): [be[herge.local]] [ad_gpo_process_gpo_done] (0x0400):
> No GPOs found that apply to this system.
> (2021-03-30 14:12:16): [be[herge.local]] [ad_gpo_process_gpo_done] (0x0400):
> No applicable GPOs have been found and ad_gpo_implicit_deny is set to
> 'true'. The user will be denied access.
> (2021-03-30 14:12:16): [be[herge.local]] [ad_gpo_access_done] (0x0040):
> GPO-based access control failed.
> 
> [root@ttuffin-vm-4 ~]# uname -r
> 4.18.0-240.el8.x86_64
> 
> [root@ttuffin-vm-4 ~]# rpm -qa | grep sssd
> sssd-common-2.3.0-9.el8_3sb1.x86_64
> sssd-krb5-2.3.0-9.el8_3sb1.x86_64
> sssd-ipa-2.3.0-9.el8_3sb1.x86_64
> sssd-nfs-idmap-2.3.0-9.el8.x86_64
> python3-sssdconfig-2.3.0-9.el8_3sb1.noarch
> sssd-client-2.3.0-9.el8_3sb1.x86_64
> sssd-krb5-common-2.3.0-9.el8_3sb1.x86_64
> sssd-ad-2.3.0-9.el8_3sb1.x86_64
> sssd-ldap-2.3.0-9.el8_3sb1.x86_64
> sssd-2.3.0-9.el8_3sb1.x86_64
> sssd-common-pac-2.3.0-9.el8_3sb1.x86_64
> sssd-proxy-2.3.0-9.el8_3sb1.x86_64
> sssd-kcm-2.3.0-9.el8_3sb1.x86_64
> 
> Cheers,
> Thomas

Hi,

thanks for the fast testing, I'll prepare an upstream pull-request.

bye,
Sumit
Comment 7 Sumit Bose 2021-03-30 15:48:50 UTC 
Upstream ticket:
https://github.com/SSSD/sssd/issues/5561
Comment 11 Pavel Březina 2021-04-13 11:47:21 UTC 
* `master`
    * e865b008aa8947efca0116deb95e29cc2309256f - AD GPO: respect ad_gpo_implicit_deny if no GPO is present
Comment 12 Pavel Březina 2021-04-13 11:50:08 UTC 
Pushed PR: https://github.com/SSSD/sssd/pull/5562

* `master`
    * e865b008aa8947efca0116deb95e29cc2309256f - AD GPO: respect ad_gpo_implicit_deny if no GPO is present
Comment 13 Dan Lavu 2021-06-03 12:02:44 UTC 
Created attachment 1788832 [details]
gpo_policy_report
Comment 14 Dan Lavu 2021-06-03 12:03:56 UTC 
Tested against sssd-2.5.0-1.el8.x86_64

##### sssd.conf #####
[sssd]
domains = domain.com
config_file_version = 2
services = nss, pam

[domain/domain.com]
ad_domain = domain.com
krb5_realm = DOMAIN.COM
realmd_tags = manages-system joined-with-adcli 
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_implicit_deny = True
ad_gpo_access_control = enforcing

##### gpo config ##### 
PS C:\cygwin64\home\Administrator> Get-GPInheritance -Target "ou=test_ou,dc=domain,dc=com"
Get-GPInheritance -Target "ou=test_ou,dc=domain,dc=com"


Name                  : test_ou
ContainerType         : OU
Path                  : ou=test_ou,dc=domain,dc=com
GpoInheritanceBlocked : Yes
GpoLinks              : {}
InheritedGpoLinks     : {}



PS C:\cygwin64\home\Administrator> Get-GPInheritance -Target "dc=domain,dc=com" 
Get-GPInheritance -Target "dc=domain,dc=com" 


Name                  : domain.com
ContainerType         : Domain
Path                  : dc=domain,dc=com
GpoInheritanceBlocked : No
GpoLinks              : {Default Domain Policy, Disable-RC4-etype, hbac}
InheritedGpoLinks     : {Default Domain Policy, Disable-RC4-etype, hbac}



##### output #####
[root@ci-vm-10-0-99-216 cloud-user]# ssh allowed_user@localhost 
allowed_user@localhost's password: 
Connection closed by ::1 port 22

[root@ci-vm-10-0-99-216 cloud-user]# ssh denied_user@localhost 
denied_user@localhost's password: 
Connection closed by ::1 port 22

[root@ci-vm-10-0-99-216 cloud-user]# ssh regular_user@localhost 
regular_user@localhost's password: 
Connection closed by ::1 port 22
Comment 25 errata-xmlrpc 2021-11-09 19:47:10 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (sssd bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4435