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.... ?
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.o...
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.o...
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.o...
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.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue