sssd-users

sssd-users@lists.fedorahosted.org

1 participants
1832 discussions

Server is unwilling to perform(53)
by Rodrigo Prieto 03 Feb '25

03 Feb '25

Hello, I have an OpenLDAP server with anonymous access disabled. When I check the SSSD logs, I see that it makes an anonymous query for certain attributes, resulting in the following error: * (2025-02-01 5:45:50): [be[LDAP]] [sdap_connect_done] (0x0080): START TLS result: Success(0), (null) * (2025-02-01 5:45:50): [be[LDAP]] [sdap_op_destructor] (0x2000): Operation 1 finished * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_rootdse_send] (0x4000): Getting rootdse * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 2 * (2025-02-01 5:45:50): [be[LDAP]] [sdap_op_add] (0x2000): New operation 2 timeout 6 * (2025-02-01 5:45:50): [be[LDAP]] [sdap_process_result] (0x2000): Trace: sh[0x5562b7500710], connected[1], ops[0x5562b7494520], ldap[0x5562b74feb80] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_process_result] (0x2000): Trace: end of ldap_result list * (2025-02-01 5:45:50): [be[LDAP]] [sdap_process_result] (0x2000): Trace: sh[0x5562b7500710], connected[1], ops[0x5562b7494520], ldap[0x5562b74feb80] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_process_result] (0x2000): Trace: end of ldap_result list * (2025-02-01 5:45:50): [be[LDAP]] [sdap_process_result] (0x2000): Trace: sh[0x5562b7500710], connected[1], ops[0x5562b7494520], ldap[0x5562b74feb80] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_process_result] (0x2000): Trace: end of ldap_result list * (2025-02-01 5:45:50): [be[LDAP]] [sdap_process_result] (0x2000): Trace: sh[0x5562b7500710], connected[1], ops[0x5562b7494520], ldap[0x5562b74feb80] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_op_finished] (0x0400): Search result: Server is unwilling to perform(53), authentication required * (2025-02-01 5:45:50): [be[LDAP]] [sdap_get_generic_op_finished] (0x0040): Unexpected result from ldap: Server is unwilling to perform(53), authentication required If I enable anonymous access, this error does not appear. In my sssd.conf configuration, I am using binddn and password. Is there any way to disable these queries, or is it mandatory for the OpenLDAP server to allow anonymous access? Best regards.

2 1

/var/lib/sss/pubconf/kpasswdinfo.$DOMAIN missing
by Brian J. Murrell 31 Jan '25

31 Jan '25

I am trying to start the krenew user service from the kstart package but it's failing due to krenew failing. Using strace to see what is going on with it I ends as such: openat(AT_FDCWD, "/var/lib/sss/pubconf/kdcinfo.EXAMPLE.COM", O_RDONLY) = 3 read(3, "[redacted]\n[fd31:aeb1:48"..., 4096) = 77 read(3, "", 4019) = 0 close(3) = 0 openat(AT_FDCWD, "/var/lib/sss/pubconf/kpasswdinfo.EXAMPLE.COM", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "krenew: ", 8krenew: ) = 8 write(2, "error renewing credentials: KDC "..., 62error renewing credentials: KDC can't fulfill requested option) = 62 write(2, "\n", 1 ) = 1 exit_group(1) = ? +++ exited with 1 +++ It seems to very clearly want that /var/lib/sss/pubconf/kpasswdinfo.EXAMPLE.COM file to exist, but it does not. Thoughts? Cheers, b.

1 0

Is there anything more effective than sss_cache -E?
by Johnnie W Adams 22 Jan '25

22 Jan '25

Hi, folks, I am trying to force reloads against LDAP and failing terribly with sss_cache -E. I keep getting the same long, long, long out-of-date information. Is there anything more thorough than sss_cache -E to clear it out? Thanks, John A -- John Adams Senior Linux/Middleware Administrator | Information Technology Services +1-501-916-3010 | jxadams(a)ualr.edu | http://ualr.edu/itservices *UA Little Rock* Reminder: IT Services will never ask for your password over the phone or in an email. Always be suspicious of requests for personal information that come via email, even from known contacts. For more information or to report suspicious email, visit IT Security <http://ualr.edu/itservices/security/>.

6 5

looking for the bitmap debug levels of ldap_library_debug_level....
by Spike White 17 Jan '25

