Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1850548 - sssd not renewing/obtaining krb ticket at login
Summary: sssd not renewing/obtaining krb ticket at login
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 32
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: sssd-maintainers
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2020-06-24 13:28 UTC by Gwyn Ciesla
Modified: 2020-07-30 18:56 UTC (History)
10 users (show)

Fixed In Version: sssd-2.3.1-2.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-07-30 18:56:54 UTC
Type: Bug

Attachments (Terms of Use)

Description Gwyn Ciesla 2020-06-24 13:28:54 UTC
Prior to f32, my sssd/krb5 setup allowed login and ensured a current krb5 ticket at login. With f32 it allows login but doesn't obtain or renew a ticket. Manual kinit works fine after login.  The only error I see in the logs at the moment at login time is:

[dp_target_run_constructor] (0x0010): Target [resolver] constructor failed [95]: Operation not supported

Comment 1 Sumit Bose 2020-06-24 15:37:56 UTC

this sounds like SSSD is offline. Can you send the output of

    sssctl domain-status


Comment 2 Gwyn Ciesla 2020-06-24 15:48:43 UTC
sudo sssctl domain-status BAMBOO
Online status: Online

Active servers:
KERBEROS: not connected

Discovered KERBEROS servers:
- bamboo

I can confirm that the kerberos server is online and working.

Comment 3 Sumit Bose 2020-06-24 18:14:05 UTC

is this a setup where Kerberos authentication is configured for local users? If yes, does the local user still has a password in /etc/shadow as well?

Can you send the PAM related messages from /var/log/secure or the journal for an authentication attempt?


Comment 4 Gwyn Ciesla 2020-06-24 19:01:50 UTC
Correct. And it does still have a local password.

Jun 24 08:08:19 gwythsefyll audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun 24 08:08:21 gwythsefyll gdm-password][1925]: gkr-pam: unable to locate daemon control file
Jun 24 08:08:21 gwythsefyll audit[1925]: USER_AUTH pid=1925 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_succeed_if,pam_localuser acct="gwyn" exe="/usr/libexec/gdm-session-worker" hostname=gwythsefyll addr=? terminal=/dev/tty1 res=success'
Jun 24 08:08:21 gwythsefyll gdm-password][1925]: gkr-pam: stashed password to try later in open session

Comment 5 Sumit Bose 2020-06-25 06:07:40 UTC

thanks for the logs. Since there is no message from pam_unix I think this is a known regression caused by the fix for The regression is currently discussed in (sorry, this ticket is mostly private). We can use this ticket here to track the fix for Fedora.

Unfortunately there is no easy work-around. One would be to change one of the passwords (I assume /etc/shadow and Kerberos password are currently the same) then pam_unix should fail if you use the Kerberos password and now SSSD has a chance to do Kerberos authentication. But this of course would only work if this affects just a few users.


Comment 6 Gwyn Ciesla 2020-06-25 13:33:47 UTC
They were the same. I changed the local password. I've not yet tested GDM, but ssh logins work with either password.

Comment 7 Sumit Bose 2020-06-25 19:02:55 UTC

do you get a Kerberos ticket when using the Kerberos password?


Comment 8 Gwyn Ciesla 2020-06-25 19:16:34 UTC
Yes, and I do not when using the local password.

Comment 9 Sumit Bose 2020-06-26 11:20:49 UTC
(In reply to Gwyn Ciesla from comment #8)
> Yes, and I do not when using the local password.


ok, so this works as expected. Jfyi, should fix the issue.


Comment 10 Gwyn Ciesla 2020-06-26 14:45:06 UTC
I built a local set of sssd packages with that patch, and it does indeed work. Thank you!

Comment 11 Pavel Březina 2020-07-02 10:01:10 UTC
Pushed PR:

* `master`
    * ffb9ad1331ac5f5d9bf237666aff19f1def77871 - proxy: use 'x' as default pwfield only for sssd-shadowutils target

Comment 12 Fedora Update System 2020-07-27 14:07:23 UTC
FEDORA-2020-63a418c824 has been submitted as an update to Fedora 32.

Comment 13 Fedora Update System 2020-07-28 15:20:12 UTC
FEDORA-2020-63a418c824 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-63a418c824`
You can provide feedback for this update here:

See also for more information on how to test updates.

Comment 14 Fedora Update System 2020-07-30 18:56:54 UTC
FEDORA-2020-63a418c824 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.