Re: Trouble with multiple kerberos ticket caches

[Orion Poplawski <orion@nwra.com>]

[-- Attachment #1: Type: text/plain, Size: 3980 bytes --]

On 5/7/25 10:57, Daniel Kobras wrote:
> Hi!
> 
> Am 06.05.25 um 21:54 schrieb Orion Poplawski:
>> More details.  The issue seems to arise when doing gssapi delegation from a
>> macOS client to the Linux box.  If I have ticket on macOS:
>>
>> Ticket cache: API:427671FC-DB63-442F-ACA4-13A9194F4398
>> Default principal: user@AD.NWRA.COM
>>
>> Valid starting     Expires            Service principal
>> 05/06/25 13:29:54  05/06/25 23:29:54  krbtgt/AD.NWRA.COM@AD.NWRA.COM
>>          renew until 05/13/25 13:29:50
>> 05/06/25 13:30:30  05/06/25 23:29:54  krbtgt/NWRA.COM@AD.NWRA.COM
>> 05/06/25 13:30:30  05/06/25 23:29:54  host/host@NWRA.COM
>>
>> and ssh to the Linux box, I can't access the nfs mount:
>>
>> -bash: /home/user/.bash_profile: Permission denied
>>
>> Ticket cache: KEYRING:persistent:30657:krb_ccache_efgrZpc
>> Default principal: user@AD.NWRA.COM
>>
>> Valid starting     Expires            Service principal
>> 05/06/25 13:30:30  05/06/25 23:29:54  krbtgt/AD.NWRA.COM@AD.NWRA.COM
>>
>> I also notice that the ticket is non-renewable.
>>
>> If I then kinit I can access the home directory fine.  Other than the new
>> ticket being renewable I don't see any difference:
>>
>> Ticket cache: KEYRING:persistent:30657:krb_ccache_efgrZpc
>> Default principal: user@AD.NWRA.COM
>>
>> Valid starting     Expires            Service principal
>> 05/06/25 13:31:27  05/06/25 23:31:27  nfs/server@NWRA.COM
>>          renew until 05/13/25 13:31:22
>> 05/06/25 13:31:27  05/06/25 23:31:27  krbtgt/NWRA.COM@AD.NWRA.COM
>>          renew until 05/13/25 13:31:22
>> 05/06/25 13:31:27  05/06/25 23:31:27  krbtgt/AD.NWRA.COM@AD.NWRA.COM
>>          renew until 05/13/25 13:31:22
>>
>> Actually, I also notice now that there is a krbtgt/NWRA.COM principal as well.
>>   I wonder if that is the difference.
> 
> Can you please check and compare the output of 'klist -ef' (which includes
> additional info on enctypes and flags) in both cases? It sounds like the macOS
> client is forwarding a ticket that is not accepted by the Linux client's krb5
> library. This could happen if eg. the default_tgs_enctypes configured in
> krb5.conf on the macOS side is incompatible with the permitted_enctypes in
> krb5.conf on the Linux side.

That does indeed seem to be the issue - but it seems strange.

On the mac:

Valid starting       Expires              Service principal
05/07/2025 10:50:16  05/07/2025 20:50:16  krbtgt/AD.NWRA.COM@AD.NWRA.COM
       Flags: FPIA, Etype (skey, tkt): aes256-cts-hmac-sha1-96,
aes256-cts-hmac-sha1-96

On the Linux box:

Valid starting       Expires              Service principal
05/07/2025 11:17:25  05/07/2025 20:50:16  krbtgt/AD.NWRA.COM@AD.NWRA.COM
        Flags: FfPA, Etype (skey, tkt): DEPRECATED:arcfour-hmac,
aes256-cts-hmac-sha1-96


The linux box has crypto-policies:

[libdefaults]
permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 camellia256-cts-cmac
camellia128-cts-cmac

Shouldn't that prevent it from ending up with arcfour-hmac in the first place?

I tried adding this to the mac without any change:

[libdefaults]
permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 camellia256-cts-cmac
camellia128-cts-cmac
default_tgs_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 camellia256-cts-cmac
camellia128-cts-cmac

Thanks for the reply.

-- 
Orion Poplawski
he/him/his  - surely the least important thing about me
Manager of IT Systems                      720-772-5637
NWRA, Boulder Office                  FAX: 303-415-9702
3380 Mitchell Lane                       orion@nwra.com
Boulder, CO 80301                 https://www.nwra.com/

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4087 bytes --]