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.
--
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-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
