Hi folks. This morning I found that one of my IPA servers no longer wants to authenticate any users (specifically, it doesn't want to issue any TGTs to users).
It's a fully updated RHEL 9 server; I am sure this has only been a problem since upgrading to RHEL 9.2 (see my remarks about krb5kdc.log below); my other servers are on RHEL 8 and are working fine.
Package versions:
ipa-client-common-4.10.1-6.el9.noarch ipa-server-common-4.10.1-6.el9.noarch ipa-healthcheck-core-0.12-1.el9.noarch ipa-selinux-4.10.1-6.el9.noarch ipa-common-4.10.1-6.el9.noarch ipa-client-4.10.1-6.el9.x86_64 ipa-server-4.10.1-6.el9.x86_64 ipa-server-dns-4.10.1-6.el9.noarch ipa-healthcheck-0.12-1.el9.noarch
I see the following syslog messages when trying to SSH in to the server:
May 12 08:34:52 sshd[2207]: main: sshd: ssh-rsa algorithm is disabled May 12 08:34:52 sshd[2207]: Postponed keyboard-interactive for user from 192.168.0.23 port 42210 ssh2 [preauth] May 12 08:34:56 sshd[2207]: Postponed keyboard-interactive/pam for user from 192.168.0.23 port 42210 ssh2 [preauth] May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: request received May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: user query start May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: user query end: uid=user,cn=users,cn=accounts,dc=ipa,dc=example,dc=com May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: bind start: uid=user,cn=users,cn=accounts,dc=ipa,dc=example,dc=com May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: bind end: success May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: sent: 0 data: 20 May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: ..sent: 20 data: 20 May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: response sent: Access-Accept May 12 08:35:02 krb5_child[2213]: Generic error (see e-text) May 12 08:35:02 krb5_child[2213]: Generic error (see e-text) May 12 08:35:02 sshd[2211]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.23 user=user May 12 08:35:02 sshd[2211]: pam_sss(sshd:auth): received for user user: 4 (System error) May 12 08:35:04 sshd[2207]: error: PAM: Authentication failure for user from 192.168.0.23
/var/log/sssd/krb5_child.log gives me:
(2023-05-12 8:39:50): [krb5_child[2271]] [get_and_save_tgt] (0x0020): [RID#79] 2009: [-1765328324][Generic error (see e-text)] ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2023-05-12 8:39:50): [krb5_child[2271]] [main] (0x0400): [RID#79] krb5_child started. * (2023-05-12 8:39:50): [krb5_child[2271]] [unpack_buffer] (0x1000): [RID#79] total buffer size: [140] * (2023-05-12 8:39:50): [krb5_child[2271]] [unpack_buffer] (0x0100): [RID#79] cmd [241 (auth)] uid [2000000503] gid [2000000503] validate [true] enterprise principal [false] offline [false] UPN [user@EXAMPLE.COM] * (2023-05-12 8:39:50): [krb5_child[2271]] [unpack_buffer] (0x0100): [RID#79] ccname: [KCM:] old_ccname: [KCM:] keytab: [/etc/krb5.keytab] * (2023-05-12 8:39:50): [krb5_child[2271]] [switch_creds] (0x0200): [RID#79] Switch user to [2000000503][2000000503]. * (2023-05-12 8:39:50): [krb5_child[2271]] [switch_creds] (0x0200): [RID#79] Switch user to [0][0]. * (2023-05-12 8:39:50): [krb5_child[2271]] [k5c_check_old_ccache] (0x4000): [RID#79] Ccache_file is [KCM:] and is active and TGT is valid. * (2023-05-12 8:39:50): [krb5_child[2271]] [k5c_setup_fast] (0x0100): [RID#79] Fast principal is set to [host/ipa6.example.com@EXAMPLE.COM] * (2023-05-12 8:39:50): [krb5_child[2271]] [find_principal_in_keytab] (0x4000): [RID#79] Trying to find principal host/ipa6.example.com@EXAMPLE.COM in keytab. * (2023-05-12 8:39:50): [krb5_child[2271]] [match_principal] (0x1000): [RID#79] Principal matched to the sample (host/ipa6.example.com@EXAMPLE.COM). * (2023-05-12 8:39:50): [krb5_child[2271]] [check_fast_ccache] (0x0200): [RID#79] FAST TGT is still valid. * (2023-05-12 8:39:50): [krb5_child[2271]] [become_user] (0x0200): [RID#79] Trying to become user [2000000503][2000000503]. * (2023-05-12 8:39:50): [krb5_child[2271]] [main] (0x2000): [RID#79] Running as [2000000503][2000000503]. * (2023-05-12 8:39:50): [krb5_child[2271]] [set_lifetime_options] (0x0100): [RID#79] No specific renewable lifetime requested. * (2023-05-12 8:39:50): [krb5_child[2271]] [set_lifetime_options] (0x0100): [RID#79] No specific lifetime requested. * (2023-05-12 8:39:50): [krb5_child[2271]] [set_canonicalize_option] (0x0100): [RID#79] Canonicalization is set to [true] * (2023-05-12 8:39:50): [krb5_child[2271]] [main] (0x0400): [RID#79] Will perform auth * (2023-05-12 8:39:50): [krb5_child[2271]] [main] (0x0400): [RID#79] Will perform online auth * (2023-05-12 8:39:50): [krb5_child[2271]] [tgt_req_child] (0x1000): [RID#79] Attempting to get a TGT * (2023-05-12 8:39:50): [krb5_child[2271]] [get_and_save_tgt] (0x0400): [RID#79] Attempting kinit for realm [EXAMPLE.COM] * (2023-05-12 8:39:50): [krb5_child[2271]] [sss_krb5_responder] (0x4000): [RID#79] Got question [otp]. * (2023-05-12 8:39:50): [krb5_child[2271]] [get_and_save_tgt] (0x0020): [RID#79] 2009: [-1765328324][Generic error (see e-text)] ********************** BACKTRACE DUMP ENDS HERE *********************************
(2023-05-12 8:39:50): [krb5_child[2271]] [map_krb5_error] (0x0020): [RID#79] 2138: [-1765328324][Generic error (see e-text)]
/var/log/krb5kdc.log gives me a "No such file or directory" error:
May 12 08:41:31 ipa6.example.com krb5kdc[1575](info): AS_REQ (4 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 192.168.0.6: NEEDED_PREAUTH: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, Additional pre-authentication required May 12 08:41:31 ipa6.example.com krb5kdc[1575](info): closing down fd 11 May 12 08:41:31 ipa6.example.com krb5kdc[1575](info): AS_REQ (4 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 192.168.0.6: NEEDED_PREAUTH: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, Additional pre-authentication required May 12 08:41:31 ipa6.example.com krb5kdc[1575](info): closing down fd 11 May 12 08:41:42 ipa6.example.com krb5kdc[1575](info): AS_REQ (4 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 192.168.0.6: NEEDED_PREAUTH: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, Additional pre-authentication required May 12 08:41:42 ipa6.example.com krb5kdc[1575](info): closing down fd 11 May 12 08:41:42 ipa6.example.com krb5kdc[1573](info): AS_REQ (4 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 192.168.0.6: NEEDED_PREAUTH: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, Additional pre-authentication required May 12 08:41:42 ipa6.example.com krb5kdc[1573](info): closing down fd 11 May 12 08:41:42 ipa6.example.com krb5kdc[1573](info): AS_REQ : handle_authdata (2) May 12 08:41:42 ipa6.example.com krb5kdc[1573](info): AS_REQ (4 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 192.168.0.6: HANDLE_AUTHDATA: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, No such file or directory May 12 08:41:42 ipa6.example.com krb5kdc[1573](info): closing down fd 11
There's no instance of this 'No such file or directory' message in krb5kdc.log before this morning, and I did the RHEL 9.2 upgrade on 9th May, just a couple of days ago. So it's possible that this is a problem introduced by the upgrade a couple of days ago, that has been noticed today (perhaps IPA clients were talking to other servers until this morning).
Other IPA servers log an ISSUE message at the same point, so I guess the problem is with krb5kdc, I just don't know what to check next.
Here's the relevant code (I think) in krb5kdc: https://github.com/krb5/krb5/blob/e806d1223329fe4b6d9738237893dda27b616bb6/src/kdc/do_as_req.c#L270.
The user is able to log in to the directory server with a simple bind:
# ldapwhoami -H ldapi://%2frun%2fslapd-EXAMPLE-COM.socket -D uid=user,cn=users,cn=accounts,dc=ipa,dc=example,dc=com -W Enter LDAP Password: dn: uid=user,cn=users,cn=accounts,dc=ipa,dc=example,dc=com
... so dirsrv seems to be working fine.
'ipactl status' reports all services are running. ipa-healthcheck is giving me one failure, I don't think it's relevant to the krb5kdc errors but it's something I'll look into after:
{ "source": "pki.server.healthcheck.clones.connectivity_and_data", "check": "ClonesConnectivyAndDataCheck", "result": "ERROR", "uuid": "eb35c2fd-d292-4426-a1ad-8d1adfc5349a", "when": "20230512084503Z", "duration": "10.003213", "kw": { "status": "ERROR: pki-tomcat : Unable to reach KRA at https://ipa6.example.com:443: Request timed out" } },
I am able to run 'kinit -k', e.g,. get a TGT as host/ipa6.example.com, so it's not like krb5kdc is totally busted. It just doesn't work for users any more!
As always I'd be grateful for any assistance. :)
Please check whether this user had SID from IPA domain. There might also be a problem allocating SIDs, due to incorrect or missing ID range for this user's POSIX ID. In that case there could be sidgen plugin errors in dirsrv errorlog.
Sorry for top post, I'm traveling back from SambaXP...
On Friday, May 12, 2023, Sam Morris via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hi folks. This morning I found that one of my IPA servers no longer wants to authenticate any users (specifically, it doesn't want to issue any TGTs to users).
It's a fully updated RHEL 9 server; I am sure this has only been a problem since upgrading to RHEL 9.2 (see my remarks about krb5kdc.log below); my other servers are on RHEL 8 and are working fine.
Package versions:
ipa-client-common-4.10.1-6.el9.noarch ipa-server-common-4.10.1-6.el9.noarch ipa-healthcheck-core-0.12-1.el9.noarch ipa-selinux-4.10.1-6.el9.noarch ipa-common-4.10.1-6.el9.noarch ipa-client-4.10.1-6.el9.x86_64 ipa-server-4.10.1-6.el9.x86_64 ipa-server-dns-4.10.1-6.el9.noarch ipa-healthcheck-0.12-1.el9.noarch
I see the following syslog messages when trying to SSH in to the server:
May 12 08:34:52 sshd[2207]: main: sshd: ssh-rsa algorithm is disabled May 12 08:34:52 sshd[2207]: Postponed keyboard-interactive for user
from 192.168.0.23 port 42210 ssh2 [preauth]
May 12 08:34:56 sshd[2207]: Postponed keyboard-interactive/pam for
user from 192.168.0.23 port 42210 ssh2 [preauth]
May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: request received May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: user query start May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: user query end:
uid=user,cn=users,cn=accounts,dc=ipa,dc=example,dc=com
May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: bind start:
uid=user,cn=users,cn=accounts,dc=ipa,dc=example,dc=com
May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: bind end: success May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: sent: 0 data: 20 May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: ..sent: 20 data: 20 May 12 08:35:02 ipa-otpd[2200]: user@EXAMPLE.COM: response sent:
Access-Accept
May 12 08:35:02 krb5_child[2213]: Generic error (see e-text) May 12 08:35:02 krb5_child[2213]: Generic error (see e-text) May 12 08:35:02 sshd[2211]: pam_sss(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.23 user=user
May 12 08:35:02 sshd[2211]: pam_sss(sshd:auth): received for user
user: 4 (System error)
May 12 08:35:04 sshd[2207]: error: PAM: Authentication failure for
user from 192.168.0.23
/var/log/sssd/krb5_child.log gives me:
(2023-05-12 8:39:50): [krb5_child[2271]] [get_and_save_tgt]
(0x0020): [RID#79] 2009: [-1765328324][Generic error (see e-text)]
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE
FOLLOWING BACKTRACE:
* (2023-05-12 8:39:50): [krb5_child[2271]] [main] (0x0400):
[RID#79] krb5_child started.
* (2023-05-12 8:39:50): [krb5_child[2271]] [unpack_buffer]
(0x1000): [RID#79] total buffer size: [140]
* (2023-05-12 8:39:50): [krb5_child[2271]] [unpack_buffer]
(0x0100): [RID#79] cmd [241 (auth)] uid [2000000503] gid [2000000503] validate [true] enterprise principal [false] offline [false] UPN [ user@EXAMPLE.COM]
* (2023-05-12 8:39:50): [krb5_child[2271]] [unpack_buffer]
(0x0100): [RID#79] ccname: [KCM:] old_ccname: [KCM:] keytab: [/etc/krb5.keytab]
* (2023-05-12 8:39:50): [krb5_child[2271]] [switch_creds]
(0x0200): [RID#79] Switch user to [2000000503][2000000503].
* (2023-05-12 8:39:50): [krb5_child[2271]] [switch_creds]
(0x0200): [RID#79] Switch user to [0][0].
* (2023-05-12 8:39:50): [krb5_child[2271]]
[k5c_check_old_ccache] (0x4000): [RID#79] Ccache_file is [KCM:] and is active and TGT is valid.
* (2023-05-12 8:39:50): [krb5_child[2271]] [k5c_setup_fast]
(0x0100): [RID#79] Fast principal is set to [host/ ipa6.example.com@EXAMPLE.COM]
* (2023-05-12 8:39:50): [krb5_child[2271]]
[find_principal_in_keytab] (0x4000): [RID#79] Trying to find principal host/ ipa6.example.com@EXAMPLE.COM in keytab.
* (2023-05-12 8:39:50): [krb5_child[2271]] [match_principal]
(0x1000): [RID#79] Principal matched to the sample (host/ ipa6.example.com@EXAMPLE.COM).
* (2023-05-12 8:39:50): [krb5_child[2271]] [check_fast_ccache]
(0x0200): [RID#79] FAST TGT is still valid.
* (2023-05-12 8:39:50): [krb5_child[2271]] [become_user]
(0x0200): [RID#79] Trying to become user [2000000503][2000000503].
* (2023-05-12 8:39:50): [krb5_child[2271]] [main] (0x2000):
[RID#79] Running as [2000000503][2000000503].
* (2023-05-12 8:39:50): [krb5_child[2271]]
[set_lifetime_options] (0x0100): [RID#79] No specific renewable lifetime requested.
* (2023-05-12 8:39:50): [krb5_child[2271]]
[set_lifetime_options] (0x0100): [RID#79] No specific lifetime requested.
* (2023-05-12 8:39:50): [krb5_child[2271]]
[set_canonicalize_option] (0x0100): [RID#79] Canonicalization is set to [true]
* (2023-05-12 8:39:50): [krb5_child[2271]] [main] (0x0400):
[RID#79] Will perform auth
* (2023-05-12 8:39:50): [krb5_child[2271]] [main] (0x0400):
[RID#79] Will perform online auth
* (2023-05-12 8:39:50): [krb5_child[2271]] [tgt_req_child]
(0x1000): [RID#79] Attempting to get a TGT
* (2023-05-12 8:39:50): [krb5_child[2271]] [get_and_save_tgt]
(0x0400): [RID#79] Attempting kinit for realm [EXAMPLE.COM]
* (2023-05-12 8:39:50): [krb5_child[2271]] [sss_krb5_responder]
(0x4000): [RID#79] Got question [otp].
* (2023-05-12 8:39:50): [krb5_child[2271]] [get_and_save_tgt]
(0x0020): [RID#79] 2009: [-1765328324][Generic error (see e-text)]
********************** BACKTRACE DUMP ENDS HERE
*********************************
(2023-05-12 8:39:50): [krb5_child[2271]] [map_krb5_error] (0x0020):
[RID#79] 2138: [-1765328324][Generic error (see e-text)]
/var/log/krb5kdc.log gives me a "No such file or directory" error:
May 12 08:41:31 ipa6.example.com krb5kdc[1575](info): AS_REQ (4
etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 192.168.0.6: NEEDED_PREAUTH: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, Additional pre-authentication required
May 12 08:41:31 ipa6.example.com krb5kdc[1575](info): closing down fd
11
May 12 08:41:31 ipa6.example.com krb5kdc[1575](info): AS_REQ (4
etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 192.168.0.6: NEEDED_PREAUTH: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, Additional pre-authentication required
May 12 08:41:31 ipa6.example.com krb5kdc[1575](info): closing down fd
11
May 12 08:41:42 ipa6.example.com krb5kdc[1575](info): AS_REQ (4
etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 192.168.0.6: NEEDED_PREAUTH: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, Additional pre-authentication required
May 12 08:41:42 ipa6.example.com krb5kdc[1575](info): closing down fd
11
May 12 08:41:42 ipa6.example.com krb5kdc[1573](info): AS_REQ (4
etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 192.168.0.6: NEEDED_PREAUTH: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, Additional pre-authentication required
May 12 08:41:42 ipa6.example.com krb5kdc[1573](info): closing down fd
11
May 12 08:41:42 ipa6.example.com krb5kdc[1573](info): AS_REQ :
handle_authdata (2)
May 12 08:41:42 ipa6.example.com krb5kdc[1573](info): AS_REQ (4
etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 192.168.0.6: HANDLE_AUTHDATA: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, No such file or directory
May 12 08:41:42 ipa6.example.com krb5kdc[1573](info): closing down fd
11
There's no instance of this 'No such file or directory' message in krb5kdc.log before this morning, and I did the RHEL 9.2 upgrade on 9th May, just a couple of days ago. So it's possible that this is a problem introduced by the upgrade a couple of days ago, that has been noticed today (perhaps IPA clients were talking to other servers until this morning).
Other IPA servers log an ISSUE message at the same point, so I guess the problem is with krb5kdc, I just don't know what to check next.
Here's the relevant code (I think) in krb5kdc: <
https://github.com/krb5/krb5/blob/e806d1223329fe4b6d9738237893dda27b616bb6/s...
.
The user is able to log in to the directory server with a simple bind:
# ldapwhoami -H ldapi://%2frun%2fslapd-EXAMPLE-COM.socket -D
uid=user,cn=users,cn=accounts,dc=ipa,dc=example,dc=com -W
Enter LDAP Password: dn: uid=user,cn=users,cn=accounts,dc=ipa,dc=example,dc=com
... so dirsrv seems to be working fine.
'ipactl status' reports all services are running. ipa-healthcheck is giving me one failure, I don't think it's relevant to the krb5kdc errors but it's something I'll look into after:
{ "source": "pki.server.healthcheck.clones.connectivity_and_data", "check": "ClonesConnectivyAndDataCheck", "result": "ERROR", "uuid": "eb35c2fd-d292-4426-a1ad-8d1adfc5349a",
"when": "20230512084503Z", "duration": "10.003213", "kw": { "status": "ERROR: pki-tomcat : Unable to reach KRA at
https://ipa6.example.com:443: Request timed out"
} },
I am able to run 'kinit -k', e.g,. get a TGT as host/ipa6.example.com, so it's not like krb5kdc is totally busted. It just doesn't work for users any more!
As always I'd be grateful for any assistance. :)
-- Sam Morris https://robots.org.uk/ PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9 _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@lists.fedorahoste...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
On Fri, May 12, 2023 at 02:32:48PM +0300, Alexander Bokovoy via FreeIPA-users wrote:
Please check whether this user had SID from IPA domain. There might also be a problem allocating SIDs, due to incorrect or missing ID range for this user's POSIX ID. In that case there could be sidgen plugin errors in dirsrv errorlog.
I've got two users where I'm seeing this - neither have an 'ipaNTSecurityIdentifier' attribute. My (disabled) 'admin' user does have the attribute (with the expected RID of 500).
I can't see any lines with 'sid' in the dirsrv error log file either. The sidgen plugin is enabled...
# ldapsearch -Q -LLL -o ldif-wrap=no -Y EXTERNAL -H ldapi://%2frun%2fslapd-IPA-EXAMPLE-COM.socket -s base -b 'cn=IPA SIDGEN,cn=plugins,cn=config' dn: cn=IPA SIDGEN,cn=plugins,cn=config cn: IPA SIDGEN nsslapd-basedn: dc=ipa,dc=robots,dc=org,dc=uk nsslapd-plugin-depends-on-type: database nsslapd-pluginDescription: Add a SID to newly added or modified objects with uid pr gid numbers nsslapd-pluginEnabled: on nsslapd-pluginId: IPA SIDGEN postop plugin nsslapd-pluginInitfunc: ipa_sidgen_init nsslapd-pluginPath: libipa_sidgen nsslapd-pluginType: postoperation nsslapd-pluginVendor: FreeIPA project nsslapd-pluginVersion: FreeIPA/1.0 objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject
Shall I run the SIDgen task as documented at https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html#troubleshooting-and-debugging or is there any extra info I can dig up first to find out why this didn't run on upgrade?
Wait, according to that page, after upgrading I have to run 'ipa config-mod --enable-sids'... is that right?
Correct, run the task, it will produce some output in the dirsrv errorlog.
On Friday, May 12, 2023, Sam Morris sam@robots.org.uk wrote:
On Fri, May 12, 2023 at 02:32:48PM +0300, Alexander Bokovoy via
FreeIPA-users wrote:
Please check whether this user had SID from IPA domain. There might also
be
a problem allocating SIDs, due to incorrect or missing ID range for this user's POSIX ID. In that case there could be sidgen plugin errors in
dirsrv
errorlog.
I've got two users where I'm seeing this - neither have an 'ipaNTSecurityIdentifier' attribute. My (disabled) 'admin' user does have the attribute (with the expected RID of 500).
I can't see any lines with 'sid' in the dirsrv error log file either. The sidgen plugin is enabled...
# ldapsearch -Q -LLL -o ldif-wrap=no -Y EXTERNAL -H
ldapi://%2frun%2fslapd-IPA-EXAMPLE-COM.socket -s base -b 'cn=IPA SIDGEN,cn=plugins,cn=config'
dn: cn=IPA SIDGEN,cn=plugins,cn=config cn: IPA SIDGEN nsslapd-basedn: dc=ipa,dc=robots,dc=org,dc=uk nsslapd-plugin-depends-on-type: database nsslapd-pluginDescription: Add a SID to newly added or modified
objects with uid pr gid numbers
nsslapd-pluginEnabled: on nsslapd-pluginId: IPA SIDGEN postop plugin nsslapd-pluginInitfunc: ipa_sidgen_init nsslapd-pluginPath: libipa_sidgen nsslapd-pluginType: postoperation nsslapd-pluginVendor: FreeIPA project nsslapd-pluginVersion: FreeIPA/1.0 objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject
Shall I run the SIDgen task as documented at <
https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html#trou...
or is there any extra info I can dig up first to find out why this didn't run on upgrade?
Wait, according to that page, after upgrading I have to run 'ipa config-mod --enable-sids'... is that right?
-- Sam Morris https://robots.org.uk/ PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
Hello,
I had a similar issue with alma9/ipa 4.10 server and wasn't able to authenticate on specific resources (virtual machines) and my problem was that on some of them (debians) there was a missing configuration for hostname. On other parts of infra (alma8/9) the issue was out of sync clock - had to re-adjust zone settings for (alma8 only) few vms and syncing clock made both alma8/9 vms to work properly. I'm almost sure that you've check this, but had to share my last experience with IPA
On Fri, May 12, 2023 at 3:46 PM Alexander Bokovoy via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Correct, run the task, it will produce some output in the dirsrv errorlog.
On Friday, May 12, 2023, Sam Morris sam@robots.org.uk wrote:
On Fri, May 12, 2023 at 02:32:48PM +0300, Alexander Bokovoy via
FreeIPA-users wrote:
Please check whether this user had SID from IPA domain. There might
also be
a problem allocating SIDs, due to incorrect or missing ID range for this user's POSIX ID. In that case there could be sidgen plugin errors in
dirsrv
errorlog.
I've got two users where I'm seeing this - neither have an 'ipaNTSecurityIdentifier' attribute. My (disabled) 'admin' user does have the attribute (with the expected RID of 500).
I can't see any lines with 'sid' in the dirsrv error log file either. The sidgen plugin is enabled...
# ldapsearch -Q -LLL -o ldif-wrap=no -Y EXTERNAL -H
ldapi://%2frun%2fslapd-IPA-EXAMPLE-COM.socket -s base -b 'cn=IPA SIDGEN,cn=plugins,cn=config'
dn: cn=IPA SIDGEN,cn=plugins,cn=config cn: IPA SIDGEN nsslapd-basedn: dc=ipa,dc=robots,dc=org,dc=uk nsslapd-plugin-depends-on-type: database nsslapd-pluginDescription: Add a SID to newly added or modified
objects with uid pr gid numbers
nsslapd-pluginEnabled: on nsslapd-pluginId: IPA SIDGEN postop plugin nsslapd-pluginInitfunc: ipa_sidgen_init nsslapd-pluginPath: libipa_sidgen nsslapd-pluginType: postoperation nsslapd-pluginVendor: FreeIPA project nsslapd-pluginVersion: FreeIPA/1.0 objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject
Shall I run the SIDgen task as documented at <
https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html#trou...
or is there any extra info I can dig up first to find out why this didn't run on upgrade?
Wait, according to that page, after upgrading I have to run 'ipa config-mod --enable-sids'... is that right?
-- Sam Morris https://robots.org.uk/ PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, 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."
On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users wrote:
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?)
This seems to be the case. Specifically I:
1. Removed the ipantsecurityidentifier attribute from a user, and removed ipantuserattrs from the user's objectclass 2. Tried to log in as the user & got the same failures + 'No such file or directory' message in /var/log/krb5kdc.log 3. Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true' within the realm-specific configuration in the realms section 4. Restarted krb5kdc 5. Tried to log in as the user and it worked!
The docs for disable_pac say:
If true, the KDC will not issue PACs for this realm, and S4U2Self and S4U2Proxy operations will be disabled. The default is false, which will permit the KDC to issue PACs. New in release 1.20.
... which doesn't explain that if the KDC can't issue a PAC for some reason then the KDC will fail to issue the TGT. But at least I've gotten to the bottom of things now. :)
"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: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, 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."
... "or on the same server after temporarily setting "disable_pac = true" in kdc.conf, and restarting krb5kdc."
On su, 14 touko 2023, Sam Morris wrote:
On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users wrote:
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?)
This seems to be the case. Specifically I:
- Removed the ipantsecurityidentifier attribute from a user, and removed ipantuserattrs from the user's objectclass
- Tried to log in as the user & got the same failures + 'No such file or directory' message in /var/log/krb5kdc.log
- Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true' within the realm-specific configuration in the realms section
- Restarted krb5kdc
- Tried to log in as the user and it worked!
The docs for disable_pac say:
If true, the KDC will not issue PACs for this realm, and S4U2Self and S4U2Proxy operations will be disabled. The default is false, which will permit the KDC to issue PACs. New in release 1.20.
... which doesn't explain that if the KDC can't issue a PAC for some reason then the KDC will fail to issue the TGT. But at least I've gotten to the bottom of things now. :)
RHEL IdM documentation has a separate chapter related to it.
RHEL 9: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
RHEL 8: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
This documentation is in place since summer 2022.
"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: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, 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."
... "or on the same server after temporarily setting "disable_pac = true" in kdc.conf, and restarting krb5kdc."
You should not be disabling PAC because you are really setting yourself up to an attack with a known exploit out in a wild.
On Mon, May 15, 2023 at 09:28:22AM +0300, Alexander Bokovoy via FreeIPA-users wrote:
On su, 14 touko 2023, Sam Morris wrote:
On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users wrote:
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?)
This seems to be the case. Specifically I:
- Removed the ipantsecurityidentifier attribute from a user, and removed ipantuserattrs from the user's objectclass
- Tried to log in as the user & got the same failures + 'No such file or directory' message in /var/log/krb5kdc.log
- Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true' within the realm-specific configuration in the realms section
- Restarted krb5kdc
- Tried to log in as the user and it worked!
The docs for disable_pac say:
If true, the KDC will not issue PACs for this realm, and S4U2Self and S4U2Proxy operations will be disabled. The default is false, which will permit the KDC to issue PACs. New in release 1.20.
... which doesn't explain that if the KDC can't issue a PAC for some reason then the KDC will fail to issue the TGT. But at least I've gotten to the bottom of things now. :)
RHEL IdM documentation has a separate chapter related to it.
RHEL 9: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
RHEL 8: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
This documentation is in place since summer 2022.
Brilliant. It's interesting that the docs say "As of RHEL 8.6, Kerberos in IdM requires that your IdM objects have SIDs, which are necessary for security based on Privilege Access Certificate (PAC) information.", but I had no problems with authentication on my RHEL 8.6/8.7 servers...
"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: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, 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."
... "or on the same server after temporarily setting "disable_pac = true" in kdc.conf, and restarting krb5kdc."
You should not be disabling PAC because you are really setting yourself up to an attack with a known exploit out in a wild.
Absolutely--I just wanted to document what I'd found out, because there isn't a clear connection documented between the behaviour in RHEL 9.2 with MIT Kerberos 1.20 and the behaviour seen when your IPA users don't have SIDs assigned.
is there a way to do a bulk update of existing users? We have this issue. I can disable the pac, but that might not be a good long term solution ________________________________ From: Sam Morris via FreeIPA-users freeipa-users@lists.fedorahosted.org Sent: Monday, May 15, 2023 8:08 AM To: FreeIPA users list freeipa-users@lists.fedorahosted.org Cc: Alexander Bokovoy abokovoy@redhat.com; Sam Morris sam@robots.org.uk Subject: [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA server
On Mon, May 15, 2023 at 09:28:22AM +0300, Alexander Bokovoy via FreeIPA-users wrote:
On su, 14 touko 2023, Sam Morris wrote:
On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users wrote:
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?)
This seems to be the case. Specifically I:
- Removed the ipantsecurityidentifier attribute from a user, and removed ipantuserattrs from the user's objectclass
- Tried to log in as the user & got the same failures + 'No such file or directory' message in /var/log/krb5kdc.log
- Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true' within the realm-specific configuration in the realms section
- Restarted krb5kdc
- Tried to log in as the user and it worked!
The docs for disable_pac say:
If true, the KDC will not issue PACs for this realm, and S4U2Self and S4U2Proxy operations will be disabled. The default is false, which will permit the KDC to issue PACs. New in release 1.20.
... which doesn't explain that if the KDC can't issue a PAC for some reason then the KDC will fail to issue the TGT. But at least I've gotten to the bottom of things now. :)
RHEL IdM documentation has a separate chapter related to it.
RHEL 9: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
RHEL 8: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
This documentation is in place since summer 2022.
Brilliant. It's interesting that the docs say "As of RHEL 8.6, Kerberos in IdM requires that your IdM objects have SIDs, which are necessary for security based on Privilege Access Certificate (PAC) information.", but I had no problems with authentication on my RHEL 8.6/8.7 servers...
"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: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, 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."
... "or on the same server after temporarily setting "disable_pac = true" in kdc.conf, and restarting krb5kdc."
You should not be disabling PAC because you are really setting yourself up to an attack with a known exploit out in a wild.
Absolutely--I just wanted to document what I'd found out, because there isn't a clear connection documented between the behaviour in RHEL 9.2 with MIT Kerberos 1.20 and the behaviour seen when your IPA users don't have SIDs assigned.
-- Sam Morris https://robots.org.uk/ PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9 _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
OK, so I see the answer to my problem is to run
ipa config-mod --add-sids --enable-sid
But we have old UIDs that with low numbers. It looks like I need to do
ipa idrange-add CS.RUTGERS.EDU_low_id_range --base-id=1 --range-size=200000 --rid-base=200000000 --secondary-rid-base=300000000 ipa idrange-add CS.RUTGERS.EDU_mid_id_range --base-id=600000 --range-size=200000 --rid-base=400000000 --secondary-rid-base=500000000
In order for ipa user-add for those UIDs to work on any system, presumably I have to do that on all IPA servers. Is that OK? I'm assuming new id's where we don't specify a UID will be put in the same range before, which is different on each server.
________________________________ From: Sam Morris via FreeIPA-users freeipa-users@lists.fedorahosted.org Sent: Monday, May 15, 2023 8:08 AM To: FreeIPA users list freeipa-users@lists.fedorahosted.org Cc: Alexander Bokovoy abokovoy@redhat.com; Sam Morris sam@robots.org.uk Subject: [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA server
On Mon, May 15, 2023 at 09:28:22AM +0300, Alexander Bokovoy via FreeIPA-users wrote:
On su, 14 touko 2023, Sam Morris wrote:
On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users wrote:
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?)
This seems to be the case. Specifically I:
- Removed the ipantsecurityidentifier attribute from a user, and removed ipantuserattrs from the user's objectclass
- Tried to log in as the user & got the same failures + 'No such file or directory' message in /var/log/krb5kdc.log
- Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true' within the realm-specific configuration in the realms section
- Restarted krb5kdc
- Tried to log in as the user and it worked!
The docs for disable_pac say:
If true, the KDC will not issue PACs for this realm, and S4U2Self and S4U2Proxy operations will be disabled. The default is false, which will permit the KDC to issue PACs. New in release 1.20.
... which doesn't explain that if the KDC can't issue a PAC for some reason then the KDC will fail to issue the TGT. But at least I've gotten to the bottom of things now. :)
RHEL IdM documentation has a separate chapter related to it.
RHEL 9: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
RHEL 8: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
This documentation is in place since summer 2022.
Brilliant. It's interesting that the docs say "As of RHEL 8.6, Kerberos in IdM requires that your IdM objects have SIDs, which are necessary for security based on Privilege Access Certificate (PAC) information.", but I had no problems with authentication on my RHEL 8.6/8.7 servers...
"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: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, 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."
... "or on the same server after temporarily setting "disable_pac = true" in kdc.conf, and restarting krb5kdc."
You should not be disabling PAC because you are really setting yourself up to an attack with a known exploit out in a wild.
Absolutely--I just wanted to document what I'd found out, because there isn't a clear connection documented between the behaviour in RHEL 9.2 with MIT Kerberos 1.20 and the behaviour seen when your IPA users don't have SIDs assigned.
-- Sam Morris https://robots.org.uk/ PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9 _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
That is definitely an issue with 9.2 as I had 9.1 before with no problem at all
пн, 15 мая 2023 г. в 20:08, Sam Morris via FreeIPA-users freeipa-users@lists.fedorahosted.org:
On Mon, May 15, 2023 at 09:28:22AM +0300, Alexander Bokovoy via FreeIPA-users wrote:
On su, 14 touko 2023, Sam Morris wrote:
On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users wrote:
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?)
This seems to be the case. Specifically I:
- Removed the ipantsecurityidentifier attribute from a user, and removed ipantuserattrs from the user's objectclass
- Tried to log in as the user & got the same failures + 'No such file or directory' message in /var/log/krb5kdc.log
- Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true' within the realm-specific configuration in the realms section
- Restarted krb5kdc
- Tried to log in as the user and it worked!
The docs for disable_pac say:
If true, the KDC will not issue PACs for this realm, and S4U2Self and S4U2Proxy operations will be disabled. The default is false, which will permit the KDC to issue PACs. New in release 1.20.
... which doesn't explain that if the KDC can't issue a PAC for some reason then the KDC will fail to issue the TGT. But at least I've gotten to the bottom of things now. :)
RHEL IdM documentation has a separate chapter related to it.
RHEL 9: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
RHEL 8: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
This documentation is in place since summer 2022.
Brilliant. It's interesting that the docs say "As of RHEL 8.6, Kerberos in IdM requires that your IdM objects have SIDs, which are necessary for security based on Privilege Access Certificate (PAC) information.", but I had no problems with authentication on my RHEL 8.6/8.7 servers...
"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: user@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, 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."
... "or on the same server after temporarily setting "disable_pac = true" in kdc.conf, and restarting krb5kdc."
You should not be disabling PAC because you are really setting yourself up to an attack with a known exploit out in a wild.
Absolutely--I just wanted to document what I'd found out, because there isn't a clear connection documented between the behaviour in RHEL 9.2 with MIT Kerberos 1.20 and the behaviour seen when your IPA users don't have SIDs assigned.
-- Sam Morris https://robots.org.uk/ PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9 _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
freeipa-users@lists.fedorahosted.org