#4081 systemctl status sssd says No such file or directory about "default" when keytab exists but is empty file
Closed: Fixed a year ago by pbrezina. Opened 2 years ago by atikhonov.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 8): Bug 1748292

Description of problem:

When the /etc/krb5.keytab file exists but is empty for whatever reason, the
error message given by SSSD in journal is confusing, citing missing file
"default" as a reason.

Version-Release number of selected component (if applicable):

sssd-krb5-common-2.2.0-16.el8.x86_64

How reproducible:

Deterministic.

Steps to Reproduce:
1. Have RHEL 8 and IPA-enrol it using ipa-client-install.
2. Check that /etc/krb5.keytab exists and is non-empty.
3. Run echo -n > /etc/krb5.keytab
4. Run systemctl restart sssd
5. Run systemctl status sssd

Actual results:

Job for sssd.service failed because the control process exited with error code.
See "systemctl status sssd.service" and "journalctl -xe" for details.

‚óŹ sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor
preset: enabled)
   Active: failed (Result: exit-code) since Tue 2019-09-03 06:03:24 EDT; 21s
ago
  Process: 16431 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited,
status=1/FAILURE)
 Main PID: 16431 (code=exited, status=1/FAILURE)

Sep 03 06:03:23 machine.example.com sssd[sudo][16443]: Starting up
Sep 03 06:03:23 machine.example.com sssd[pam][16444]: Starting up
Sep 03 06:03:23 machine.example.com sssd[pac][16445]: Starting up
Sep 03 06:03:24 machine.example.com sssd[be[example.test]][16446]: Starting up
Sep 03 06:03:24 machine.example.com sssd[be[example.test]][16446]: Failed to
read keytab [default]: No such file or directory
Sep 03 06:03:24 machine.example.com sssd[16431]: Exiting the SSSD. Could not
restart critical service [example.test].
Sep 03 06:03:24 machine.example.com sssd[be[implicit_files]][16432]: Shutting
down
Sep 03 06:03:24 machine.example.com systemd[1]: sssd.service: Main process
exited, code=exited, status=1/FAILURE
Sep 03 06:03:24 machine.example.com systemd[1]: sssd.service: Failed with
result 'exit-code'.
Sep 03 06:03:24 machine.example.com systemd[1]: Failed to start System Security
Services Daemon.

Expected results:

I'd expect the "Failed to read keytab" error message to read something like

Sep 03 06:03:24 machine.example.com sssd[be[example.test]][16446]: Failed to
read keytab [/etc/krb5.keytab]: It exists but does not look like a valid keytab
file

Additional info:

Metadata Update from @atikhonov:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1748292

2 years ago

Metadata Update from @atikhonov:
- Issue assigned to atikhonov

2 years ago

PR: https://github.com/SSSD/sssd/pull/883

With this patch in this case:

  • journal says:
Failed to read keytab [default]: No suitable principal found in keytab
  • /var/log/sssd_$backend.log says:
[find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed: Unsupported key table format version number

(getting exactly this message into journal log is a little bit tricky)

Metadata Update from @atikhonov:
- Issue tagged with: PR

2 years ago

I still really want to know how people keep ending up with empty files at /etc/krb5.keytab. None of our tooling makes those...

  • master
    • e778fa1 - util/sss_krb5: debug messages fixes
    • 716aeba - util/sss_krb5: fixed few memory handling issues
    • 8f27546 - util/sss_krb5: find_principal_in_keytab() was amended
    • 5086353 - util/sss_krb5.c: elimination of unreachable code

Metadata Update from @pbrezina:
- Issue status updated to: Open (was: Closed)

a year ago

Metadata Update from @pbrezina:
- Custom field design_review adjusted to on
- Custom field mark adjusted to on
- Custom field patch adjusted to on
- Custom field review adjusted to on
- Custom field sensitive adjusted to on
- Custom field testsupdated adjusted to on
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

a year ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/5046

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata