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....@ipa.example.com for
ldap/ipa3.ipa.example....@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....@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....@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....@ipa.example.com for
ldap/ipa5.ipa.example....@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....@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#_334
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.
--
/ 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
