Done. Thanks!

On Fri, 12 Jul 2024 at 12:06, Sumit Bose <sbose@redhat.com> wrote:
Am Fri, Jul 12, 2024 at 10:03:35AM +0100 schrieb Steve Scotter:
> 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: image.png]

Hi,

thanks for the detailed explanation. To avoid that this information gets
lost on the mailing list I wonder if you would like to add it to the
documentation on sssd.io?

E.g. you can create a pull request and update
https://github.com/SSSD/sssd.io/blob/master/src/troubleshooting/ad_provider.rst?

bye,
Sumit

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



> --
> _______________________________________________
> 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