0

I'm looking at altering some config of some Ubuntu machines that are using the SSSD package to bind to AD. As far as I understand, all ldap queries should be going through TSL from the config below.

Struggling to test this extensively as our live AD is pretty busy and hard to report against in real time. We only have vague reports that are harvested every few hours which still report my test machine as a problem.

I have been monitoring tcpdump there are still odd bits of information that are in clear text, but nothing sensitive just AD server locations and meta data being updated. It's seems to be just arbitrary information reporting ad servers when sssd.service is restarted.

If anyone can give any advice to ensure sssd with work against the up and coming Microsoft patch, I would be obviously very grateful.

[sssd]
domains = example.com
config_file_version = 2
services = nss, pam

[domain/example.com]
ad_domain = example.com
krb5_realm = example.com
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
rdns = false
dyndns_update_ptr = false
use_fully_qualified_names = False
#fallback_homedir = /home/%u@%d
access_provider = ad
override_homedir = /home/example/%u
ad_gpo_map_permit = +polkit-1
dyndns_update = True
default_domain_suffix = example.com
ignore_group_members = True

ldap_id_mapping = True
ldap_access_filter = (objectClass=user)

#ldap_uri = ldaps://example.com:636
ldap_uri = ldaps://example.com

ldap_search_base = DC=example,DC=com

# The file containing CA certificates you want sssd to trust.
ldap_tls_cacert = /etc/pki/rootCA.pem

# The TLS ciphers you wish to use. SSSD uses OpenSSL style cipher
# suites
ldap_tls_cipher_suite = HIGH

ldap_sasl_mech = GSSAPI
ldap_tls_reqcert = demand

1 Answer 1

0

If you are on something like Red Hat 8 and are trying to use ldaps, verify the TLS on the back end is 2048-bit or higher and supports modern DH Ciphers. If not, set opensslcnf.config from SECLEVEL=2 to 1.

Alternatively, if you have joined the domains and have a working keytab, you can use GSSAPI encryption over ldap. This negates the need to have bind credentials in the clear.

You'll need to choose one type of authentication for each domain section and verify all settings are compatible. Pay close attention to the man pages for these as some are completely incompatible with other settings. These are just the variables I flip in automation based on auth type. There are many more but these are most relevant based on what you provided.

auth_provider (ldap or ad most likely based on your use case)
ldap_id_mapping (false is mostly used for the old unix tab attributes)
id_provider (ad will use GSSAPI.  start_tls will most likely fail though)
ldap_user_name (uid for rfc2307, rfc2307bis, and IPA.  sAMAccountName for AD)
ldap_group_name (cn for rfc2307, rfc2307bis, and IPA.  sAMAccountName for AD)
1
  • Thanks for reply Allen, hopefully can actually do more testing with this soon and report back.
    – jamboNum5
    Nov 26, 2020 at 15:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .