On Чцв, 09 сту 2025, Chris Jacobs via FreeIPA-users wrote:
After getting SIDs added to all users and groups, and ensuring all
hosts have krbcanonicalname added, I haven't gotten any further.
After adding the host as an ipa-client, I then run ipa-replica-install
--setup-ca --skip-conncheck --unattended --verbose
--log-file=/root/ipa-replica-install.log and it will finish succesfully.
All seems well until I poke a bit deeper. Setting a current CentOS 7
client to use this host and run ipa -vv ping I receive the error: ipa:
INFO: Connection to https://idm02.mgmt.example.net/ipa/session/json
failed with <ProtocolError for idm02.mgmt.example.net/ipa/session/json:
401 Unauthorized>
ipa: INFO: trying https://ipa02.mgmt.example.net/ipa/session/json
ipa: INFO: Request: {
"id": 0,
"method": "ping",
"params": [
[],
{}
]
}
I had similar issues from another RHEL8 box connecting to this host,
and as near as I can tell, the issue is something arcane with kerberos.
logs from above ipa -vv ping call:
==> /var/log/httpd/error_log <==
[Thu Jan 09 00:23:41.273124 2025] [auth_gssapi:error] [pid 6115:tid
140546118952704] [client 10.0.0.15:51082] Failed to unseal session
data!, referer: https://idm02.mgmt.example.net/ipa/xml
Typically, 'Failed to unseal session data!' tells that you are using a
session that was not produced by this replica at this time frame. Each
session cookie is encrypted by mod_auth_gssapi module with a session key
unique to this machine. The session key is generated on initial startup
of 'httpd' service and is stored in /etc/httpd/alias/ipasession.key.
A sequence of
$ kdestroy
$ kinit
$ ipa ping (or other IPA command)
would force IPA server side to generate valid session.
==> /var/log/httpd/access_log <==
10.0.0.15 - - [09/Jan/2025:00:23:41 +0000] "POST /ipa/session/json HTTP/1.1"
401 2719
==> /var/log/httpd/ssl_request_log <==
[09/Jan/2025:00:23:41 +0000] 10.0.0.15 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 "POST
/ipa/session/json HTTP/1.1" 2719
==> /var/log/krb5kdc.log <==
Jan 09 00:23:41 idm02.mgmt.example.net krb5kdc[6348](info): TGS_REQ (7 etypes
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
camellia256-cts-cmac(26), camellia128-cts-cmac(25),
DEPRECATED:arcfour-hmac(23)}) 10.1.0.50:
S4U2PROXY_MISSING_EXTENDED_KDC_SIGN_IN_EVIDENCE_TKT_PAC: authtime 1736382160,
etypes {rep=UNSUPPORTED:(0)} HTTP/idm02.mgmt.example....@ipa.example.net for
ldap/idm02.mgmt.example....@ipa.example.net, KDC policy rejects request
Jan 09 00:23:41 idm02.mgmt.example.net krb5kdc[6348](info): ...
CONSTRAINED-DELEGATION s4u-client=<unknown>
Jan 09 00:23:41 idm02.mgmt.example.net krb5kdc[6348](info): closing down fd 11
This error (S4U2PROXY_MISSING_EXTENDED_KDC_SIGN_IN_EVIDENCE_TKT_PAC)
happens because an initial Kerberos ticket presented by the client was
obtained from a KDC that cannot have protection against CVE-2022-37967
while idm02 now has it and denies such tickets.
See Julien's talk at FOSDEM 2024:
https://archive.fosdem.org/2024/schedule/event/fosdem-2024-2681-fixing-a-kerberos-vulnerability-with-the-bare-necessities/
for more details.
When you'd do 'kinit' above, make sure you'd do it against idm02 itself.
Or make sure that those clients actually reconfigured to talk to RHEL 8
servers (idm02?) that do work.
==> /var/log/httpd/error_log <==
[Thu Jan 09 00:23:41.292757 2025] [wsgi:error] [pid 5845:tid 140546394371840]
[remote 10.0.0.15:51082] ipa: INFO: 401 Unauthorized: Insufficient access:
SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code
may provide more information (Credential cache is empty)
==> /var/log/httpd/access_log <==
10.0.0.15 - chris.jac...@ipa.example.net [09/Jan/2025:00:23:41 +0000] "POST
/ipa/session/json HTTP/1.1" 401 290
==> /var/log/httpd/ssl_request_log <==
[09/Jan/2025:00:23:41 +0000] 10.0.0.15 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 "POST
/ipa/session/json HTTP/1.1" 290
==> /var/log/krb5kdc.log <==
Jan 09 00:23:41 idm02.mgmt.example.net krb5kdc[6348](info): TGS_REQ (7 etypes
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
camellia256-cts-cmac(26), camellia128-cts-cmac(25),
DEPRECATED:arcfour-hmac(23)}) 10.1.0.50:
S4U2PROXY_MISSING_EXTENDED_KDC_SIGN_IN_EVIDENCE_TKT_PAC: authtime 1736382160,
etypes {rep=UNSUPPORTED:(0)} HTTP/idm02.mgmt.example....@ipa.example.net for
ldap/idm02.mgmt.example....@ipa.example.net, KDC policy rejects request
Jan 09 00:23:41 idm02.mgmt.example.net krb5kdc[6348](info): ...
CONSTRAINED-DELEGATION s4u-client=<unknown>
Jan 09 00:23:41 idm02.mgmt.example.net krb5kdc[6348](info): closing down fd 11
==> /var/log/httpd/error_log <==
[Thu Jan 09 00:23:41.314422 2025] [wsgi:error] [pid 5844:tid 140546394371840]
[remote 10.0.0.15:51084] ipa: INFO: 401 Unauthorized: Insufficient access:
SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code
may provide more information (Credential cache is empty)
==> /var/log/httpd/access_log <==
10.0.0.15 - chris.jac...@ipa.example.net [09/Jan/2025:00:23:41 +0000] "POST
/ipa/session/json HTTP/1.1" 401 290
==> /var/log/httpd/ssl_request_log <==
[09/Jan/2025:00:23:41 +0000] 10.0.0.15 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 "POST
/ipa/session/json HTTP/1.1" 290
==> /var/log/messages <==
Jan 9 00:23:41 idm02 [5845]: GSSAPI Error: Unspecified GSS failure. Minor
code may provide more information (Credential cache is empty)
Jan 9 00:23:41 idm02 [5844]: GSSAPI Error: Unspecified GSS failure. Minor
code may provide more information (Credential cache is empty)
I have verified permission of /run/ipa/ccache, I have tried after reboots, and
I also found this seemingly related error in slapd log:
[09/Jan/2025:00:09:03.758725886 +0000] - ERR - set_krb5_creds - Could not get
initial credentials for principal [ldap/idm02.mgmt.example....@ipa.example.net]
in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text))
I have the same issues with default crypto policies, DEFAULT:AD-SUPPORT and
LEGACY:AD-SUPPORT.
ipa packages:
ipa-client-4.9.13-14.module+el8.10.0+22574+12a10600.x86_64
ipa-client-common-4.9.13-14.module+el8.10.0+22574+12a10600.noarch
ipa-common-4.9.13-14.module+el8.10.0+22574+12a10600.noarch
ipa-healthcheck-0.12-4.module+el8.10.0+22138+e77d88cf.noarch
ipa-healthcheck-core-0.12-4.module+el8.10.0+22138+e77d88cf.noarch
ipa-selinux-4.9.13-14.module+el8.10.0+22574+12a10600.noarch
ipa-server-4.9.13-14.module+el8.10.0+22574+12a10600.x86_64
ipa-server-common-4.9.13-14.module+el8.10.0+22574+12a10600.noarch
The old CentOS 7 ipa nodes are running latest available to them from centos
repos: 4.6.8
End goal: get RHEL8 idm nodes up and running to take over for the
existing ipa nodes (I think all I'll need to do once I get these RHEL8
IDM nodes up and running well is set one them as the CA and CRL master
and then slowly snip the old C7 IPA nodes).
I'm at my wits end here and seem to have hit a roadblock. Any help
would be appreciated.
Thanks,
- chris
--
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
/ 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-le...@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.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
