On Аўт, 05 вер 2023, Sam Morris via FreeIPA-users wrote:
On Mon, Sep 04, 2023 at 06:43:02PM +0100, Sam Morris via FreeIPA-users wrote:
I get the same when I run it on ipa3 (also running RHEL 8).
I changed 'server' in /etc/ipa/default.conf to point to this server and I see the same errors:
Sep 05 14:02:49 ipa3.ipa.example.com krb5kdc[1715](info): TGS_REQ : handle_authdata (-1765328371) Sep 05 14:02:49 ipa3.ipa.example.com krb5kdc[1715](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)}) 157.90.149.68: HANDLE_AUTHDATA: authtime 1693922568, etypes {rep=UNSUPPORTED:(0)} HTTP/ipa3.ipa.example.com@IPA.EXAMPLE.COM for ldap/ipa3.ipa.example.com@IPA.EXAMPLE.COM, KDC can't fulfill requested option Sep 05 14:02:49 ipa3.ipa.example.com krb5kdc[1715](info): ... CONSTRAINED-DELEGATION s4u-client=host/xoanon.ipa.example.com@IPA.EXAMPLE.COM
I had a look through the kdc logs with the following command:
$ grep -h -A2 'TGS_REQ : handle_authdata' /var/log/krb5kdc.log-* /var/log/krb5kdc.log
... and the results are interesting. It seems that since May 12, my RHEL 8 servers started refusing to perform constrained delegation requests for both user and host/service principals.
The failures for users stopped after I ran 'ipa config-mod --enable-sid --add-sids' as kindly recommended by Alex in the thread at https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/RSAXURG6AR3MWONR3CZSOOI5ULDB2UVC/.
But since then, the RHEL 8 servers have continued to fail to process constrained delegation requests on behalf of host and service principals.
In another reply in this thread, Alex wrote:
Since the client here is host/xoanon.ipa.example.com, this means this client most likely has no SID associated with it and cannot be associated with any of the two supported classes of PAC-enabled services: IPA servers and IPA clients. Otherwise it would have had a PAC in the ticket.
Now that I understand a little more about what's going on I have found that I can reproduce this problem without having to involve dogtag and certmonger.
I believe this problem prevents any IPA API from a host or service princpal from succeding, when the request is being processed on a RHEL 8 server, for the reason that the kdc refuses the constrained delegation request made by the API to get a ticket to the ldap server on behalf of the client.
[root@xoanon ~]# KRB5_CLIENT_KTNAME=/etc/hitron-exporter.keytab kinit -V -c /tmp/hitron.cc -k -i Using specified cache: /tmp/hitron.cc Using principal: HTTP/hitron-exporter.ipa.example.com@IPA.EXAMPLE.COM Authenticated to Kerberos v5
[root@xoanon ~]# KRB5CCNAME=/tmp/hitron.cc ipa -d service-show HTTP/hitron-exporter.ipa.example.com [...] ipa: DEBUG: trying https://ipa5.ipa.example.com/ipa/session/json ipa: DEBUG: New HTTP connection (ipa5.ipa.example.com) ipa: DEBUG: HTTP connection destroyed (ipa5.ipa.example.com) Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/ipalib/rpc.py", line 730, in single_request response.msg) xmlrpc.client.ProtocolError: <ProtocolError for ipa5.ipa.example.com/ipa/session/json: 401 Unauthorized> ipa: DEBUG: trying https://ipa5.ipa.example.com/ipa/session/json ipa: DEBUG: New HTTP connection (ipa5.ipa.example.com) ipa: DEBUG: HTTP connection destroyed (ipa5.ipa.example.com) Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/ipalib/rpc.py", line 730, in single_request response.msg) xmlrpc.client.ProtocolError: <ProtocolError for ipa5.ipa.example.com/ipa/session/json: 401 Unauthorized> ipa: INFO: Connection to https://ipa5.ipa.example.com/ipa/session/json failed with <ProtocolError for ipa5.ipa.example.com/ipa/session/json: 401 Unauthorized> [... client goes on to try ipa6, an RHEL 9 server, which works ...]
On ipa5:
Sep 05 14:53:10 ipa5.ipa.example.com krb5kdc[223385](info): TGS_REQ : handle_authdata (-1765328371) Sep 05 14:53:10 ipa5.ipa.example.com krb5kdc[223385](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 1693925569, 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 05 14:53:10 ipa5.ipa.example.com krb5kdc[223385](info): ... CONSTRAINED-DELEGATION s4u-client=HTTP/hitron-exporter.ipa.example.com@IPA.EXAMPLE.COM
In most cases python-ipaclient automatically retries, and eventually hits a RHEL 9 server which is why I hadn't noticed until now. It's only certmonger's ipa-getcert command that gives up immediately instead of trying another server.
If you're reading along and have an up-to-date RHEL 8 environment, please try calling the IPA API on behalf of a host or service principal and report the result. In the mean time I'll see if I can reproduce this on a fresh CentOS Stream 8 server.
Thanks for these details.
It may well be either IPA part in https://pagure.io/freeipa/blob/master/f/daemons/ipa-kdb/ipa_kdb_mspac_v6.c#_... which means we have more than one PAC buffer returned (unlikely), or ipadb_check_allowed_to_delegate returns incorrect result.
The latter was fixed quite some time ago and should be in 4.9.11+:
either commit e86807b58c67a607bceb568d206af3b3abc03dea
ipa-kdb: handle empty S4U proxy in allowed_to_delegate
With krb5 1.20, S4U processing code uses a special case of passing an empty S4U proxy to allowed_to_delegate() callback to identify if the server cannot get forwardable S4U2Self tickets according to [MS-PAC] 3.2.5.1.2.
This means we need to ensure NULL proxy is a valid one and return an appropriate response to that.
Fixes: https://pagure.io/freeipa/issue/9083
or commit commit 21d99b457d688528bf7e4dcd64d20f7189d16fec
ipa-kdb: for delegation check, use different error codes before and after krb5 1.20
With MIT krb5 1.20, a call to krb5_db_check_allowed_to_delegate() and krb5_db_check_allowed_to_delegate_from() expects to return either KRB5KDC_ERR_BADOPTION for a policy denial or KRB5_PLUGIN_OP_NOTSUPP in case plugin does not handle the policy case. This is part of the MIT krb5 commit a441fbe329ebbd7775eb5d4ccc4a05eef370f08b which added a minimal MS-PAC generator.
Prior to MIT krb5 1.20, the same call was expected to return either KRB5KDC_ERR_POLICY or KRB5_PLUGIN_OP_NOTSUPP errors.
Related: https://pagure.io/freeipa/issue/9083
Since you are saying it started after May 2023, that might be actually the 4.9.11 change. This would affect services which have no constrained delegation rules on defined.
I guess it is actually the first one, may be it is incomplete and returns wrong error code back to krb5 which it doesn't expect.
Can you please give exact versions of krb5 and ipa packages?
Finally, it could be code in handle_signticket() in krb5 1.18 where AD-SIGNEDPATH authdata element is missing. The latter is unlikely too.