SSSD incorrectly works with AD GPO during user login #5708

qwert1qwert · 2021-07-08T21:28:42Z

Hi,

We use GPOs to allow/deny user access to our servers. GPOs are linked to servers container and in their "Security filters" are only groups which contain necessary servers. Users can't read this GPO because of another container and security filter.
Everything works good for Windows machines - as it should be. However, on Linux machines SSSD requires that user have a permission to read this GPO.
If user can't read this GPO and we add ad_gpo_ignore_unreadable=true option, than any domain user will be able to login to servers which apply this policy. If we set ad_gpo_ignore_unreadable=false (or just remove it), all domain users can't login to servers which apply this policy.

This policy contains only server's part and is in container which shouldn't be applied to users.

OS: Centos 7
SSSD: 1.16.5

alexey-tikhonov · 2021-07-09T09:17:38Z

Hi,

could you please test if this scenario works for you with 2.x based SSSD? (Modern Fedora, CentOS stream, etc)

qwert1qwert · 2021-07-09T10:22:03Z

I'll test it on the Weekend

qwert1qwert · 2021-07-11T16:07:02Z

Looks like on last versions everything works good:

Centos Stream
sssd 2.5.1

Is it possible to install sssd 2.5.1 on Centos 7? Our main Linux OS is still Centos 7.

qwert1qwert · 2021-07-11T16:29:27Z

Sorry, I was mistaken. It doesn't work too. But in this case any domain user can't login at all.

alexey-tikhonov · 2021-07-11T16:50:59Z

Unfortunately I'm not fluent in GPO.
Could you please comment if this is relevant to #5181 and #5561?

qwert1qwert · 2021-07-11T18:54:05Z

No, it is different.
Let me try to explain more detailed.

For example, we such organization units structure:
domain root
|-company
|--servers
|--users
We have server server1 under "servers" OU and user1 under "users" OU.
Any OU may have linked GPO(s).
Servers under OU "server" will try to read and apply all GPOs under "domain root", "company", "servers". Of course they will read and apply only GPO with proper permissions. Servers will use only "Computer configuration" part of GPOs. Users may have permissions on these GPOs or may not - it doesn't matter.
Users under OU "users" will try to read and apply all GPOs under "domain root", "company", "users". The server must be able to read all GPOs which are applicable for user, but there system will apply only "User configuration" part of GPOs.

When server1 logins to domain, it reads appropriate GPOs and see which domain groups have permissions to login remotely/locally on it from "Computer configuration" part of GPOs. When user1 logins to domain, server1 gets and applies for him necessary GPOs. If the same items are configured in "Computer configuration" and "User configuration", than computer part has more priority.

So, server and user in this scenario may have common GPOs (under "domain root", "company"), some GPOs will be applied only while server itself logons to domain (under "servers") and some of GPOs will be applied only during user logon (under "users").

That is how it works for Windows-based machines. In Linux SSSD tries to apply during user logon GPOs under OU "servers" which shouldn't be touched by the system at this moment at all.

sumit-bose · 2021-08-03T12:17:05Z

Hi,

thanks for the detailed explanation. Do I understand correctly that you removed the default permissions for 'Authenticated Users' from the GPOs in 'servers' and replaced it with something which only applies to host objects?

bye,
Sumit

qwert1qwert · 2021-08-03T12:59:51Z

Hi,

Yes, it's correct. We want to apply the GPO only to specific server groups.

panlinux · 2022-11-10T21:23:48Z

@qwert1qwert have you tried the ad_gpo_ignore_unreadable option? If I understood it correctly, when the user logs in, sssd is trying to apply the server gpos, but those can't be read with the user credentials, and shouldn't be applied anyway, because they were applied already when the "server logs in"?

panlinux · 2022-11-10T21:24:50Z

Sorry, you said you tried it, never mind.

panlinux · 2022-11-11T18:04:05Z

@qwert1qwert could you be affected by https://support.microsoft.com/en-us/topic/ms16-072-security-update-for-group-policy-june-14-2016-7570425d-d460-3003-b2ac-a464c874725d? What is the security filtering you have on each group policy object, did you add Domain Computers as suggested in that advisory?

