** 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.
+
+ [ 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.
+
+ [ 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
+
+ [ 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
