sssd-users August 2022

sssd-users@lists.fedorahosted.org

4 participants
3 discussions

[SSSD] Announcing SSSD 2.7.4
by Pavel Březina 26 Aug '22

26 Aug '22

# SSSD 2.7.4 The SSSD team is announcing the release of version 2.7.4 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.7.4 See the full release notes at: https://sssd.io/release-notes/sssd-2.7.4.html RPM packages will be made available for Fedora shortly. ## Feedback Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users ## Highlights ### General information * Lock-free client support will be only built if libc provides `pthread_key_create()` and `pthread_once()`. For glibc this means version 2.34+

1 0

authentication to an intentionally "broken" LDAP server
by Jarett DeAngelis 26 Aug '22

26 Aug '22

Hi everyone, I am trying to get SSSD to auth against an LDAP service provided by an IAM SaaS company that goes out of its way to make its LDAP interface as minimal as possible. All I want SSSD to do is check usernames and passwords against the service (which allows the systems in question to be secured by MFA) and grab UIDs and GIDs from two specified attributes in each user object. It seems to be able to connect fine, but it seems to choke on some missing attributes, as seen in these logs: ``` (2022-08-20 21:17:18): [be[test.ldap]] [sdap_get_generic_op_finished] (0x0400): [RID#6930] Search result: Insufficient access(50), no errmsg set (2022-08-20 21:17:18): [be[test.ldap]] [sdap_get_generic_op_finished] (0x0040): [RID#6930] Unexpected result from ldap: Insufficient access(50), no errmsg set * ... skipping repetitive backtrace ... (2022-08-20 21:17:18): [be[test.ldap]] [generic_ext_search_handler] (0x0020): [RID#6930] sdap_get_generic_ext_recv request failed: [5]: Input/output error * ... skipping repetitive backtrace ... (2022-08-20 21:17:18): [be[test.ldap]] [sdap_get_server_opts_from_rootdse] (0x0200): [RID#6930] No known USN scheme is supported by this server! (2022-08-20 21:17:18): [be[test.ldap]] [sdap_cli_auth_step] (0x0100): [RID#6930] expire timeout is 900 (2022-08-20 21:17:18): [be[test.ldap]] [sdap_cli_auth_step] (0x1000): [RID#6930] the connection will expire at 1661045538 (2022-08-20 21:17:18): [be[test.ldap]] [simple_bind_send] (0x0100): [RID#6930] Executing simple bind as: uid=ldap-bind,ou=users,dc=test,dc=ldap (2022-08-20 21:17:19): [be[test.ldap]] [simple_bind_done] (0x0080): [RID#6930] ldap_parse_passwordpolicy_control failed. (2022-08-20 21:17:19): [be[test.ldap]] [sdap_cli_connect_recv] (0x0040): [RID#6930] Unable to establish connection [1432158209]: Internal Error * ... skipping repetitive backtrace ... (2022-08-20 21:17:19): [be[test.ldap]] [fo_set_port_status] (0x0100): [RID#6930] Marking port 636 of server 'test.ldap' as 'not working' (2022-08-20 21:17:19): [be[test.ldap]] [fo_set_port_status] (0x0400): [RID#6930] Marking port 636 of duplicate server 'test.ldap' as 'not working' ``` sssd.conf is as shown: [sssd] services = nss, pam config_file_version = 2 domains = test.ldap [nss] [pam] [domain/test.ldap] debug_level = 7 ldap_id_use_start_tls = True cache_credentials = True ldap_search_base = ou=users,dc=test,dc=ldap id_provider = ldap auth_provider = ldap chpass_provider = ldap access_provider = permit #sudo_provider = ldap ldap_uri = ldaps://test.ldap ldap_default_bind_dn = uid=ldap-bind,ou=users,dc=test,dc=ldap ldap_default_authtok = some_good_password ldap_user_uid_number = employeeNumber ldap_user_gid_number = managerNumber ldap_user_name = uid ldap_tls_reqcert = allow ldap_tls_cacert = /etc/pki/tls/cacert.crt ldap_tls_cacertdir = /etc/pki/tls ldap_search_timeout = 50 ldap_network_timeout = 60 #ldap_access_order = filter #ldap_access_filter = (objectClass=inetOrgPerson) auto_private_groups = true Can someone help me figure out how to get around this? Open to all solutions including doing something with a server in between proxying communications between the "broken" LDAP server and our equipment.

2 3

RFE: option to not block all permitted users and groups if an unknown domain entered...
by Spike White 22 Aug '22

22 Aug '22

sssd personnel, When a Linux SE fat-fingers the domain name when doing a 'realm permit' or 'realm permit -g', it locks all permitted users and groups. Even worse, it's not usually obvious from looking at the 'simple_allow_users' and 'simple_allow_groups' lines which entry is the culprit. Here's an example: simple_allow_groups = amerlinuxsup(a)amer.company.com, amerlinuxeng(a)amer.company.com, emealinuxsup(a)emea.company.com, emealinuxeng(a)emea.company.com, apaclinuxsup(a)apac.company.com, apaclinuxeng(a)apac.company.com, gbllinuxsuppw(a)amer.company.com, pptsupportpac(a)amer.company.com, unv_legato_admins(a)amer.company.com, scheduling_global(a)amer.company.com, amerlinuxengtfssupt(a)amer.company.com, amerlnxsvcdelauttfs(a)apac.company.com, fnms_ops(a)amer.company.com, zabbix-support(a)amer.company.com, bladelogic_linux_users(a)amer.company.com, iasnprod(a)amer.company.com, unv_dba_login(a)amer.company.com, engit-ebpa(a)amer.company.com simple_allow_users = processehcprofiler(a)amer.company.com, svc_prdautovm(a)amer.company.com, processfoglight(a)amer.company.com, svc_prdprofoglight01(a)amer.company.com, service_ome_linux(a)amr.company.com, svc_prdesquadscounix(a)apac.company.com, admmmikolaj(a)amer.company.com The offending entry is 'service_ome_linux(a)amr.company.com'. The Linux SE fat-fingered that user when doing a realm permit. Since sssd treats this as an unknown domain (to sssd), it locks all permitted users and groups. I've tried to submit this to my OS vendor as a bug, but they claim it's a 'feature'. Ok, but it would be nice to have a configuration option to ignore permitted users and groups from unknown realms -- to not lock all existing permitted users and groups. Spike

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users August 2022