qwert1qwert · 2022-11-11T22:22:59Z

No, it is completely different.
I don't have user's GPOs, only computer's. It allows to login exact group of users but it is computer's part of GPO.

alexey-tikhonov · 2023-08-29T09:07:44Z

Hi @qwert1qwert,
is it still an issue for you? Did you figure out anything else worth mentioning here?

sumit-bose · 2023-09-14T11:21:34Z

Hi,

I think I have an idea what is wrong here. Currently SSSD is only checking for the host itself but does not include the groups the host is a member of in the evaluation (in contrast to the groups the user is a member of).

@qwert1qwert, if you still have a chance to check this I wonder if you can add the host itself to the Security Filtering together with the hostgroup and check if it is then working as expected.

bye,
Sumit

Resolves: SSSD#5708

With this patch the group-memberships of the client running SSSD are included in the evaluation of the security filtering. Similar as in AD the host object is more or less handled as a user object which allows to skip some code dedicated to computers only. Resolves: SSSD#5708

The related calls are not needed anymore. Resolves: SSSD#5708

Resolves: SSSD#5708

With this patch the group-memberships of the client running SSSD are included in the evaluation of the security filtering. Similar as in AD the host object is more or less handled as a user object which allows to skip some code dedicated to computers only. Resolves: SSSD#5708

The related calls are not needed anymore. Resolves: SSSD#5708

With this patch the group-memberships of the client running SSSD are included in the evaluation of the security filtering. Similar as in AD the host object is more or less handled as a user object which allows to skip some code dedicated to computers only. Resolves: SSSD#5708

The related calls are not needed anymore. Resolves: SSSD#5708

Resolves: SSSD#5708

With this patch the group-memberships of the client running SSSD are included in the evaluation of the security filtering. Similar as in AD the host object is more or less handled as a user object which allows to skip some code dedicated to computers only. Resolves: SSSD#5708

The related calls are not needed anymore. Resolves: SSSD#5708

This patch adds a new parameter set_non_posix to the user and group lookup calls. Currently the domain type is used to determine if the search should be restricted to POSIX objects or not. The new option allows to drop this restriction explicitly to look up non-POSIX objects. Resolves: SSSD#5708

The related calls are not needed anymore. Resolves: #5708 Reviewed-by: Justin Stephenson <jstephen@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit ff23e7e) Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com>

This patch adds a new parameter set_non_posix to the user and group lookup calls. Currently the domain type is used to determine if the search should be restricted to POSIX objects or not. The new option allows to drop this restriction explicitly to look up non-POSIX objects. Resolves: #5708 Reviewed-by: Justin Stephenson <jstephen@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit 5f63d9b) Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com>

alexey-tikhonov · 2024-01-31T09:58:12Z

Pushed PR: #7131

sssd-2-8
- 0338470 - sdap: add set_non_posix parameter
- 597d193 - sysdb: remove sysdb_computer.[ch]
- 5635a8c - ad: gpo evalute host groups
- 2e02801 - LDAP: make groups_by_user_send/recv public

AD handles users and computer objects very similar and so does SSSD's GPO code when lookup up the host's group-memberships. But users and computers might be stored in different sub-tree of the AD LDAP tree and if a dedicated user search base is given with the ldap_user_search_base option in sssd.conf the host object might be in a different sub-tree. To make sure the host can still be found this patch uses the base DN of the LDAP tree when searching for hosts in the GPO code. Resolves: SSSD#5708

The naming_context could be a more reliable source than basedn for the actual base DN because basedn is set very early from the domain name given in sssd.conf. Although it is recommended to use the fully qualified DNS domain name here it is not required. As a result basedn might not reflect the actual based DN of the LDAP server. Also pure LDAP server (i.e. not AD or FreeIPA) might use different schemes to set the base DN which will not be based on the DNS domain of the LDAP server. Resolves: SSSD#5708

AD handles users and computer objects very similar and so does SSSD's GPO code when lookup up the host's group-memberships. But users and computers might be stored in different sub-tree of the AD LDAP tree and if a dedicated user search base is given with the ldap_user_search_base option in sssd.conf the host object might be in a different sub-tree. To make sure the host can still be found this patch uses the base DN of the LDAP tree when searching for hosts in the GPO code. Resolves: #5708 Reviewed-by: Alejandro López <allopez@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com>

