macOS API ccache, kinit for multiple principals gives internal credentials cache error

[A. Karl Kornel]

Hello!

I have run into an issue with krb5 1.21.1 on macOS 14+, related to the 
new API ccache type: If I already have a credential cache, doing a 
`kinit` for a different principal will return "Internal credentials 
cache error while generating new ccache".  However, using macOS 
Kerberos' `kinit` works fine.  I thought to report it here, in case it 
is fixable.

I am running MIT Kerberos 1.21.3, as packaged by MacPorts.  When I do 
these tests, I do not have the KRB5CCNAME environment variable set.

I found that the following sequence of operations ultimately fails:

* MIT Kerberos `kdestroy -A`
* MIT Kerberos `kinit -F akkornel at stanford.edu` -- works
* MIT Kerberos `kinit -F akkornel/root at stanford.edu` -- fails
* MIT Kerberos `klist -l` -- lists one ccache, for akkornel at stanford.edu

But these sequences work:

* MIT Kerberos `kdestroy -A`
* MIT Kerberos `kinit -F akkornel at stanford.edu` -- works
* macOS/Heimdal Kerberos `kinit --no-forward akkornel/root at stanford.edu` 
-- works
* MIT Kerberos `klist -l` -- lists both ccaches

* MIT Kerberos `kdestroy -A`
* macOS/Heimdal Kerberos `kinit --no-forward akkornel at stanford.edu` -- 
works
* macOS/Heimdal Kerberos `kinit --no-forward akkornel/root at stanford.edu` 
-- works
* MIT Kerberos `klist -l` -- lists both ccaches

In other words...

* MIT Kerberos is able to see and use all API ccaches.
* MIT Kerberos can only create a new API ccache if none exists.
* macOS/Heimdal Kerberos can create a new API ccache, even if one 
already exists.

I decided to try clearing everything with `kdestroy -A`, and then 
running MIT Kerberos commands with KRB_TRACE set.  Here are the outputs 
from the first sequence that I listed above.

My first `kinit` works fine:

FV9D5J4T23:~ akkornel(nc)$ KRB5_TRACE=/dev/stderr kinit -F 
akkornel at stanford.edu
2025-02-12T14:56:46 set-error: -1765328243: no credential for 
D61D8910-6938-4563-8FA0-7B38147AA094
2025-02-12T14:56:46 set-error: -1765328243: no credential for 
D61D8910-6938-4563-8FA0-7B38147AA094
2025-02-12T14:56:46 set-error: -1765328243: no credential for 
D61D8910-6938-4563-8FA0-7B38147AA094
2025-02-12T14:56:46 set-error: -1765328243: no credential for 
D61D8910-6938-4563-8FA0-7B38147AA094
2025-02-12T14:56:46 set-error: -1765328242: Reached end of credential 
caches
[25286] 1739401006.849757: Matching akkornel at stanford.edu in collection 
with result: -1765328243/Can't find client principal 
akkornel at stanford.edu in cache collection
[25286] 1739401006.849758: Getting initial credentials for 
akkornel at stanford.edu
... snip ...
[25286] 1739401017.285780: FAST negotiation: available
[25286] 1739401017.285781: Resolving unique ccache of type MEMORY
[25286] 1739401017.285782: Initializing MEMORY:mnLlukm with default 
princ akkornel at stanford.edu
[25286] 1739401017.285783: Storing config in MEMORY:mnLlukm for 
krbtgt/stanford.edu at stanford.edu: fast_avail: yes
[25286] 1739401017.285784: Storing akkornel at stanford.edu -> 
krb5_ccache_conf_data/fast_avail/krbtgt\/stanford.edu\@stanford.edu at X-CACHECONF: 
in MEMORY:mnLlukm
[25286] 1739401017.285785: Storing config in MEMORY:mnLlukm for 
krbtgt/stanford.edu at stanford.edu: pa_type: 2
[25286] 1739401017.285786: Storing akkornel at stanford.edu -> 
krb5_ccache_conf_data/pa_type/krbtgt\/stanford.edu\@stanford.edu at X-CACHECONF: 
in MEMORY:mnLlukm
[25286] 1739401017.285787: Storing akkornel at stanford.edu -> 
krbtgt/stanford.edu at stanford.edu in MEMORY:mnLlukm
[25286] 1739401017.285788: Moving ccache MEMORY:mnLlukm to 
API:D61D8910-6938-4563-8FA0-7B38147AA094
[25286] 1739401017.285789: Initializing 
API:D61D8910-6938-4563-8FA0-7B38147AA094 with default princ 
akkornel at stanford.edu
2025-02-12T14:56:57 set-error: -1765328243: no credential for 
D61D8910-6938-4563-8FA0-7B38147AA094
[25286] 1739401017.285790: Storing akkornel at stanford.edu -> 
krb5_ccache_conf_data/fast_avail/krbtgt\/stanford.edu\@stanford.edu at X-CACHECONF: 
in API:D61D8910-6938-4563-8FA0-7B38147AA094
[25286] 1739401017.285791: Storing akkornel at stanford.edu -> 
krb5_ccache_conf_data/pa_type/krbtgt\/stanford.edu\@stanford.edu at X-CACHECONF: 
in API:D61D8910-6938-4563-8FA0-7B38147AA094
[25286] 1739401017.285792: Storing akkornel at stanford.edu -> 
krbtgt/stanford.edu at stanford.edu in 
API:D61D8910-6938-4563-8FA0-7B38147AA094
[25286] 1739401017.285793: Destroying ccache MEMORY:mnLlukm

My second `kinit` attempt errors out very quickly:

FV9D5J4T23:~ akkornel(p)$ KRB5_TRACE=/dev/stderr kinit -F 
akkornel/root at stanford.edu
2025-02-12T14:57:02 set-error: -1765328242: Reached end of credential 
caches
[25366] 1739401022.226472: Matching akkornel/root at stanford.edu in 
collection with result: -1765328243/Can't find client principal 
akkornel/root at stanford.edu in cache collection
[25366] 1739401022.226473: Resolving unique ccache of type API
2025-02-12T14:57:02 set-error: -1765328167: unable to find realm of host 
FV9D5J4T23
2025-02-12T14:57:02 set-error: -1765328167: Unable to find realm of self
kinit: Internal credentials cache error while generating new ccache

I don't know if there are any other logs I can capture or debugging that 
I can do, but I'm willing to try!

-- 
~ Karl Kornel