** Description changed: [ Impact ] - * An explanation of the effects of the bug on users and justification - for backporting the fix to the stable release. - - * In addition, it is helpful, but not required, to include an - explanation of how the upload fixes this bug. + 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 ] - - * detailed instructions how to reproduce the bug - - * these should allow someone who is not familiar with the affected - package to reproduce the bug and verify that the updated package - fixes the problem. - - * if other testing is appropriate to perform before landing this - update, this should also be described here. + 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]. + [ 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. + * 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 + * 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. ```
-- 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