The naming_context could be a more reliable source than basedn for the actual base DN because basedn is set very early from the domain name given in sssd.conf. Although it is recommended to use the fully qualified DNS domain name here it is not required. As a result basedn might not reflect the actual based DN of the LDAP server. Also pure LDAP server (i.e. not AD or FreeIPA) might use different schemes to set the base DN which will not be based on the DNS domain of the LDAP server. Resolves: #5708 Reviewed-by: Alejandro López <allopez@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com>

AD handles users and computer objects very similar and so does SSSD's GPO code when lookup up the host's group-memberships. But users and computers might be stored in different sub-tree of the AD LDAP tree and if a dedicated user search base is given with the ldap_user_search_base option in sssd.conf the host object might be in a different sub-tree. To make sure the host can still be found this patch uses the base DN of the LDAP tree when searching for hosts in the GPO code. Resolves: #5708 Reviewed-by: Alejandro López <allopez@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit 29a77c6)

The naming_context could be a more reliable source than basedn for the actual base DN because basedn is set very early from the domain name given in sssd.conf. Although it is recommended to use the fully qualified DNS domain name here it is not required. As a result basedn might not reflect the actual based DN of the LDAP server. Also pure LDAP server (i.e. not AD or FreeIPA) might use different schemes to set the base DN which will not be based on the DNS domain of the LDAP server. Resolves: #5708 Reviewed-by: Alejandro López <allopez@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit a153f13)

AD handles users and computer objects very similar and so does SSSD's GPO code when lookup up the host's group-memberships. But users and computers might be stored in different sub-tree of the AD LDAP tree and if a dedicated user search base is given with the ldap_user_search_base option in sssd.conf the host object might be in a different sub-tree. To make sure the host can still be found this patch uses the base DN of the LDAP tree when searching for hosts in the GPO code. Resolves: #5708 Reviewed-by: Alejandro López <allopez@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit 29a77c6)

The naming_context could be a more reliable source than basedn for the actual base DN because basedn is set very early from the domain name given in sssd.conf. Although it is recommended to use the fully qualified DNS domain name here it is not required. As a result basedn might not reflect the actual based DN of the LDAP server. Also pure LDAP server (i.e. not AD or FreeIPA) might use different schemes to set the base DN which will not be based on the DNS domain of the LDAP server. Resolves: #5708 Reviewed-by: Alejandro López <allopez@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit a153f13)

alexey-tikhonov · 2024-02-09T14:11:49Z

Pushed PR: #7145

master
- a153f13 - sdap: add naming_context as new member of struct sdap_domain
- 29a77c6 - sdap: add search_bases option to groups_by_user_send()
sssd-2-8
- 04c0279 - sdap: add naming_context as new member of struct sdap_domain
- 151ba69 - sdap: add search_bases option to groups_by_user_send()
sssd-2-9
- 6a8e60d - sdap: add naming_context as new member of struct sdap_domain
- a7621a5 - sdap: add search_bases option to groups_by_user_send()

struct sdap_search_base includes the DN as a string. To better compare the DNs it is better to use a struct ldb_dn, in addition to the string. The struct ldb_dn also needs to keep the associated struct ldb_context, so we are also storing it in the structure. Resolves: SSSD#5708 Reviewed-by: Sumit Bose <sbose@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit cfc591d)

struct sdap_search_base includes the DN as a string. To better compare the DNs it is better to use a struct ldb_dn, in addition to the string. The struct ldb_dn also needs to keep the associated struct ldb_context, so we are also storing it in the structure. Resolves: #5708 Reviewed-by: Sumit Bose <sbose@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit cfc591d) Reviewed-by: Alexey Tikhonov <atikhono@redhat.com>

alexey-tikhonov · 2024-02-26T13:43:24Z

Pushed PR: #7211

sssd-2-8
- 3800473 - SDAP: Include struct ldb_dn in struct sdap_search_base

Resolves: SSSD#5708 Reviewed-by: Justin Stephenson <jstephen@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit 9b73614) Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com>

