** Description changed: [ Impact ] This bug causes sssd to break when it is upgraded on a system joined to an Active Directory domain. Symptoms include failure to resolve non- cached usernames and groups, including failure to login for domain users. A simple --reinstall of sssd-common and sssd-krb5-common, i.e., same versions, will trigger the bug. Upgrades lead to the same broken behavior. - [ Test Plan ] This test plan is to be performed on a samba server joined to a samba active directory controller. Instructions on how to deploy a samba AD/DC server can be found at [1], and how to join a samba server using sssd to that controller can be found at [2]. + + + For this test plan, the samba AD/DC server was provisioned for the "example.fake" domain. + + - On the samba AD/DC server, create three domain users: + root@r-samba:~# samba-tool user create noble + root@r-samba:~# samba-tool user create resolute + root@r-samba:~# samba-tool user create stonking + root@r-samba:~# samba-tool user create questing + + - On the joined samba server under test for this SRU, verify that the + noble user can be resolved: + + root@r-sssd:~# id [email protected] + uid=1170201107([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) + + - In preparation for reproducing the bug, open a terminal and tail the + /var/log/sssd/sssd_example.fake.log log file, looking for expressions of + the failure: + + root@r-sssd:~# tail -f /var/log/sssd/sssd_example.fake.log | grep -iE + "(internal|corrupted)" + + - In another terminal on the joined samba server under test, reinstall + the sssd-common and sssd-krb5-common packages: + + root@r-sssd:~# apt install --reinstall sssd-common sssd-krb5-common + + - Observe that the log file being tailed will show several occurrences like: + * (2026-07-13 17:22:23): [be[example.fake]] [dp_load_targets] (0x0020): Unable to load target [id] [80]: Accessing a corrupted shared library. + (2026-07-13 17:22:23): [be[example.fake]] [dp_init] (0x0020): Unable to initialize DP targets [1432158209]: Internal Error + + - on the member server under test, try to resolve the other user we + created, "resolute". It will fail: + + root@r-sssd:~# id [email protected] + id: '[email protected]': no such user + + - But the user we resolved before remains working, due to cache: + + root@r-sssd:~# id [email protected] + uid=1170201107([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) + + - Now install the packages from proposed, and try to resolve the first 3 users we created. It will work: + root@r-sssd:~# id [email protected] + uid=1170201107([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) + root@r-sssd:~# id [email protected] + uid=1170201110([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) + root@r-sssd:~# id [email protected] + uid=1170201117([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) + root@r-sssd:~# + + And the terminal window tailing the logs will have been quiet with no + new "internal error" or "corrupted shared library" log entries. + + - Lastly, reinstall the sssd-common and sssd-krb5-common packages from + proposed, and observe that the logs remain quiet with no new error + messages: + + root@r-sssd:~# apt install --reinstall sssd-common sssd-krb5-common + + - And now test all 4 users that we created, including the fresh one and + never probed before "questing": + + root@r-sssd:~# id [email protected] + uid=1170201107([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) + + root@r-sssd:~# id [email protected] + uid=1170201110([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) + + root@r-sssd:~# id [email protected] + uid=1170201117([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) + + root@r-sssd:~# id [email protected] + uid=1170201119([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) + root@r-sssd:~# [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must never be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Make sure to explain any deviation from the norm, to save the SRU reviewer from having to infer your reasoning, possibly incorrectly. This should also help reduce review iterations, particularly when the reason for the deviation is not obvious. * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board and address these questions in advance 1. https://ubuntu.com/server/docs/how-to/samba/provision-samba-ad-controller/ 2. https://ubuntu.com/server/docs/how-to/samba/member-server-in-an-ad-domain/ - [ Original description ] ## Source package `sssd` ## Bug title Update to SSSD 2.12.0-1ubuntu5 breaks AD join due to SSSD inability to read keytab 1. Ubuntu release --- Ubuntu 26.04 2. Package version --- The issue appeared immediately after unattended-upgrade updated the SSSD package set from `2.12.0-1ubuntu5` to `2.12.0-1ubuntu5.1`. Please see attached apport data and/or the output of: ``` apt-cache policy sssd sssd-ad sssd-common sssd-krb5-common sssd-ldap libnss-sss libpam-sss ``` Relevant unattended-upgrade history: ``` Start-Date: 2026-06-02 06:48:24 Commandline: /usr/bin/unattended-upgrade Upgrade: gsasl-common:amd64 (2.2.2-4ubuntu1, 2.2.2-4ubuntu1.1), sssd-proxy:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-ad-common:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-ipa:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-dbus:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libgsasl18:amd64 (2.2.2-4ubuntu1, 2.2.2-4ubuntu1.1), sssd-krb5-common:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libsss-nss-idmap0:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), python3-sss:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libnss-sss:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-krb5:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libipa-hbac0t64:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-tools:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libsss-idmap0:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-ad:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-common:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libpam-sss:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-ldap:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libsss-certmap0:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1) End-Date: 2026-06-02 06:48:48 ``` Relevant installed versions after the upgrade: ``` libldb2:amd64 2:2.11.0+samba4.23.6+dfsg-1ubuntu2.1 libsss-certmap0 2.12.0-1ubuntu5.1 libsss-idmap0 2.12.0-1ubuntu5.1 libsss-nss-idmap0 2.12.0-1ubuntu5.1 sssd 2.12.0-1ubuntu5.1 sssd-ad 2.12.0-1ubuntu5.1 sssd-ad-common 2.12.0-1ubuntu5.1 sssd-common 2.12.0-1ubuntu5.1 sssd-dbus 2.12.0-1ubuntu5.1 sssd-ipa 2.12.0-1ubuntu5.1 sssd-krb5 2.12.0-1ubuntu5.1 sssd-krb5-common 2.12.0-1ubuntu5.1 sssd-ldap 2.12.0-1ubuntu5.1 sssd-proxy 2.12.0-1ubuntu5.1 sssd-tools 2.12.0-1ubuntu5.1 ``` 3. What I expected to happen --- An existing Ubuntu 26.04 AD-joined client using the SSSD AD provider should continue to start SSSD successfully after an unattended upgrade from SSSD `2.12.0-1ubuntu5` to `2.12.0-1ubuntu5.1`. The system already had a valid `/etc/krb5.keytab`, and SSSD was functioning before the upgrade. If Ubuntu’s SSSD packaging now requires `/etc/krb5.keytab` to be readable by the `sssd` service user or group, I would expect at least one of the following: * the package upgrade migrates or adjusts the keytab ownership/mode where appropriate; * the package upgrade emits a clear warning; * Ubuntu documentation clearly states that AD-provider clients need `/etc/krb5.keytab` readable by `sssd`; * SSSD logs a direct keytab permission/readability error rather than surfacing the later and misleading `Accessing a corrupted shared library` message. 4. What happened instead --- Immediately after unattended-upgrade updated the SSSD packages from `2.12.0-1ubuntu5` to `2.12.0-1ubuntu5.1`, SSSD failed to initialize the AD provider backend. The SSSD monitor repeatedly attempted to start the domain backend, which exited with code 3: ``` (2026-06-02 6:48:36): [sssd] [svc_child_info] (0x0040): Child [2278146] ('domain.college.edu':'%BE_domain.college.edu') exited with code [3] ... (2026-06-02 6:48:42): [sssd] [monitor_restart_service] (0x0010): Process [domain.college.edu], definitely stopped! (2026-06-02 6:48:42): [sssd] [monitor_quit] (0x3f7c0): Returned with: 1 ``` The domain-specific SSSD log showed that the AD provider failed while attempting to initialize SASL/GSSAPI options and select the machine principal from the default keytab: ``` (2026-06-02 6:48:42): [be[domain.college.edu]] [ad_set_sdap_options] (0x0100): Option krb5_realm set to DOMAIN.COLLEGE.EDU (2026-06-02 6:48:42): [be[domain.college.edu]] [sdap_set_sasl_options] (0x0100): Will look for [email protected] in default keytab (2026-06-02 6:48:42): [be[domain.college.edu]] [create_child_req_send_buffer] (0x0400): buffer size: 60 (2026-06-02 6:48:42): [be[domain.college.edu]] [sdap_select_principal_from_keytab_sync] (0x0020): Failed to get principal from keytab (sss_atomic_read_s() failed), see ldap_child.log (pid = 2278182) for details. ``` This was followed by: ``` (2026-06-02 6:48:42): [be[domain.college.edu]] [ad_set_sdap_options] (0x0040): Cannot set the SASL-related options (2026-06-02 6:48:42): [be[domain.college.edu]] [sssm_ad_init] (0x0020): Unable to init AD id options (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_module_run_constructor] (0x0010): Module [ad] constructor failed [5]: Input/output error (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_load_module] (0x0020): Unable to create DP module. ``` And finally: ``` (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_target_init] (0x0010): Unable to load module ad (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_load_targets] (0x0020): Unable to load target [id] [80]: Accessing a corrupted shared library. (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_init] (0x0020): Unable to initialize DP targets [1432158209]: Internal Error (2026-06-02 6:48:42): [be[domain.college.edu]] [be_process_init] (0x0010): Unable to setup data provider [1432158209]: Internal Error (2026-06-02 6:48:42): [be[domain.college.edu]] [main] (0x0010): Could not initialize backend [1432158209] ``` The keytab was present before and after the upgrade and was owned `root:root` with mode `0600`: ``` f: /etc/krb5.keytab drwxr-xr-x root root / drwxr-xr-x root root etc -rw------- root root krb5.keytab -rw------- 1 root root 880 May 5 17:39 /etc/krb5.keytab ``` The SSSD service unit runs as the `sssd` user and group: ``` User=sssd Group=sssd CapabilityBoundingSet= CAP_SETGID CAP_SETUID CAP_DAC_READ_SEARCH SecureBits=noroot noroot-locked ``` Helper binary capabilities are present: ``` /usr/libexec/sssd/sssd_pam cap_dac_read_search=p /usr/libexec/sssd/krb5_child cap_dac_read_search,cap_setgid,cap_setuid=p /usr/libexec/sssd/ldap_child cap_dac_read_search=p /usr/libexec/sssd/selinux_child cap_setgid,cap_setuid=p ``` ## Workaround Changing the keytab ownership and mode to make it readable by the `sssd` group immediately resolved the issue: ``` sudo chown root:sssd /etc/krb5.keytab sudo chmod 0640 /etc/krb5.keytab sudo systemctl restart sssd ``` After this change, SSSD started successfully and AD lookups/authentication worked again. ## Impact This broke SSSD startup and therefore broke AD identity lookup/authentication on an already-joined Ubuntu 26.04 AD client immediately after an unattended package upgrade. This is especially problematic because the failure can occur automatically during unattended-upgrades and may break logins on already-joined systems. ## Additional environment details This is an existing Ubuntu 26.04 AD client using SSSD with the AD provider. The relevant domain configuration is: ``` [sssd] domains = domain.college.edu debug_level = 3 [domain/domain.college.edu] access_provider = ad ad_backup_server = ad1.college.edu ad_domain = domain.college.edu ad_gpo_access_control = disabled ad_maximum_machine_account_password_age = 0 ad_server = dc2.college.edu cache_credentials = True default_shell = /bin/bash fallback_homedir = /home/%u id_provider = ad dyndns_update = False krb5_realm = DOMAIN.COLLEGE.EDU ldap_id_mapping = False ldap_referrals = False max_id = 158999 min_id = 1001 override_homedir = /home/%u use_fully_qualified_names = False ``` This system has a local SSSD systemd drop-in that only changes restart behavior and start-limit behavior. It does not change the SSSD service user, service group, capability bounding set, securebits configuration, or helper binary capabilities. The local AD join automation creates the keytab using `adcli join` and previously did not alter the resulting keytab ownership or mode. The pre-existing `root:root 0600` keytab mode is a common historical state for `/etc/krb5.keytab`. ## Request Please confirm the intended ownership and permissions for `/etc/krb5.keytab` on Ubuntu 26.04 SSSD AD-provider clients after the SSSD 2.12.0 package changes. If `root:sssd 0640` is now required or recommended, please consider adding upgrade handling, release notes, or documentation so existing AD- joined clients do not fail after unattended upgrades. Please also consider improving the error handling/logging so that this condition is reported as a keytab readability/permission problem rather than later surfacing as: ``` Unable to load target [id] [80]: Accessing a corrupted shared library. ```
** Description changed: [ Impact ] This bug causes sssd to break when it is upgraded on a system joined to an Active Directory domain. Symptoms include failure to resolve non- cached usernames and groups, including failure to login for domain users. A simple --reinstall of sssd-common and sssd-krb5-common, i.e., same versions, will trigger the bug. Upgrades lead to the same broken behavior. [ Test Plan ] This test plan is to be performed on a samba server joined to a samba active directory controller. Instructions on how to deploy a samba AD/DC server can be found at [1], and how to join a samba server using sssd to that controller can be found at [2]. - - For this test plan, the samba AD/DC server was provisioned for the "example.fake" domain. + For this test plan, the samba AD/DC server was provisioned for the + "example.fake" domain. - On the samba AD/DC server, create three domain users: root@r-samba:~# samba-tool user create noble root@r-samba:~# samba-tool user create resolute root@r-samba:~# samba-tool user create stonking root@r-samba:~# samba-tool user create questing - On the joined samba server under test for this SRU, verify that the noble user can be resolved: root@r-sssd:~# id [email protected] uid=1170201107([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) - In preparation for reproducing the bug, open a terminal and tail the /var/log/sssd/sssd_example.fake.log log file, looking for expressions of the failure: root@r-sssd:~# tail -f /var/log/sssd/sssd_example.fake.log | grep -iE "(internal|corrupted)" - In another terminal on the joined samba server under test, reinstall the sssd-common and sssd-krb5-common packages: root@r-sssd:~# apt install --reinstall sssd-common sssd-krb5-common - Observe that the log file being tailed will show several occurrences like: - * (2026-07-13 17:22:23): [be[example.fake]] [dp_load_targets] (0x0020): Unable to load target [id] [80]: Accessing a corrupted shared library. + * (2026-07-13 17:22:23): [be[example.fake]] [dp_load_targets] (0x0020): Unable to load target [id] [80]: Accessing a corrupted shared library. (2026-07-13 17:22:23): [be[example.fake]] [dp_init] (0x0020): Unable to initialize DP targets [1432158209]: Internal Error - on the member server under test, try to resolve the other user we created, "resolute". It will fail: root@r-sssd:~# id [email protected] id: '[email protected]': no such user - But the user we resolved before remains working, due to cache: root@r-sssd:~# id [email protected] uid=1170201107([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) - Now install the packages from proposed, and try to resolve the first 3 users we created. It will work: root@r-sssd:~# id [email protected] uid=1170201107([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) root@r-sssd:~# id [email protected] uid=1170201110([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) root@r-sssd:~# id [email protected] uid=1170201117([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) - root@r-sssd:~# + root@r-sssd:~# And the terminal window tailing the logs will have been quiet with no new "internal error" or "corrupted shared library" log entries. - Lastly, reinstall the sssd-common and sssd-krb5-common packages from proposed, and observe that the logs remain quiet with no new error messages: root@r-sssd:~# apt install --reinstall sssd-common sssd-krb5-common - And now test all 4 users that we created, including the fresh one and never probed before "questing": root@r-sssd:~# id [email protected] uid=1170201107([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) root@r-sssd:~# id [email protected] uid=1170201110([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) root@r-sssd:~# id [email protected] uid=1170201117([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) root@r-sssd:~# id [email protected] uid=1170201119([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) - root@r-sssd:~# - + root@r-sssd:~# [ Where problems could occur ] - * Think about what the upload changes in the software. Imagine the - change is wrong or breaks something else: how would this show up? - - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the event - of a regression. - - * This must never be "None" or "Low", or entirely an argument as to why - your upload is low risk. - - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. + The fix is only in the sssd-common.postinst maintainer script, and involves resetting permissions and ownership that were granted on first install. Therefore possible regressions include: + - the new commands failing, and thus making the postinst exit non-zero and breaking the package installation. + - overwriting local permission and ownership changes done by the administrator + + The commands are the same as executed at first package install, so no + regressions are expected there. An important note is that package sssd- + common is changing the ownership and permissions of files from another + package. That is guarded by checking if those files are present first. + [ Other Info ] - - * Anything else you think is useful to include - - * Make sure to explain any deviation from the norm, to save the SRU - reviewer from having to infer your reasoning, possibly incorrectly. - This should also help reduce review iterations, particularly when the - reason for the deviation is not obvious. - - * Anticipate questions from users, SRU, +1 maintenance, security teams - and the Technical Board and address these questions in advance + N/A. + 1. https://ubuntu.com/server/docs/how-to/samba/provision-samba-ad-controller/ 2. https://ubuntu.com/server/docs/how-to/samba/member-server-in-an-ad-domain/ [ Original description ] ## Source package `sssd` ## Bug title Update to SSSD 2.12.0-1ubuntu5 breaks AD join due to SSSD inability to read keytab 1. Ubuntu release --- Ubuntu 26.04 2. Package version --- The issue appeared immediately after unattended-upgrade updated the SSSD package set from `2.12.0-1ubuntu5` to `2.12.0-1ubuntu5.1`. Please see attached apport data and/or the output of: ``` apt-cache policy sssd sssd-ad sssd-common sssd-krb5-common sssd-ldap libnss-sss libpam-sss ``` Relevant unattended-upgrade history: ``` Start-Date: 2026-06-02 06:48:24 Commandline: /usr/bin/unattended-upgrade Upgrade: gsasl-common:amd64 (2.2.2-4ubuntu1, 2.2.2-4ubuntu1.1), sssd-proxy:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-ad-common:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-ipa:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-dbus:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libgsasl18:amd64 (2.2.2-4ubuntu1, 2.2.2-4ubuntu1.1), sssd-krb5-common:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libsss-nss-idmap0:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), python3-sss:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libnss-sss:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-krb5:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libipa-hbac0t64:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-tools:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libsss-idmap0:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-ad:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-common:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libpam-sss:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-ldap:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libsss-certmap0:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1) End-Date: 2026-06-02 06:48:48 ``` Relevant installed versions after the upgrade: ``` libldb2:amd64 2:2.11.0+samba4.23.6+dfsg-1ubuntu2.1 libsss-certmap0 2.12.0-1ubuntu5.1 libsss-idmap0 2.12.0-1ubuntu5.1 libsss-nss-idmap0 2.12.0-1ubuntu5.1 sssd 2.12.0-1ubuntu5.1 sssd-ad 2.12.0-1ubuntu5.1 sssd-ad-common 2.12.0-1ubuntu5.1 sssd-common 2.12.0-1ubuntu5.1 sssd-dbus 2.12.0-1ubuntu5.1 sssd-ipa 2.12.0-1ubuntu5.1 sssd-krb5 2.12.0-1ubuntu5.1 sssd-krb5-common 2.12.0-1ubuntu5.1 sssd-ldap 2.12.0-1ubuntu5.1 sssd-proxy 2.12.0-1ubuntu5.1 sssd-tools 2.12.0-1ubuntu5.1 ``` 3. What I expected to happen --- An existing Ubuntu 26.04 AD-joined client using the SSSD AD provider should continue to start SSSD successfully after an unattended upgrade from SSSD `2.12.0-1ubuntu5` to `2.12.0-1ubuntu5.1`. The system already had a valid `/etc/krb5.keytab`, and SSSD was functioning before the upgrade. If Ubuntu’s SSSD packaging now requires `/etc/krb5.keytab` to be readable by the `sssd` service user or group, I would expect at least one of the following: * the package upgrade migrates or adjusts the keytab ownership/mode where appropriate; * the package upgrade emits a clear warning; * Ubuntu documentation clearly states that AD-provider clients need `/etc/krb5.keytab` readable by `sssd`; * SSSD logs a direct keytab permission/readability error rather than surfacing the later and misleading `Accessing a corrupted shared library` message. 4. What happened instead --- Immediately after unattended-upgrade updated the SSSD packages from `2.12.0-1ubuntu5` to `2.12.0-1ubuntu5.1`, SSSD failed to initialize the AD provider backend. The SSSD monitor repeatedly attempted to start the domain backend, which exited with code 3: ``` (2026-06-02 6:48:36): [sssd] [svc_child_info] (0x0040): Child [2278146] ('domain.college.edu':'%BE_domain.college.edu') exited with code [3] ... (2026-06-02 6:48:42): [sssd] [monitor_restart_service] (0x0010): Process [domain.college.edu], definitely stopped! (2026-06-02 6:48:42): [sssd] [monitor_quit] (0x3f7c0): Returned with: 1 ``` The domain-specific SSSD log showed that the AD provider failed while attempting to initialize SASL/GSSAPI options and select the machine principal from the default keytab: ``` (2026-06-02 6:48:42): [be[domain.college.edu]] [ad_set_sdap_options] (0x0100): Option krb5_realm set to DOMAIN.COLLEGE.EDU (2026-06-02 6:48:42): [be[domain.college.edu]] [sdap_set_sasl_options] (0x0100): Will look for [email protected] in default keytab (2026-06-02 6:48:42): [be[domain.college.edu]] [create_child_req_send_buffer] (0x0400): buffer size: 60 (2026-06-02 6:48:42): [be[domain.college.edu]] [sdap_select_principal_from_keytab_sync] (0x0020): Failed to get principal from keytab (sss_atomic_read_s() failed), see ldap_child.log (pid = 2278182) for details. ``` This was followed by: ``` (2026-06-02 6:48:42): [be[domain.college.edu]] [ad_set_sdap_options] (0x0040): Cannot set the SASL-related options (2026-06-02 6:48:42): [be[domain.college.edu]] [sssm_ad_init] (0x0020): Unable to init AD id options (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_module_run_constructor] (0x0010): Module [ad] constructor failed [5]: Input/output error (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_load_module] (0x0020): Unable to create DP module. ``` And finally: ``` (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_target_init] (0x0010): Unable to load module ad (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_load_targets] (0x0020): Unable to load target [id] [80]: Accessing a corrupted shared library. (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_init] (0x0020): Unable to initialize DP targets [1432158209]: Internal Error (2026-06-02 6:48:42): [be[domain.college.edu]] [be_process_init] (0x0010): Unable to setup data provider [1432158209]: Internal Error (2026-06-02 6:48:42): [be[domain.college.edu]] [main] (0x0010): Could not initialize backend [1432158209] ``` The keytab was present before and after the upgrade and was owned `root:root` with mode `0600`: ``` f: /etc/krb5.keytab drwxr-xr-x root root / drwxr-xr-x root root etc -rw------- root root krb5.keytab -rw------- 1 root root 880 May 5 17:39 /etc/krb5.keytab ``` The SSSD service unit runs as the `sssd` user and group: ``` User=sssd Group=sssd CapabilityBoundingSet= CAP_SETGID CAP_SETUID CAP_DAC_READ_SEARCH SecureBits=noroot noroot-locked ``` Helper binary capabilities are present: ``` /usr/libexec/sssd/sssd_pam cap_dac_read_search=p /usr/libexec/sssd/krb5_child cap_dac_read_search,cap_setgid,cap_setuid=p /usr/libexec/sssd/ldap_child cap_dac_read_search=p /usr/libexec/sssd/selinux_child cap_setgid,cap_setuid=p ``` ## Workaround Changing the keytab ownership and mode to make it readable by the `sssd` group immediately resolved the issue: ``` sudo chown root:sssd /etc/krb5.keytab sudo chmod 0640 /etc/krb5.keytab sudo systemctl restart sssd ``` After this change, SSSD started successfully and AD lookups/authentication worked again. ## Impact This broke SSSD startup and therefore broke AD identity lookup/authentication on an already-joined Ubuntu 26.04 AD client immediately after an unattended package upgrade. This is especially problematic because the failure can occur automatically during unattended-upgrades and may break logins on already-joined systems. ## Additional environment details This is an existing Ubuntu 26.04 AD client using SSSD with the AD provider. The relevant domain configuration is: ``` [sssd] domains = domain.college.edu debug_level = 3 [domain/domain.college.edu] access_provider = ad ad_backup_server = ad1.college.edu ad_domain = domain.college.edu ad_gpo_access_control = disabled ad_maximum_machine_account_password_age = 0 ad_server = dc2.college.edu cache_credentials = True default_shell = /bin/bash fallback_homedir = /home/%u id_provider = ad dyndns_update = False krb5_realm = DOMAIN.COLLEGE.EDU ldap_id_mapping = False ldap_referrals = False max_id = 158999 min_id = 1001 override_homedir = /home/%u use_fully_qualified_names = False ``` This system has a local SSSD systemd drop-in that only changes restart behavior and start-limit behavior. It does not change the SSSD service user, service group, capability bounding set, securebits configuration, or helper binary capabilities. The local AD join automation creates the keytab using `adcli join` and previously did not alter the resulting keytab ownership or mode. The pre-existing `root:root 0600` keytab mode is a common historical state for `/etc/krb5.keytab`. ## Request Please confirm the intended ownership and permissions for `/etc/krb5.keytab` on Ubuntu 26.04 SSSD AD-provider clients after the SSSD 2.12.0 package changes. If `root:sssd 0640` is now required or recommended, please consider adding upgrade handling, release notes, or documentation so existing AD- joined clients do not fail after unattended upgrades. Please also consider improving the error handling/logging so that this condition is reported as a keytab readability/permission problem rather than later surfacing as: ``` Unable to load target [id] [80]: Accessing a corrupted shared library. ``` ** Description changed: [ Impact ] This bug causes sssd to break when it is upgraded on a system joined to an Active Directory domain. Symptoms include failure to resolve non- cached usernames and groups, including failure to login for domain users. A simple --reinstall of sssd-common and sssd-krb5-common, i.e., same versions, will trigger the bug. Upgrades lead to the same broken behavior. [ Test Plan ] This test plan is to be performed on a samba server joined to a samba active directory controller. Instructions on how to deploy a samba AD/DC server can be found at [1], and how to join a samba server using sssd to that controller can be found at [2]. For this test plan, the samba AD/DC server was provisioned for the "example.fake" domain. - On the samba AD/DC server, create three domain users: root@r-samba:~# samba-tool user create noble root@r-samba:~# samba-tool user create resolute root@r-samba:~# samba-tool user create stonking root@r-samba:~# samba-tool user create questing - On the joined samba server under test for this SRU, verify that the noble user can be resolved: root@r-sssd:~# id [email protected] uid=1170201107([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) - In preparation for reproducing the bug, open a terminal and tail the /var/log/sssd/sssd_example.fake.log log file, looking for expressions of the failure: root@r-sssd:~# tail -f /var/log/sssd/sssd_example.fake.log | grep -iE "(internal|corrupted)" - In another terminal on the joined samba server under test, reinstall the sssd-common and sssd-krb5-common packages: root@r-sssd:~# apt install --reinstall sssd-common sssd-krb5-common - Observe that the log file being tailed will show several occurrences like: * (2026-07-13 17:22:23): [be[example.fake]] [dp_load_targets] (0x0020): Unable to load target [id] [80]: Accessing a corrupted shared library. (2026-07-13 17:22:23): [be[example.fake]] [dp_init] (0x0020): Unable to initialize DP targets [1432158209]: Internal Error - on the member server under test, try to resolve the other user we created, "resolute". It will fail: root@r-sssd:~# id [email protected] id: '[email protected]': no such user - But the user we resolved before remains working, due to cache: root@r-sssd:~# id [email protected] uid=1170201107([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) - Now install the packages from proposed, and try to resolve the first 3 users we created. It will work: root@r-sssd:~# id [email protected] uid=1170201107([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) root@r-sssd:~# id [email protected] uid=1170201110([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) root@r-sssd:~# id [email protected] uid=1170201117([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) root@r-sssd:~# And the terminal window tailing the logs will have been quiet with no new "internal error" or "corrupted shared library" log entries. - Lastly, reinstall the sssd-common and sssd-krb5-common packages from proposed, and observe that the logs remain quiet with no new error messages: root@r-sssd:~# apt install --reinstall sssd-common sssd-krb5-common - And now test all 4 users that we created, including the fresh one and never probed before "questing": root@r-sssd:~# id [email protected] uid=1170201107([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) root@r-sssd:~# id [email protected] uid=1170201110([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) root@r-sssd:~# id [email protected] uid=1170201117([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) root@r-sssd:~# id [email protected] uid=1170201119([email protected]) gid=1170200513(domain [email protected]) groups=1170200513(domain [email protected]) root@r-sssd:~# [ Where problems could occur ] The fix is only in the sssd-common.postinst maintainer script, and involves resetting permissions and ownership that were granted on first install. Therefore possible regressions include: - the new commands failing, and thus making the postinst exit non-zero and breaking the package installation. - overwriting local permission and ownership changes done by the administrator The commands are the same as executed at first package install, so no regressions are expected there. An important note is that package sssd- - common is changing the ownership and permissions of files from another - package. That is guarded by checking if those files are present first. - + common is changing the ownership and permissions of files from package + sssd-krb5-common and sssd-ipa. That is guarded by checking if those + files are present first. + + The resetting of ownership and permissions done in sssd-common must + match exactly what is done in the packages that actually ship those + files. There is no code guard against a mistake there, which would + present itself as difference in behavior of fresh installs versus + upgrades. [ Other Info ] N/A. - 1. https://ubuntu.com/server/docs/how-to/samba/provision-samba-ad-controller/ 2. https://ubuntu.com/server/docs/how-to/samba/member-server-in-an-ad-domain/ [ Original description ] ## Source package `sssd` ## Bug title Update to SSSD 2.12.0-1ubuntu5 breaks AD join due to SSSD inability to read keytab 1. Ubuntu release --- Ubuntu 26.04 2. Package version --- The issue appeared immediately after unattended-upgrade updated the SSSD package set from `2.12.0-1ubuntu5` to `2.12.0-1ubuntu5.1`. Please see attached apport data and/or the output of: ``` apt-cache policy sssd sssd-ad sssd-common sssd-krb5-common sssd-ldap libnss-sss libpam-sss ``` Relevant unattended-upgrade history: ``` Start-Date: 2026-06-02 06:48:24 Commandline: /usr/bin/unattended-upgrade Upgrade: gsasl-common:amd64 (2.2.2-4ubuntu1, 2.2.2-4ubuntu1.1), sssd-proxy:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-ad-common:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-ipa:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-dbus:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libgsasl18:amd64 (2.2.2-4ubuntu1, 2.2.2-4ubuntu1.1), sssd-krb5-common:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libsss-nss-idmap0:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), python3-sss:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libnss-sss:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-krb5:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libipa-hbac0t64:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-tools:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libsss-idmap0:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-ad:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-common:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libpam-sss:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), sssd-ldap:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1), libsss-certmap0:amd64 (2.12.0-1ubuntu5, 2.12.0-1ubuntu5.1) End-Date: 2026-06-02 06:48:48 ``` Relevant installed versions after the upgrade: ``` libldb2:amd64 2:2.11.0+samba4.23.6+dfsg-1ubuntu2.1 libsss-certmap0 2.12.0-1ubuntu5.1 libsss-idmap0 2.12.0-1ubuntu5.1 libsss-nss-idmap0 2.12.0-1ubuntu5.1 sssd 2.12.0-1ubuntu5.1 sssd-ad 2.12.0-1ubuntu5.1 sssd-ad-common 2.12.0-1ubuntu5.1 sssd-common 2.12.0-1ubuntu5.1 sssd-dbus 2.12.0-1ubuntu5.1 sssd-ipa 2.12.0-1ubuntu5.1 sssd-krb5 2.12.0-1ubuntu5.1 sssd-krb5-common 2.12.0-1ubuntu5.1 sssd-ldap 2.12.0-1ubuntu5.1 sssd-proxy 2.12.0-1ubuntu5.1 sssd-tools 2.12.0-1ubuntu5.1 ``` 3. What I expected to happen --- An existing Ubuntu 26.04 AD-joined client using the SSSD AD provider should continue to start SSSD successfully after an unattended upgrade from SSSD `2.12.0-1ubuntu5` to `2.12.0-1ubuntu5.1`. The system already had a valid `/etc/krb5.keytab`, and SSSD was functioning before the upgrade. If Ubuntu’s SSSD packaging now requires `/etc/krb5.keytab` to be readable by the `sssd` service user or group, I would expect at least one of the following: * the package upgrade migrates or adjusts the keytab ownership/mode where appropriate; * the package upgrade emits a clear warning; * Ubuntu documentation clearly states that AD-provider clients need `/etc/krb5.keytab` readable by `sssd`; * SSSD logs a direct keytab permission/readability error rather than surfacing the later and misleading `Accessing a corrupted shared library` message. 4. What happened instead --- Immediately after unattended-upgrade updated the SSSD packages from `2.12.0-1ubuntu5` to `2.12.0-1ubuntu5.1`, SSSD failed to initialize the AD provider backend. The SSSD monitor repeatedly attempted to start the domain backend, which exited with code 3: ``` (2026-06-02 6:48:36): [sssd] [svc_child_info] (0x0040): Child [2278146] ('domain.college.edu':'%BE_domain.college.edu') exited with code [3] ... (2026-06-02 6:48:42): [sssd] [monitor_restart_service] (0x0010): Process [domain.college.edu], definitely stopped! (2026-06-02 6:48:42): [sssd] [monitor_quit] (0x3f7c0): Returned with: 1 ``` The domain-specific SSSD log showed that the AD provider failed while attempting to initialize SASL/GSSAPI options and select the machine principal from the default keytab: ``` (2026-06-02 6:48:42): [be[domain.college.edu]] [ad_set_sdap_options] (0x0100): Option krb5_realm set to DOMAIN.COLLEGE.EDU (2026-06-02 6:48:42): [be[domain.college.edu]] [sdap_set_sasl_options] (0x0100): Will look for [email protected] in default keytab (2026-06-02 6:48:42): [be[domain.college.edu]] [create_child_req_send_buffer] (0x0400): buffer size: 60 (2026-06-02 6:48:42): [be[domain.college.edu]] [sdap_select_principal_from_keytab_sync] (0x0020): Failed to get principal from keytab (sss_atomic_read_s() failed), see ldap_child.log (pid = 2278182) for details. ``` This was followed by: ``` (2026-06-02 6:48:42): [be[domain.college.edu]] [ad_set_sdap_options] (0x0040): Cannot set the SASL-related options (2026-06-02 6:48:42): [be[domain.college.edu]] [sssm_ad_init] (0x0020): Unable to init AD id options (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_module_run_constructor] (0x0010): Module [ad] constructor failed [5]: Input/output error (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_load_module] (0x0020): Unable to create DP module. ``` And finally: ``` (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_target_init] (0x0010): Unable to load module ad (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_load_targets] (0x0020): Unable to load target [id] [80]: Accessing a corrupted shared library. (2026-06-02 6:48:42): [be[domain.college.edu]] [dp_init] (0x0020): Unable to initialize DP targets [1432158209]: Internal Error (2026-06-02 6:48:42): [be[domain.college.edu]] [be_process_init] (0x0010): Unable to setup data provider [1432158209]: Internal Error (2026-06-02 6:48:42): [be[domain.college.edu]] [main] (0x0010): Could not initialize backend [1432158209] ``` The keytab was present before and after the upgrade and was owned `root:root` with mode `0600`: ``` f: /etc/krb5.keytab drwxr-xr-x root root / drwxr-xr-x root root etc -rw------- root root krb5.keytab -rw------- 1 root root 880 May 5 17:39 /etc/krb5.keytab ``` The SSSD service unit runs as the `sssd` user and group: ``` User=sssd Group=sssd CapabilityBoundingSet= CAP_SETGID CAP_SETUID CAP_DAC_READ_SEARCH SecureBits=noroot noroot-locked ``` Helper binary capabilities are present: ``` /usr/libexec/sssd/sssd_pam cap_dac_read_search=p /usr/libexec/sssd/krb5_child cap_dac_read_search,cap_setgid,cap_setuid=p /usr/libexec/sssd/ldap_child cap_dac_read_search=p /usr/libexec/sssd/selinux_child cap_setgid,cap_setuid=p ``` ## Workaround Changing the keytab ownership and mode to make it readable by the `sssd` group immediately resolved the issue: ``` sudo chown root:sssd /etc/krb5.keytab sudo chmod 0640 /etc/krb5.keytab sudo systemctl restart sssd ``` After this change, SSSD started successfully and AD lookups/authentication worked again. ## Impact This broke SSSD startup and therefore broke AD identity lookup/authentication on an already-joined Ubuntu 26.04 AD client immediately after an unattended package upgrade. This is especially problematic because the failure can occur automatically during unattended-upgrades and may break logins on already-joined systems. ## Additional environment details This is an existing Ubuntu 26.04 AD client using SSSD with the AD provider. The relevant domain configuration is: ``` [sssd] domains = domain.college.edu debug_level = 3 [domain/domain.college.edu] access_provider = ad ad_backup_server = ad1.college.edu ad_domain = domain.college.edu ad_gpo_access_control = disabled ad_maximum_machine_account_password_age = 0 ad_server = dc2.college.edu cache_credentials = True default_shell = /bin/bash fallback_homedir = /home/%u id_provider = ad dyndns_update = False krb5_realm = DOMAIN.COLLEGE.EDU ldap_id_mapping = False ldap_referrals = False max_id = 158999 min_id = 1001 override_homedir = /home/%u use_fully_qualified_names = False ``` This system has a local SSSD systemd drop-in that only changes restart behavior and start-limit behavior. It does not change the SSSD service user, service group, capability bounding set, securebits configuration, or helper binary capabilities. The local AD join automation creates the keytab using `adcli join` and previously did not alter the resulting keytab ownership or mode. The pre-existing `root:root 0600` keytab mode is a common historical state for `/etc/krb5.keytab`. ## Request Please confirm the intended ownership and permissions for `/etc/krb5.keytab` on Ubuntu 26.04 SSSD AD-provider clients after the SSSD 2.12.0 package changes. If `root:sssd 0640` is now required or recommended, please consider adding upgrade handling, release notes, or documentation so existing AD- joined clients do not fail after unattended upgrades. Please also consider improving the error handling/logging so that this condition is reported as a keytab readability/permission problem rather than later surfacing as: ``` Unable to load target [id] [80]: Accessing a corrupted shared library. ``` -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2155002 Title: Update to SSSD 2.12.0-1ubuntu5 breaks AD join due to SSSD inability to read keytab To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2155002/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
