Hi Sumit,

Thanks for taking the time to reply.

This morning I've done some further testing and found that granting the group "DOMAIN\Domain Computers" permissions to "Read remote access information" on the OU where the users who are going to authenticate against the SSSD clients works.

I've attached an image below, but I'm not sure if it'll be recorded for prosperity by the mailing list so explain it in text form too...

* Open Active Directory Users and Groups
* Navigate to the OU where your users are located (by default that'll be domain -> Users, but in a mature domain this is likely to be elsewhere. You could also do this at the root of the domain, but I'd not recommend it... privilege of least access and all that. Think about your highly privileged accounts, e.g. Domain Admins etc)
* Right click on the OU, click the Properties and select the Security tab.
* Click Advanced button
* Click Add
* Click "Select a principal". At this stage you need to make a decision.. which principle should I use? You could use Domain Computers, but you may feel this is too wide a group as it contains all the computers in the domain. At the opposite end of the spectrum you could use the computer account of the SSSD client (ie, the computers name); this would be a very narrow scoped permission which would allow ssd to work.. but could cause an administrative headache when adding additional SSSD clients. A sensible middle group might be to create a group (eg, "SSD Clients"), use that as the principle for this permission and then add all your SSSD clients to this group.
* Select "Type" as "Allow"
* Select "Applies" To as "Descendant User objects"
* Select "Read remote access information" and make sure all other boxes are ticked.

I found the GUI would by default tick all the Read permissions by default. To save me having to untick everything I made sure all the boxes in the Permissions section were Unticked, then switched "Applies to" from "Descendant User objects" to "Descendant Trusted Domain objects" and back to "Descendant User objects", this would untick everything. Then I could just tick "Read remote access information"

image.png

Regards

Steve

On Fri, 12 Jul 2024 at 08:52, Sumit Bose <sbose@redhat.com> wrote:
Am Thu, Jul 11, 2024 at 05:53:56PM +0100 schrieb Steve Scotter:
> Hi,
>
> This is likely a newbie issue and I apologize in advance. I've only been
> working with sssd for a matter of weeks and until I hardened Active
> Directory (as a result of an internal penetration test) sssd had been
> reliable and robust.
>
> Over the past few days I've been harding an Active Directory in a testing
> environment. It seems as though removing "Authenticated Users" from
> "Pre-Windows 2000 Compatible Access" (as is recommended best practice)
> breaks sssd's ability to perform group enumeration.
>
> With "Authenticated Users" in "Pre-Windows 2000 Compatible Access" group
>
> # id firstname.lastname
> uid=XXXXX01148(firstname.lastname) gid= XXXXX00513(domain users)
> groups=XXXXX01605(redactedgroup1),XXXXX01267(redactedgroup2),XXXXX02621(redactedgroup3),XXXXX01230(redactedgroup4),XXXXX00513(domain
> users),XXXXX01154(redactedgroup5),XXXXX01257(redactedgroup6),XXXXXX01307(redactedgroup7),XXXXX01156(redactedgroup8),XXXXX01111(redactedgroup9)
>
> With "Authenticated Users" removed from the "Pre-Windows 2000 Compatible
> Access" group
>
> # id  firstname.lastname
> uid=XXXXX01148(firstname.lastname) gid=XXXXX00513(domain users)
> groups=XXXXX00513(domain users)

Hi,

to be able to determine the group memberships of a user the `memberOf`
attribute must be read. Since SSSD in your configuration is using the
tokenGroups request I guess 'tokenGroupsGlobalAndUniversal' must be
allowed as well.

When joining AD a computer account for the client is created which SSSD
is using to authenticate against AD to do LDAP searches. So I guess if
you would add the 'Domain Computers' group (or a group which contains
all SSSD clients) to 'Pre-Windows 2000 Compatible Access' after removing
'Authenticated User' and restart SSSD (or wait for about 20 minutes
because SSSD should be default reconnect to AD every 15 minutes) the
group list is hopefully shown again.

As an alternative you can try to give permissions to the group of SSSD
clients to read the mentioned attributes explicitly. But this might be a
bit try and error because I not sure if the two mentioned are sufficient
of if more are needed.

HTH

bye,
Sumit

>
> I've had a good rummage around the internet, but not found a solution, or
> even anyone else reporting this issue before.
>
> Any help gratefully received!
>
> Active Directory is Windows Server 2022 based.
>
> Test client machines
> Debian 12 - sssd v2.8.2-4
> Ubuntu 22 - sssd v2.6.3-1ubuntu3.3
>
> # cat /etc/sssd/sssd.conf
>
> [sssd]
> domains = redacted.co.uk
> config_file_version = 2
> services = nss, pam
> default_domain_suffix = redacted.co.uk
> full_name_format = %1$s
>
> [domain/redacted.co.uk]
> default_shell = /bin/bash
> krb5_store_password_if_offline = True
> cache_credentials = True
> krb5_realm = REDACTED.CO.UK
> realmd_tags = manages-system joined-with-adcli
> id_provider = ad
> fallback_homedir = /home/%u
> override_homedir = /home/%u
> ad_domain = redacted.co.uk
> use_fully_qualified_names = True
> ldap_id_mapping = True
> access_provider = ad
> # So that ssh public keys works when a users key is stored in
> altSecurityIdentities
> ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
> ldap_user_ssh_public_key = altSecurityIdentities
> # Removes requirement for host to communicate with DC's over port 445
> ad_gpo_access_control = disabled
> # Removes requirement for host to communicate with DC's over port 3268
> ad_enable_gc = false
>
> Kind Regards
>
> Steve

> --
> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

--
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue