freeipa

#9164 Cross realm s4u2self/s4u2proxy fails
Closed: fixed by frenaud. Opened by krisvandenbergh.

Closed: fixed
Reopen Issue

Issue

I'm on RHEL 8.5 with ipa 4.9.8-7. Doing s4u2self/s4u2proxy works for users within the IDM realm, but not for users from the trusted AD realm. I'm getting:

$ kvno -I user02@AD.EXAMPLE.COM host/client.idm.example.com
kvno: TGT has been revoked while getting credentials for host/client.idm.example.com@IDM.EXAMPLE.COM

Steps to Reproduce

  1. Install ipa 4.9.8-7 on RHEL 8.5
  2. Install Windows 2019 with AD
  3. From IDM, establish two-way trust beween IDM and AD realm
  4. Run "kinit -k" and the above kvno command.

Actual behavior

Throws and error: kvno: TGT has been revoked while getting credentials for host/client.idm.example.com@IDM.EXAMPLE.COM

Expected behavior

No error. kvno should show something like:
host/client.idm.example.com@IDM.EXAMPLE.COM: kvno = 1

Version/Release/Distribution

ipa-server-4.9.8-7.module+el8.6.0+14337+19b76db2.x86_64
ipa-client-4.9.8-7.module+el8.6.0+14337+19b76db2.x86_64
389-ds-base-1.4.3.28-6.module+el8.6.0+14129+983ceada.x86_64
pki-ca-10.12.0-2.module+el8.6.0+14115+8b467244.noarch
krb5-server-1.18.2-14.el8.x86_64

Additional info:

The krb5kdc.log says:

May 27 12:34:47 kerberos.idm.example.com krb5kdc1732: 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.1.42: ISSUE: authtime 1653647627, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, host/client.idm.example.com@IDM.EXAMPLE.COM for krbtgt/AD.EXAMPLE.COM@IDM.EXAMPLE.COM
May 27 12:34:47 kerberos.idm.example.com krb5kdc1732: closing down fd 12
May 27 12:34:47 kerberos.idm.example.com krb5kdc1732: PAC issue: PAC has a SID different from what PAC requester claims. PAC [S-1-5-21-2772319413-1696261159-756038808-1602] vs PAC requester [S-1-5-21-956857513-2416212418-705989587-515]
May 27 12:34:47 kerberos.idm.example.com krb5kdc1732: TGS_REQ : handle_authdata (-1765328364)
May 27 12:34:47 kerberos.idm.example.com krb5kdc1732: 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.1.42: HANDLE_AUTHDATA: authtime 1653647627, etypes {rep=UNSUPPORTED:(0)} host/client.idm.example.com@IDM.EXAMPLE.COM for host/client.idm.example.com@IDM.EXAMPLE.COM, TGT has been revoked
May 27 12:34:47 kerberos.idm.example.com krb5kdc1732: ... PROTOCOL-TRANSITION s4u-client=user02@AD.EXAMPLE.COM
May 27 12:34:47 kerberos.idm.example.com krb5kdc1732: closing down fd 12

I tried to reproduce this with git master on Fedora 36 and Windows 2022 and failed. Instead, I am getting a different known issue in the same scenario: https://pagure.io/freeipa/issue/9124

I have a small patch that attempts to avoid checking requester SID against SID from the PAC of a trusted domain's principal for S4U case but this cannot be properly tested until issue #9124 is fixed.
krisvandenbergh commented

Thanks for feedback.

I can confirm when I do a "ipa-print-pac impersonate" on the IPA server it works for users in the IPA domain, but not for users in the AD domain. In the latter case I also get:

gss_acquire_cred_impersonate_name(): Unspecified GSS failure. Minor code may provide more information
TGT has been revoked

In the krb5kdc.log the same message appears:

PAC issue: PAC has a SID different from what PAC requester claims.

So, it seems my case is indeed a duplicate of #9124.
Edited by krisvandenbergh

It is not exactly, the revoked TGT is an intentional check which in your case went wrong. I know what's wrong but I cannot write a test that would get it working for any Windows Server 2016+ version in my test environments because it gets stumbled on #9124 before reaching the point you have.

I have been looking in detail into what is in there for #9124 past week but had to limit my activities due to flu. ;) So not exactly there yet.

master:

  • e00f457f755e78d384beb8cc7ac312e9741b56af ipa-kdb: hint KDC to use aes256-sha1 for forest trust TGT
  • 4ef8258d58046ee905c929c0e889653a8b86d383 ipa-kdb: protect against context corruption
  • 03897d8a6899691b7218428b296f6d22ccadcfb2 ipa-kdb: postpone ticket checksum configuration
  • d551e853fc4e213cf384bc983d0e76d8568ee954 ipa-kdb: process out of realm server lookup during S4U
  • 9cdf010ca6c8b03d9f7cc338e8253219e0e877b0 ipa-kdb: skip verification of PAC full checksum
  • 18bf495ce88fbb032f23f7db7f941458ecf55c7a ipalib/x509.py: Add signature_algorithm_parameters

ipa-4-10:

  • 3d0decd9efc4883328e95f9ff89002aec32462ec ipa-kdb: hint KDC to use aes256-sha1 for forest trust TGT
  • 803a44777f901217d634f8fd7feed8b66ece352a ipa-kdb: protect against context corruption
  • fefa0248296413b6ee5ad2543d8feb1b31840aee ipa-kdb: postpone ticket checksum configuration
  • bd8fcd6f5bc62a4bfc544b69c0d960291be05d37 ipa-kdb: process out of realm server lookup during S4U
  • 1b55e9b1cb4f192635878b0b7242104d58a37d2b ipa-kdb: skip verification of PAC full checksum
  • 11ce2b2133364916de06f4c42d8a19ce438bd41c ipalib/x509.py: Add signature_algorithm_parameters

Metadata Update from @frenaud:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

master:

  • 3a706e86200dd3ab9d317fb6f71ba80d3ae2f642 ipa-kdb: be compatible with krb5 1.19 when checking for server referral

ipa-4-10:

  • f2b821abca72e0d444c96598799c4947e2173d3f ipa-kdb: be compatible with krb5 1.19 when checking for server referral
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.