17 Jan '25

Sssd experts, Our AD team is complaining that their AD controllers in our more densely-populated datacenters are getting overloaded. (up to 5K concurrent LDAP connections per AD DC). They find that 90% of the LDAP queries come from Linux servers -- which is surprising as Linux servers are < 50% of the resident population. We had previously found a coding bug in a vendor’s cron job that was generating a lot of unnecessary LDAP queries. That cybersecurity monitoring software was on every Linux server, so it led to a thundering herd problem when the cron job would kick off on every Linux server. That thundering herd problem has been remediated, but we suspect something similar occurring now. We’d like to see what LDAP queries are being executed by several random Linux servers, but we’ve had negative experiences leaving sssd debug_level = 9 on for several days. (Fills up the /var/log filesystem after a few days). I read in the sssd-ldap man page: ldap_library_debug_level (integer) Switches on libldap debugging with the given level. The libldap debug messages will be written independent of the general debug_level. OpenLDAP uses a bitmap to enable debugging for specific components, -1 will enable full debug output. Default: 0 (libldap debugging disabled) This seems to be exactly what we want! We want to see what LDAP queries are being executed without all the other massive logging that arises from debug_level 9. However, I cannot find these bitmap values of debug levels for the openldap library. The most I can find is bitmapped debug values for a stand-alone slapd daemon. OpenLDAP debug level - Knowledge Base / Community - Univention Help <https://help.univention.com/t/openldap-debug-level/19301> Where may I find the documentation of the bitmapped debug values that can be set via ldap_library_debug_level? Spike White

4 4

Issue with SSSD and Authentication Using AD Sites
by Rob Gibson 10 Jan '25

10 Jan '25

I am having some extreme difficulty with a setup for work, and I'm hoping that someone on the list can help... My employer has two sites, New York and London (details are being anonymized, but the details are consistent. At each physical location, we have servers which we wish to configure with AD logins against an existing on-prem AD domain, example.com. Each of these locations has two domain controllers which are properly categorized in Active Directory Sites and Services, and the Windows servers will log into their local DCs for their site. This can be confirmed as zero communication is allowed from one site's servers to the opposite's DCs. and you cannot telnet from one side to the other, although AD replication between the two sites is configured correctly. The Linux servers running sssd are Ubuntu 20.04 with sssd 2.2.3. The Windows DCs are Server 2019 running a supported domain functional level. Each Linux server has the IP addresses of their respective local DCs configured as their DNS resolvers. I was unable to use "realm discover" to discover a default domain, but I understand this is because the servers are not using DHCP, so they have no default DNS domain. However, when I "realm discover example.com", I get the expected output, including the "ad" provider statement. I am able to join the domain, and I can see the computer object getting created on the DCs, so it looks like the domain join is working correctly. I can also run "getent passwd <user>@example.com" and get a passwd entry exactly as I would expect it. The next test is to attempt to log in using the AD provider. I have tried using SSH, sudo, and directly running "login" from a 'root' shell. In all three cases, they will work once or twice and then fail over and over again, with the failures taking roughly 90 seconds to time out. Having found nothing obviously wrong but with timeout, I double-checked DNS to make sure all DNS names were available from the DCs, and they were. I also confirmed with our network team that no failures are seen when the login is happening, so it's not traversing and being blocked at the firewall. At nearly my wits end, I decided to do a local packet capture with Wireshark on the Linux server. To my surprise, sssd was trying to connect to the opposite datacenter. A server in New York was trying to connect to London for authentication, and this is not allowed by firewall rules. I see the first packet fail, and then 4 more with a doubling of each duration until it times out completely. I have spent the last couple of days trying various combinations of parameters with no luck. I have added the below settings to "sssd.conf" and restarted sssd: * ad_site = NewYork * ad_server = dc1.example.com, dc2.example.com * ad_enable_dns_sites = false * dns_discovery_domain = NewYork._sites.example.com For each of these, I have added each one to the section for example.com before restarting sssd. Each change has resulted in the same symptoms. What am I missing? What other things can I try to diagnose or resolve the issue? Thanks in advance, Rob

2 1

[SSSD] Announcing SSSD 2.10.1
by Pavel Březina 10 Dec '24

10 Dec '24

