[ale] [EXTERNAL] Re: Any AD + SSSD expertise?

Thu Aug 31 14:13:44 EDT 2023

So, this is our old LDAP sssd.conf  - there is a lot of custom mappings etc... done there, which were done by someone who retired years ago, and one of my co-workers, to get it working with our old heavily customized legacy LDAP.

[sssd]
config_file_version = 2
services = nss,pam
sbus_timeout = 30
domains = default

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

[domain/default]
#debug_level = 9
enumerate = false
ldap_id_use_start_tls = false
ldap_schema = rfc2307bis
ldap_search_base = search base info
id_provider = ldap
access_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap.url.ua.edu
cache_credentials = True
#ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_tls_reqcert = never
ldap_default_bind_dn = connector-username
ldap_default_authtok = connector-password
ldap_user_search_base = search base info
ldap_access_filter = custom
ldap_user_gid_number = custom
ldap_user_gecos = cn
ldap_user_home_directory = custom
ldap_user_shell = custom
ldap_group_search_base = group search base info
ldap_netgroup_search_base = netgroup search base info

This is what I'm working with on the new one for AD (I know it isn't secured, this is just the "get it working first" sandbox system)
[sssd]
config_file_version = 2
services = nss,pam
domains = example-domain.ua.edu

[nss]
fallback_homedir = /home/%u
default_shell = /bin/bash

[pam]
[domain/example-domain.ua.edu]
debug_level = 5
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://example-domain.ua.edu
ldap_search_base = search base info
ldap_default_bind_dn = connector account
ldap_default_authtok_type = password
ldap_default_authtok = connector password
ldap_user_object_class = person
ldap_group_object_class = group
ldap_schema = ad
ldap_referrals = False
ldap_id_mapping = True
enumerate = false
cache_credentials = true
ldap_id_use_start_tls = false
ldap_tls_reqcert = never
#ldap_tls_cacert specifies the file containing the certificate
#ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt

--
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251
allen at ua.edu

________________________________________
From: Jeremy T. Bouse <jeremy.bouse at undergrid.net>
Sent: Thursday, August 31, 2023 1:04 PM
To: Atlanta Linux Enthusiasts
Cc: Allen Beddingfield
Subject: [EXTERNAL] Re: [ale] Any AD + SSSD expertise?

You don't often get email from jeremy.bouse at undergrid.net. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
One initial question that might determine if it's going to be extremely difficult is whether or not that old config was using the dynamic UID/GID mapping based on the SID or whether you had added those to the user/group DNs. We're in the process of moving systems as we rebuild the environment to use SSSD and we're using AD but we're planning to have a subdomain for the Linux systems to keep them separate from the Windows systems.

On Thu, Aug 31, 2023 at 1:59 PM Allen Beddingfield via Ale <ale at ale.org<mailto:ale at ale.org>> wrote:
So, we currently have our Linux systems using an old 389 Directory for authentication, and have to switch to AD authentication to retire that system.  I don't have any say in that matter, so authenticating to AD is the mandated solution that I have to get working.  Most of these systems are SUSE Linux Enterprise 15, with a few 12.x systems.
I got the old sssd.conf and nsswitch.conf working for LDAP 10+ years ago, and really just haven't looked at it since, as it has worked without any issue.  I'm not wanting to go through the process of adding everything to AD, doing kerberos, etc....  so this will be SSSD using AD as an LDAP source for authentication.  I've got that part working well.  However, I've got one annoyance.  With the LDAP setup, the users would just kind of look like local users, in that their primary group would be the local "users" group.  (This is SUSE, so all users get the same primary group of "users", instead of an individual group that corresponds to their username).
However, when configured against AD, the users' primary group is "Domain Users".  I'm trying to find some way to either duplicate the old behavior, or at least have "Domain Users" be something like "adusers" without the capital letters and space.  I saw a suggestion for functionality to implement the Red Hat style individual user groups, but that isn't really what I'm trying to accomplish.

Anyone ever done this, or have any idea how to accomplish something like this?
I asked ChatGPT, and got suggested some parameters for the config file that I think it just made up haha
Allen B.

--
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251
allen at ua.edu<mailto:allen at ua.edu>
_______________________________________________
Ale mailing list
Ale at ale.org<mailto:Ale at ale.org>
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--

Jeremy T. Bouse

Sr. DevOps Engineer

321.525.3280

UnderGrid.net<https://undergrid.net/>

[https://lh4.googleusercontent.com/HhH_XCkiHPpWFqwrCu1usqJKf42Pdk32atiscm1XYHxDDkEzjAIDbQL4i6rLRjjPrOGN3ZTEiOM12wqxuMnp4Xm-LD5peX9NauDbsxFCg9KEaLKBtGFthEWDZ0mfC_IWR31eSNTc3z46vF8t0g]<https://www.credly.com/badges/69208741-17c8-4876-a5c0-bcaa9078ba29>[https://lh6.googleusercontent.com/Hz_F-y2yqOdU_eEbifE_KdEz0rZ6sOstQpY7Leqjf1d3_sHs0iaYOugAacgr0N-akqIIBk5RLsJZYJ_Rs_hhY1kC1QMsF3XgeWk3rOSfdyNbKkS4MReHKp5A2uQEZORiimoG7BQPfbchgXhsHg]<https://www.credly.com/badges/8613a442-3830-42c9-a629-8e1576dfec5e>