With this patch the group-memberships of the client running SSSD are included in the evaluation of the security filtering. Similar as in AD the host object is more or less handled as a user object which allows to skip some code dedicated to computers only. Resolves: SSSD#5708 Reviewed-by: Justin Stephenson <jstephen@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit c02e09a) Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com>

The related calls are not needed anymore. Resolves: SSSD#5708 Reviewed-by: Justin Stephenson <jstephen@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit ff23e7e) Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com>

This patch adds a new parameter set_non_posix to the user and group lookup calls. Currently the domain type is used to determine if the search should be restricted to POSIX objects or not. The new option allows to drop this restriction explicitly to look up non-POSIX objects. Resolves: SSSD#5708 Reviewed-by: Justin Stephenson <jstephen@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit 5f63d9b) Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com>

AD handles users and computer objects very similar and so does SSSD's GPO code when lookup up the host's group-memberships. But users and computers might be stored in different sub-tree of the AD LDAP tree and if a dedicated user search base is given with the ldap_user_search_base option in sssd.conf the host object might be in a different sub-tree. To make sure the host can still be found this patch uses the base DN of the LDAP tree when searching for hosts in the GPO code. Resolves: SSSD#5708 Reviewed-by: Alejandro López <allopez@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit 29a77c6)

The naming_context could be a more reliable source than basedn for the actual base DN because basedn is set very early from the domain name given in sssd.conf. Although it is recommended to use the fully qualified DNS domain name here it is not required. As a result basedn might not reflect the actual based DN of the LDAP server. Also pure LDAP server (i.e. not AD or FreeIPA) might use different schemes to set the base DN which will not be based on the DNS domain of the LDAP server. Resolves: SSSD#5708 Reviewed-by: Alejandro López <allopez@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit a153f13)

struct sdap_search_base includes the DN as a string. To better compare the DNs it is better to use a struct ldb_dn, in addition to the string. The struct ldb_dn also needs to keep the associated struct ldb_context, so we are also storing it in the structure. Resolves: SSSD#5708 Reviewed-by: Sumit Bose <sbose@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit cfc591d) Reviewed-by: Alexey Tikhonov <atikhono@redhat.com>

Resolves: SSSD#5708 Reviewed-by: Justin Stephenson <jstephen@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit 9b73614) Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com>

With this patch the group-memberships of the client running SSSD are included in the evaluation of the security filtering. Similar as in AD the host object is more or less handled as a user object which allows to skip some code dedicated to computers only. Resolves: SSSD#5708 Reviewed-by: Justin Stephenson <jstephen@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit c02e09a) Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com>

The related calls are not needed anymore. Resolves: SSSD#5708 Reviewed-by: Justin Stephenson <jstephen@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit ff23e7e) Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com>

This patch adds a new parameter set_non_posix to the user and group lookup calls. Currently the domain type is used to determine if the search should be restricted to POSIX objects or not. The new option allows to drop this restriction explicitly to look up non-POSIX objects. Resolves: SSSD#5708 Reviewed-by: Justin Stephenson <jstephen@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit 5f63d9b) Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com>

AD handles users and computer objects very similar and so does SSSD's GPO code when lookup up the host's group-memberships. But users and computers might be stored in different sub-tree of the AD LDAP tree and if a dedicated user search base is given with the ldap_user_search_base option in sssd.conf the host object might be in a different sub-tree. To make sure the host can still be found this patch uses the base DN of the LDAP tree when searching for hosts in the GPO code. Resolves: SSSD#5708 Reviewed-by: Alejandro López <allopez@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit 29a77c6)

The naming_context could be a more reliable source than basedn for the actual base DN because basedn is set very early from the domain name given in sssd.conf. Although it is recommended to use the fully qualified DNS domain name here it is not required. As a result basedn might not reflect the actual based DN of the LDAP server. Also pure LDAP server (i.e. not AD or FreeIPA) might use different schemes to set the base DN which will not be based on the DNS domain of the LDAP server. Resolves: SSSD#5708 Reviewed-by: Alejandro López <allopez@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit a153f13)