# SSSD 2.10.1 The SSSD team is announcing the release of version 2.10.1 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.10.1 See the full release notes at: https://sssd.io/release-notes/sssd-2.10.1.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 # SSSD 2.10.1 Release Notes ## Highlights ### General information * `krb5-child-test` was removed. Corresponding tests under 'src/tests/system/' are aimed to provide a comprehensive test coverage of 'krb5_child' functionality. * SSSD doesn't create anymore missing path components of DIR:/FILE: ccache types while acquiring user's TGT. The parent directory of requested ccache directory must exist and the user trying to log in must have 'rwx' access to this directory. This matches behavior of 'kinit'. * The DoT (DNS over TLS) for dynamic DNS updates is supported now. It requires new version of `nsupdate` from BIND 9.19+. * The option default_domain_suffix is deprecated. Consider using the more flexible domain_resolution_order instead. ### Packaging changes * **Important note for downstream maintainers.** A set of capabilities required by privileged binaries was further reduced to: ``` krb5_child cap_dac_read_search,cap_setgid,cap_setuid=p ldap_child cap_dac_read_search=p selinux_child cap_setgid,cap_setuid=p sssd_pam cap_dac_read_search=p ``` Keep in mind that even with a limited set of fine grained capabilities, usual precautions still should be taken while packaging binaries with file capabilities: it's very important to make sure that those are executable only by root/sssd service user. For this reason upstream spec file packages it as: ``` -rwxr-x---. 1 root sssd ``` Failing to do so (i.e. allowing non-privileged users to execute those binaries) can impose systems installing the package to a security risk. * Support of deprecated 'ad_allow_remote_domain_local_groups' sssd.conf option isn't built by default. It can be enabled using '--with-allow-remote-domain-local-groups' ./configure option. ### Configuration changes * `ad_allow_remote_domain_local_groups` option is deprecated and will be removed in future releases. * the `dyndns_server` option is extended so it can be in form of URI (dns+tls://1.2.3.4:853#servername). New set of options `dyndns_dot_cacert`, `dyndns_dot_cert` and `dyndns_dot_key` allows to configure DNS-over-TLS communication. * Added `exop_force` value for configuration option `ldap_pwmodify_mode`. This can be used to force a password change even if no grace logins are left. Depending on the configuration of the LDAP server it might be expected that the password change will fail.

1 0

slow login and first sudo usage when user is hard coded in /etc/sudo/sudoers file
by Ice Man 06 Dec '24

06 Dec '24

