1. Forum
  2. Usenet
  3. COMP.PROTOCOLS.KERBEROS

  • macOS API ccache, kinit for multiple principals gives internal credenti

    From A. Karl Kornel@21:1/5 to All on Wed Feb 12 15:35:30 2025
    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@stanford.edu` -- works
    * MIT Kerberos `kinit -F akkornel/root@stanford.edu` -- fails
    * MIT Kerberos `klist -l` -- lists one ccache, for akkornel@stanford.edu

    But these sequences work:

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

    * MIT Kerberos `kdestroy -A`
    * macOS/Heimdal Kerberos `kinit --no-forward akkornel@stanford.edu` --
    works
    * macOS/Heimdal Kerberos `kinit --no-forward akkornel/root@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@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@stanford.edu in collection
    with result: -1765328243/Can't find client principal
    akkornel@stanford.edu in cache collection
    [25286] 1739401006.849758: Getting initial credentials for akkornel@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@stanford.edu
    [25286] 1739401017.285783: Storing config in MEMORY:mnLlukm for krbtgt/stanford.edu@stanford.edu: fast_avail: yes
    [25286] 1739401017.285784: Storing akkornel@stanford.edu -> krb5_ccache_conf_data/fast_avail/krbtgt\/stanford.edu\@stanford.edu@X-CACHECONF:
    in MEMORY:mnLlukm
    [25286] 1739401017.285785: Storing config in MEMORY:mnLlukm for krbtgt/stanford.edu@stanford.edu: pa_type: 2
    [25286] 1739401017.285786: Storing akkornel@stanford.edu -> krb5_ccache_conf_data/pa_type/krbtgt\/stanford.edu\@stanford.edu@X-CACHECONF: in MEMORY:mnLlukm
    [25286] 1739401017.285787: Storing akkornel@stanford.edu -> krbtgt/stanford.edu@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@stanford.edu
    2025-02-12T14:56:57 set-error: -1765328243: no credential for D61D8910-6938-4563-8FA0-7B38147AA094
    [25286] 1739401017.285790: Storing akkornel@stanford.edu -> krb5_ccache_conf_data/fast_avail/krbtgt\/stanford.edu\@stanford.edu@X-CACHECONF:
    in API:D61D8910-6938-4563-8FA0-7B38147AA094
    [25286] 1739401017.285791: Storing akkornel@stanford.edu -> krb5_ccache_conf_data/pa_type/krbtgt\/stanford.edu\@stanford.edu@X-CACHECONF: in API:D61D8910-6938-4563-8FA0-7B38147AA094
    [25286] 1739401017.285792: Storing akkornel@stanford.edu -> krbtgt/stanford.edu@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@stanford.edu
    2025-02-12T14:57:02 set-error: -1765328242: Reached end of credential
    caches
    [25366] 1739401022.226472: Matching akkornel/root@stanford.edu in
    collection with result: -1765328243/Can't find client principal akkornel/root@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)