On Чцв, 07 вер 2023, Sam Morris wrote:
On Wed, Sep 06, 2023 at 02:50:32PM +0300, Alexander Bokovoy via FreeIPA-users wrote:
It would help to see logs (krb5kdc.log) from RHEL8 servers for this communication, both on ipa5/ipa6 and back to xoanon.
I've created a script to test this automatically.
Thank you!
I filed https://pagure.io/freeipa/issue/9448 to track this issue. I'll be on vacation next week and Julien (krb5 maintainer) is on vacation too, so we'll look at it after we are both back to work.
[root@xoanon ~]# (set -eu; export SSSD_KRB5_LOCATOR_DISABLE=1; for tgt in 5 6; do for st in 5 6; do for ipa in 5 6; do (export KRB5CCNAME=/tmp/ipa-$tgt-$st-$ipa.cc; KRB5_CONFIG=/tmp/krb5-ipa${tgt}-min.conf kinit -k; if KRB5_CONFIG=/tmp/krb5-ipa${st}-min.conf ipa -v -e xmlrpc_uri=https://ipa$%7Bipa%7D.ipa.example.com/ipa/xml user-show admin 2>&1 | grep -q 'GSSAPI Error'; then result=FAIL; else result=OK; fi; echo $tgt $st $ipa $result); done; done; done) 5 5 5 OK 5 5 6 OK 5 6 5 FAIL 5 6 6 OK 6 5 5 OK 6 5 6 OK 6 6 5 FAIL 6 6 6 OK
Each test case is a line. The numbers tell you:
- which KDC gave the TGT to the client
- which KDC gave the ST for the IPA API to the client
- which IPA server the client made the API request to
... followed by the result.
Analysing the output, it seems that the IPA API running on the RHEL 8 server is not able to perform its constrained delegation request using an evidence ticket that was generated by the RHEL 9 server.
The KDC from which the client obtains its TGT doesn't affect the result.
Here are the krb5.conf files used in the testing:
[root@xoanon ~]# cat /tmp/krb5-ipa5-min.conf include /etc/krb5.conf
[realms] IPA.EXAMPLE.COM = { kdc = ipa5.ipa.example.com }
[root@xoanon ~]# cat /tmp/krb5-ipa5-min.conf include /etc/krb5.conf
[realms] IPA.EXAMPLE.COM = { kdc = ipa5.ipa.example.com }
(BTW, is there something I can put into /etc/ipa/default.conf to prevent the ipa client from reacting to the error from the server under test by making another request to another server? It would cut down on noise in the output/logs).
Here are the log messages from one of the failed test cases, first we see the service ticket for ipa5 being requested fron ipa6:
Sep 07 09:24:40 ipa6.ipa.example.com krb5kdc[207733](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25)}) 192.168.88.3: ISSUE: authtime 1694078668, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, host/xoanon.ipa.example.com@IPA.EXAMPLE.COM for HTTP/ipa5.ipa.example.com@IPA.EXAMPLE.COM Sep 07 09:24:40 ipa6.ipa.example.com krb5kdc[207733](info): closing down fd 11
Then on ipa5 we see the constrained delegation request from its API server fail:
Sep 07 09:24:40 ipa5.ipa.example.com krb5kdc[239017](info): TGS_REQ : handle_authdata (-1765328371) Sep 07 09:24:40 ipa5.ipa.example.com krb5kdc[239017](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25)}) 192.168.88.5: HANDLE_AUTHDATA: authtime 1694078668, etypes {rep=UNSUPPORTED:(0)} HTTP/ipa5.ipa.example.com@IPA.EXAMPLE.COM for ldap/ipa5.ipa.example.com@IPA.EXAMPLE.COM, KDC can't fulfill requested option Sep 07 09:24:40 ipa5.ipa.example.com krb5kdc[239017](info): ... CONSTRAINED-DELEGATION s4u-client=host/xoanon.ipa.example.com@IPA.EXAMPLE.COM Sep 07 09:24:40 ipa5.ipa.example.com krb5kdc[239017](info): closing down fd 12
Finally on ipa6 we see the client retrying its API request against ipa6, which involves fetching the service ticket for HTTP/ipa6, followed by ipa6's own constrained delegation request (actaully there are two, and I don't know why, not that it matters).
Sep 07 09:24:40 ipa6.ipa.example.com krb5kdc[207732](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25)}) 192.168.88.3: ISSUE: authtime 1694078668, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, host/xoanon.ipa.example.com@IPA.EXAMPLE.COM for HTTP/ipa6.ipa.example.com@IPA.EXAMPLE.COM Sep 07 09:24:40 ipa6.ipa.example.com krb5kdc[207732](info): closing down fd 11 Sep 07 09:24:40 ipa6.ipa.example.com krb5kdc[207733](info): TGS_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.88.6: ISSUE: authtime 1694078668, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, HTTP/ipa6.ipa.example.com@IPA.EXAMPLE.COM for ldap/ipa6.ipa.example.com@IPA.EXAMPLE.COM Sep 07 09:24:40 ipa6.ipa.example.com krb5kdc[207733](info): ... CONSTRAINED-DELEGATION s4u-client=host/xoanon.ipa.example.com@IPA.EXAMPLE.COM Sep 07 09:24:40 ipa6.ipa.example.com krb5kdc[207733](info): closing down fd 11 Sep 07 09:24:40 ipa6.ipa.example.com krb5kdc[207732](info): TGS_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.88.6: ISSUE: authtime 1694078668, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, HTTP/ipa6.ipa.example.com@IPA.EXAMPLE.COM for ldap/ipa6.ipa.example.com@IPA.EXAMPLE.COM Sep 07 09:24:40 ipa6.ipa.example.com krb5kdc[207732](info): ... CONSTRAINED-DELEGATION s4u-client=host/xoanon.ipa.example.com@IPA.EXAMPLE.COM Sep 07 09:24:40 ipa6.ipa.example.com krb5kdc[207732](info): closing down fd 11
If you want the full logs from the servers and/or the full debug output from the client just let me know and I'll collect them up and mail them to you.
-- Sam Morris https://robots.org.uk/ PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9