RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1944665 - No gpo found and ad_gpo_implicit_deny set to True still permits user login
Summary: No gpo found and ad_gpo_implicit_deny set to True still permits user login
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sssd
Version: 8.3
Hardware: All
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Sumit Bose
QA Contact: Dan Lavu
URL:
Whiteboard: sync-to-jira
Depends On:
Blocks: 1945656
TreeView+ depends on / blocked
 
Reported: 2021-03-30 12:49 UTC by ttuffin
Modified: 2024-10-01 17:48 UTC (History)
9 users (show)

Fixed In Version: sssd-2.5.0-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1945656 (view as bug list)
Environment:
Last Closed: 2021-11-09 19:47:10 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
gpo_policy_report (68.27 KB, text/html)
2021-06-03 12:02 UTC, Dan Lavu 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 5561 0 None open No gpo found and ad_gpo_implicit_deny set to True still permits user login 2021-03-30 15:50:16 UTC
Red Hat Product Errata RHBA-2021:4435 0 None None None 2021-11-09 19:47:40 UTC

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
Note You need to log in before you can comment on or make changes to this bug.