Public bug reported:

## 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.
```

** Affects: sssd (Ubuntu)
     Importance: Undecided
         Status: New

-- 
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

Reply via email to