On Fri, May 12, 2023 at 03:45:55PM +0300, Alexander Bokovoy via FreeIPA-users
wrote:
> Correct, run the task, it will produce some output in the dirsrv errorlog.
Ok: I tried to run this on the problematic server, but it seems that
this problem also stops the ipa command working there (I forwarded my
Kerberos TGT to the server, and could see the ipa command using it to
obtain service tickets for each IPA server, but its attempts to access
the API on each server resulted in a 401 error).
So I ran it on a RHEL 8 server and it restarted dirsrv but there weren't
any log messages about sidgen.
I then ran it again with --add-sids and that's fixed things: my users
now have a ipaNTSecurityIdentifier attribute & can authenticate with PAM
again. The ipa command on the RHEL 9.2 server also works again.
Here's the dirsrv error log for this second run with two entries
mentioning sidgen.
[12/May/2023:14:12:02.364564719 +0000] - INFO - slapd_daemon - slapd
started. Listening on All Interfaces port 389 for LDAP requests
[12/May/2023:14:12:02.373456918 +0000] - INFO - slapd_daemon - Listening on
All Interfaces port 636 for LDAPS requests
[12/May/2023:14:12:02.378358290 +0000] - INFO - slapd_daemon - Listening on
/var/run/slapd-IPA-EXAMPLE-COM.socket for LDAPI requests
[12/May/2023:14:12:02.496710111 +0000] - ERR - sidgen_task_thread - [file
ipa_sidgen_task.c, line 194]: Sidgen task starts ...
[12/May/2023:14:12:02.621796891 +0000] - WARN - content-sync-plugin -
sync_update_persist_betxn_pre_op - DB retried operation targets
"uid=adminuser,cn=users,cn=accounts,dc=ipa,dc=example,dc=com"
(op=0x7fa42feb4400 idx_pl=0) => op not changed in PL
[12/May/2023:14:12:02.678466871 +0000] - ERR - sidgen_task_thread - [file
ipa_sidgen_task.c, line 199]: Sidgen task finished [0].
[12/May/2023:14:12:02.910672812 +0000] - ERR - set_krb5_creds - The server
will use the external SASL/GSSAPI credentials cache [FILE:/tmp/krb5cc_389]. If
you want the server to automatically authenticate with its keytab, you must
remove this cache. If you did not intend to use this cache, you will likely
see many SASL/GSSAPI authentication failures.
[12/May/2023:14:12:07.439657344 +0000] - ERR - schema-compat-plugin -
warning: no entries set up under cn=computers,
cn=compat,dc=ipa,dc=example,dc=com
[12/May/2023:14:12:07.449581338 +0000] - ERR - schema-compat-plugin -
Finished plugin initialization.
So that's fixed it, thanks very much! :)
I wonder about the root cause; is this because MIT Kerberos 1.20 always
wants to include a PAC in its issued TGTs, and it gives up if it can't
retrieve a user's SID from the directory? (If so I wonder if setting
disable_pac = true in the realm section of krb5.conf would have worked
around the problem?)
Unless this was all caused by something funky in my environment that I
overlooked, I guess other users are likely to get stuck in the same
situation as me. I didn't see anything in the RHEL 9.2 release notes; a
note in there would be useful, something like:
"After upgrading, krb5kdc may fail to issue TGTs to users who have not
had a SID assigned to their accounts ('ipa user-show user --all' will
not include an ipantsecurityidentifier attribute). In this case
krb5kdc.log will log a message "HANDLE_AUTHDATA: [email protected] for
krbtgt/[email protected], No such file or directory". This can be
fixed by running 'ipa config-mod --enable-sid --add-sids' as an IPA
admin on another IPA server."
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