struct sdap_search_base includes the DN as a string. To better compare the DNs it is better to use a struct ldb_dn, in addition to the string. The struct ldb_dn also needs to keep the associated struct ldb_context, so we are also storing it in the structure. Resolves: SSSD#5708 Reviewed-by: Sumit Bose <sbose@redhat.com> Reviewed-by: Tomáš Halman <thalman@redhat.com> (cherry picked from commit cfc591d) Reviewed-by: Alexey Tikhonov <atikhono@redhat.com>

alexey-tikhonov added the Needs triage label Aug 29, 2023

sumit-bose added a commit to sumit-bose/sssd that referenced this issue Dec 22, 2023

LDAP: make groups_by_user_send/recv public

5a49bdf

Resolves: SSSD#5708

sumit-bose added a commit to sumit-bose/sssd that referenced this issue Dec 22, 2023

sysdb: remove sysdb_computer.[ch]

0748d84

The related calls are not needed anymore. Resolves: SSSD#5708

sumit-bose mentioned this issue Dec 22, 2023

ad: gpo evalute host groups #7107

Closed

sumit-bose added a commit to sumit-bose/sssd that referenced this issue Jan 8, 2024

LDAP: make groups_by_user_send/recv public

0905019

Resolves: SSSD#5708

sumit-bose added a commit to sumit-bose/sssd that referenced this issue Jan 8, 2024

sysdb: remove sysdb_computer.[ch]

5d7a39a

The related calls are not needed anymore. Resolves: SSSD#5708

sumit-bose added a commit to sumit-bose/sssd that referenced this issue Jan 8, 2024

sysdb: remove sysdb_computer.[ch]

686ee45

The related calls are not needed anymore. Resolves: SSSD#5708

sumit-bose added a commit to sumit-bose/sssd that referenced this issue Jan 9, 2024

LDAP: make groups_by_user_send/recv public

4195d83

Resolves: SSSD#5708

sumit-bose added a commit to sumit-bose/sssd that referenced this issue Jan 9, 2024

sysdb: remove sysdb_computer.[ch]

5c3a260

The related calls are not needed anymore. Resolves: SSSD#5708

alexey-tikhonov closed this as completed in 9b73614 Jan 9, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SSSD incorrectly works with AD GPO during user login #5708

SSSD incorrectly works with AD GPO during user login #5708

qwert1qwert commented Jul 8, 2021

alexey-tikhonov commented Jul 9, 2021

qwert1qwert commented Jul 9, 2021

qwert1qwert commented Jul 11, 2021

qwert1qwert commented Jul 11, 2021

alexey-tikhonov commented Jul 11, 2021

qwert1qwert commented Jul 11, 2021 •

edited

sumit-bose commented Aug 3, 2021

qwert1qwert commented Aug 3, 2021

panlinux commented Nov 10, 2022

panlinux commented Nov 10, 2022

panlinux commented Nov 11, 2022

qwert1qwert commented Nov 11, 2022

alexey-tikhonov commented Aug 29, 2023

sumit-bose commented Sep 14, 2023

alexey-tikhonov commented Jan 31, 2024

alexey-tikhonov commented Feb 9, 2024

alexey-tikhonov commented Feb 26, 2024

SSSD incorrectly works with AD GPO during user login #5708

SSSD incorrectly works with AD GPO during user login #5708

Comments

qwert1qwert commented Jul 8, 2021

alexey-tikhonov commented Jul 9, 2021

qwert1qwert commented Jul 9, 2021

qwert1qwert commented Jul 11, 2021

qwert1qwert commented Jul 11, 2021

alexey-tikhonov commented Jul 11, 2021

qwert1qwert commented Jul 11, 2021 • edited

sumit-bose commented Aug 3, 2021

qwert1qwert commented Aug 3, 2021

panlinux commented Nov 10, 2022

panlinux commented Nov 10, 2022

panlinux commented Nov 11, 2022

qwert1qwert commented Nov 11, 2022

alexey-tikhonov commented Aug 29, 2023

sumit-bose commented Sep 14, 2023

alexey-tikhonov commented Jan 31, 2024

alexey-tikhonov commented Feb 9, 2024

alexey-tikhonov commented Feb 26, 2024

qwert1qwert commented Jul 11, 2021 •

edited