I am seeing extreme slowness for all users, when they first login and when they first use sudo. They may be related, but I'm currently focusing on the sudo-slowness, because it is easier to repeat, and because the user's name is hard-coded in the sudoers file. I can reproduce the problem using: $ sudo sss_cache --groups && time sudo echo hello && time sudo echo hello Thu Dec 5 11:56:38 PM UTC 2024 hello real 5m3.852s user 0m0.007s sys 0m0.022s hello real 0m0.030s user 0m0.007s sys 0m0.010s I don't understand why this should take so long, since the user's name is hard-coded in sudoers. I expect an immediate response, similar to what I see after results are cached for subsequent sudo usage. $ grep -v -P '(^#|^$)' /etc/sudoers Defaults env_reset Defaults mail_badpass Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" Defaults use_pty root ALL=(ALL:ALL) ALL %admin ALL=(ALL) ALL %sudo ALL=(ALL) NOPASSWD: ALL myuser ALL=(ALL) NOPASSWD: ALL I primarily need sssd/ldap for user authentication against an Active Directory server. I would like to report the user's group memberships, if requested (i.e., `id`), but I don't need that information cached, unless explicitly asked. Sudo access should be granted solely from /etc/sudoers. I don't want sssd to have any part in determining sudo restrictions. My /etc/nsswitch.conf file is: $ grep -v -P '(^#|^$)' /etc/nsswitch.conf passwd: files systemd sss group: files systemd sss shadow: files sss gshadow: files sudoers: files hosts: files mdns4_minimal [NOTFOUND=return] dns networks: files protocols: db files services: db files sss ethers: db files rpc: db files netgroup: nis sss automount: sss I have tried to impose timeouts to prevent these long sudo executions, but clearly, I'm missing something. My /etc/sss/ssd.conf file is: $ grep -v -P '(^#|^$)' /etc/sssd/sssd.conf [sssd] domains = corp.mycompany.com config_file_version = 2 debug_level = 1 override_space = _ [nss] enum_cache_timeout = 1 entry_cache_nowait_percentage = 75 filter_groups = root, admin, sudo filter_users = root reconnection_retries = 3 entry_cache_timeout = 300 entry_cache_nowait_percentage = 75 [pam] [domain/corp.mycompany.com] ldap_search_timeout = 3 ldap_network_timeout = 3 ldap_enumeration_search_timeout = 3 entry_cache_timeout = 600 entry_cache_nowait_percentage = 75 entry_cache_user_timeout = 5400 entry_cache_group_timeout = 5400 entry_cache_netgroup_timeout = 5400 ldap_sudo_full_refresh_interval = 0 ldap_sudo_smart_refresh_interval = 21600 ldap_sudo_use_host_filter = true ldap_sudo_include_netgroups = false ldap_sudo_include_regexp = false ldap_referrals = False enumerate = False cache_credentials = true override_shell = /bin/bash override_homedir = /home/%u id_provider = ldap access_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://adldap.mycompany.com ldap_service_port = 636 ldap_search_base = dc=corp,dc=mycompany,dc=com ldap_tls_reqcert = allow ldap_id_use_start_tls = true ldap_id_mapping = true ldap_schema = ad ldap_user_search_base = ou=Accounts,dc=corp,dc=mycompany,dc=com ldap_group_search_base = dc=corp,dc=mycompany,dc=com ldap_user_object_class = user ldap_user_name = sAMAccountName ldap_user_fullname = displayName ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_group_object_class = group ldap_group_name = cn ldap_access_order = expire ldap_account_expire_policy = ad ldap_default_bind_dn = cn=bindusername,ou=Service Accounts,ou=Accounts,dc=corp,dc=mycompany,dc=com ldap_default_authtok_type = password ldap_default_authtok = binduserpassword What am I missing? How can I speed up sudo access? Thanks in advance for any help you can provide. :) (BTW, if you see anything else that I'm configuring sub-optimally, feel free to chime in.)

2 4

Slowness with freeipa and sudorules involving large hostgroups
by Richard Doerwaldt 06 Dec '24

06 Dec '24

I've configured sudo to use the ipa backend basically using the config ipa-client-install generated for me and it's mostly working. However, when I configure sudo rules in FreeIPA with hostgroups containing a large amount of hosts, and I attempt to run sudo with an emptied sssd cache I get delays as sssd looks up the hosts in those netgroups, sometimes leading to timeouts when these lookups exceed ldap_search_timeout. I don't think looking up the hosts the netgroups should be required to evaluate the sudo rules. Configuring ignore_group_members=True unfortunately doesn't seem to help me here. Is there any way I can avoid sssd looking up these large netgroups?

4 4

[SSSD] Announcing SSSD 2.9.6
by Pavel Březina 05 Dec '24

05 Dec '24

# SSSD 2.9.6 The SSSD team is announcing the release of version 2.9.6 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.9.6 Note that this is the latest release of 2.9.x LTM branch. See the full release notes at: https://sssd.io/release-notes/sssd-2.9.6.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 # SSSD 2.9.6 Release Notes ## Highlights ### General information * The DoT for dynamic DNS updates is supported now. It requires new version of `nsupdate` from BIND 9.19+. * The option `default_domain_suffix` is deprecated. Consider using the more flexible `domain_resolution_order` instead. ### Important fixes * When the `DP_OPT_DYNDNS_REFRESH_OFFSET` enumerator was created, the associated `struct dp_option` was not. Because these structures are part of an array and the enumerator is used as the index, the wrong structure would be accessed when trying to use this index. This problem was fixed by creating the missing structure. ### Configuration changes * The `dyndns_server` option is extended so it can be in form of URI (`dns+tls://1.2.3.4:853#servername`). New set of options `dyndns_dot_cacert`, `dyndns_dot_cert` and `dyndns_dot_key` allows to configure DNS-over-TLS communication. * Added `exop_force` value for configuration option `ldap_pwmodify_mode`. This can be used to force a password change even if no grace logins are left. Depending on the configuration of the LDAP server it might be expected that the password change will fail.

1 0

Any way to take down historical posts?
by Spike White 27 Nov '24

27 Nov '24

All, Is there any way for somone to take down historical posts that same someone has previously posted to this mailing list? Inquiring for a friend. :-) Spike

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users