From stefan at kania-online.de Fri Feb 7 08:58:25 2025 From: stefan at kania-online.de (Stefan Kania) Date: Fri, 7 Feb 2025 14:58:25 +0100 Subject: kadm5.acl "e" permission Message-ID: <85f142f8-99d7-4a9a-8b0a-20219525fe45@kania-online.de> Hello, in the kadm5.acl the "*" or the "x" gives all permission but not the permission to extract the principal keys for this it the "e" permission. Can some please explain to me how can I extract the principal key if I have the "e" permission. I can't find anything that explain how to do it. Thank you Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From ghudson at mit.edu Fri Feb 7 11:07:05 2025 From: ghudson at mit.edu (Greg Hudson) Date: Fri, 7 Feb 2025 11:07:05 -0500 Subject: kadm5.acl "e" permission In-Reply-To: <85f142f8-99d7-4a9a-8b0a-20219525fe45@kania-online.de> References: <85f142f8-99d7-4a9a-8b0a-20219525fe45@kania-online.de> Message-ID: On 2/7/25 08:58, Stefan Kania wrote: > in the kadm5.acl the "*" or the "x" gives all permission but not the > permission to extract the principal keys for this it the "e" permission. > Can some please explain to me how can I extract the principal key if I > have the "e" permission. I can't find anything that explain how to do it. The kadmin "ktadd -norandkey" command will extract principal keys to a keytab file without generating new keys as it normally does. From stefan at kania-online.de Fri Feb 7 13:07:15 2025 From: stefan at kania-online.de (Stefan Kania) Date: Fri, 7 Feb 2025 19:07:15 +0100 Subject: kadm5.acl "e" permission In-Reply-To: References: <85f142f8-99d7-4a9a-8b0a-20219525fe45@kania-online.de> Message-ID: <29e78a8d-05e2-4732-8b6c-bbe611f7c5df@kania-online.de> Am 07.02.25 um 17:07 schrieb Greg Hudson: > On 2/7/25 08:58, Stefan Kania wrote: >> in the kadm5.acl the "*" or the "x" gives all permission but not the >> permission to extract the principal keys for this it the "e" >> permission. Can some please explain to me how can I extract the >> principal key if I have the "e" permission. I can't find anything that >> explain how to do it. > > The kadmin "ktadd -norandkey" command will extract principal keys to a > keytab file without generating new keys as it normally does. > Thank you, that was exactly what I was looking for :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From karl at kornel.us Wed Feb 12 18:35:30 2025 From: karl at kornel.us (A. Karl Kornel) Date: Wed, 12 Feb 2025 15:35:30 -0800 Subject: macOS API ccache, kinit for multiple principals gives internal credentials cache error Message-ID: <454ad95255b0e02a0ad42e2f2687740e@kornel.us> 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 From kenh at cmf.nrl.navy.mil Wed Feb 12 19:17:42 2025 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Wed, 12 Feb 2025 19:17:42 -0500 Subject: macOS API ccache, kinit for multiple principals gives internal credentials cache error In-Reply-To: <454ad95255b0e02a0ad42e2f2687740e@kornel.us> References: <454ad95255b0e02a0ad42e2f2687740e@kornel.us> Message-ID: <202502130017.51D0Hgug009261@hedwig.cmf.nrl.navy.mil> >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 cannot reproduce this. I was able to use MIT Kerberos to kdestroy -A, kinit to two different principals, and it worked fine. However, some caveats. - We are using our own MIT build with a few custom patches. Nothing that affected the Apple credential cache support (which I contributed to MIT Kerberos so I know how it works). It is based on 1.21.3. - HOWEVER ... I just did a test build of stock MIT Kerberos 1.21.3 and repeated the same steps: works fine. On a long shot I thought that maybe the -F option affected things, so I tried again using that; still worked fine. - I tested on Sequoia (MacOS 15), not Sonoma. I developed this support before Sonoma so I have a hard time believing that it is broken on Sonoma, but I could be wrong. - I tested principals in two different realms. I don't think this should affect anything, but I just wanted to state it for completeness. As a note, it has been my experience that MacPorts can create a dependency hell where package behavior can depend on what you have installed when you go to build a package. For this reason (and others) I exclusively recommend Homebrew to people instead of MacPorts. The way that the MacOS X credential cache support works is that it explicitly links in the MacOS X Kerberos framework when building MIT Kerberos via the '-framework Kerberos' command-line option and then makes calls to the ccapi functions to do the appropriate things. From my memory, Heimdal took a slightly different approach and decided to dlopen that framework library instead and then do the ccapi calls. My gut feeling is that this is a MacPorts problem, but I am open to being proven wrong. I think, however, you're going to have to debug this yourself further; this looks like it is failing inside of api_macos_gen_new(), and is probably failing in either cc_initialize(), cc_context_create_new_ccache(), or cc_ccache_get_name(). --Ken From karl at kornel.us Mon Feb 17 18:18:09 2025 From: karl at kornel.us (A. Karl Kornel) Date: Mon, 17 Feb 2025 15:18:09 -0800 Subject: macOS API ccache, kinit for multiple principals gives internal credentials cache error In-Reply-To: <202502130017.51D0Hgug009261@hedwig.cmf.nrl.navy.mil> References: <454ad95255b0e02a0ad42e2f2687740e@kornel.us> <202502130017.51D0Hgug009261@hedwig.cmf.nrl.navy.mil> Message-ID: <5088ed0bca390db875d6322977d681c6@kornel.us> On 2025-02-12 04:17 PM, Ken Hornstein wrote: > <<>> > > The way that the MacOS X credential cache support works is that it > explicitly links in the MacOS X Kerberos framework when building MIT > Kerberos via the '-framework Kerberos' command-line option and then > makes calls to the ccapi functions to do the appropriate things. From > my memory, Heimdal took a slightly different approach and decided to > dlopen that framework library instead and then do the ccapi calls. > > My gut feeling is that this is a MacPorts problem, but I am open to > being proven wrong. That's entirely possible, and I should've tried to reproduce this on a stock krb5 build first. So, I just did that. I also switched to a macOS 15.3 system, which I'll be using from now on. To confirm, the steps I followed to build krb5: * Cloned from https://github.com/krb5/krb5.git * Checked out tag 'krb5-1.21.3-final' * `mkdir ~/bin/krb5` * `cd src && autoreconf` * `./configure --prefix "$HOME/bin/krb5" --enable-dns-for-realm --disable-pkinit && make && make install` With the build complete, I did the following tests: * `~/bin/krb5/bin/kdestroy -A` * `~/bin/krb5/bin/kinit -F akkornel at stanford.edu` -- works * `~/bin/krb5/bin/kinit -F akkornel/root at stanford.edu` -- fails * `~/bin/krb5/bin/klist -l` -- lists one ccache, for akkornel at stanford.edu So, still failing, unfortunately. > I think, however, you're going to have to debug > this yourself further; this looks like it is failing inside of > api_macos_gen_new(), and is probably failing in either cc_initialize(), > cc_context_create_new_ccache(), or cc_ccache_get_name(). I've never use LLDB before, but I decided to give it a try. On my first try, I got a warning about `kinit` being optimized. So, I erased "~/bin/krb5", set environment variable CFLAGS="-O0 -g", and re-ran the `./configure ? && make && make install`. With the newly-installed non-optimized krb5, I reran my tests and got the same results: * `~/bin/krb5/bin/kdestroy -A` * `~/bin/krb5/bin/kinit -F akkornel at stanford.edu` -- works * `~/bin/krb5/bin/kinit -F akkornel/root at stanford.edu` -- fails * `~/bin/krb5/bin/klist -l` -- lists one ccache, for akkornel at stanford.edu So, debug time! I used? lldb -- ~/bin/krb5/bin/kinit -F akkornel/root at stanford.edu ? to start LLDB. Then ? breakpoint set --name api_macos_gen_new ? to set the breakpoint. I ran until it hit the breakpoint, then started stepping through. * cc_initialize returned returned 0, so not that. * cc_context_create_new_ccache returned 2529639136. There we go. It took me some work, but I eventually realized that cc_context_create_new_ccache wasn't an actual function, and was resolving to the Kerberos Framework's context_create_new_ccache. I'm not sure how to debug macOS Frameworks. I tried single-stepping through assembly, and I noticed execution was making it through the Kerberos Framework and into the Heimdal Framework. And then back into MIT Kerberos code? I think the first parameter is a struct with a ton of pointers, and that's being passed around. I'll continue exploring. I'm also considering setting up a macOS VM?via UTM?to see if this also happens on a completely-clean system. ~ Karl From kenh at cmf.nrl.navy.mil Mon Feb 17 20:09:36 2025 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Mon, 17 Feb 2025 20:09:36 -0500 Subject: macOS API ccache, kinit for multiple principals gives internal credentials cache error In-Reply-To: <5088ed0bca390db875d6322977d681c6@kornel.us> References: <454ad95255b0e02a0ad42e2f2687740e@kornel.us> <202502130017.51D0Hgug009261@hedwig.cmf.nrl.navy.mil> <5088ed0bca390db875d6322977d681c6@kornel.us> Message-ID: <202502180109.51I19a6e000393@hedwig.cmf.nrl.navy.mil> Thanks for digging into this! >* cc_context_create_new_ccache returned 2529639136. There we go. Well, THAT is frustrating. You can see more about the actual API by looking at: $(xcrun --show-sdk-path)/System/Library/Frameworks/Kerberos.framework/Headers/CredentialCache.h But the official errors from those functions start at 201 and only go up to around 230. That's probably one of those OSError codes. Sigh. >It took me some work, but I eventually realized that >cc_context_create_new_ccache wasn't an actual function, and was >resolving to the Kerberos Framework's context_create_new_ccache. Right, this is detailed in the header file; it's really this macro: #define cc_context_create_new_ccache(context, version, principal, ccache) \ ((context) -> functions -> create_new_ccache (context, version, principal, ccache)) >I'm not sure how to debug macOS Frameworks. I tried single-stepping >through assembly, and I noticed execution was making it through the >Kerberos Framework and into the Heimdal Framework. And then back into >MIT Kerberos code? I think the first parameter is a struct with a ton >of pointers, and that's being passed around. Oof, this is "fun", because a lot of those frameworks like to make Objective-C calls and send IPC messages that wait for callbacks. It's a pain. However, some suggestions here. You can get a fair amount of the source code for these pieces from opensource.apple.com (go under "View Releases"). The latest OS release is 15.2, but it doesn't sound like there were changes that affected this behavior. You want the "Heimdal" and "MITKerberosShim" packages. It looks like this is in the MITKerberosShim package, specifically ccache.c. And it looks like it calls the macro LOG_FAILURE(), which calls the function mshim_failure(), in misc.c. It looks like THAT might turn on logging if you create the preference file /Library/Preferences/com.apple.MITKerberosShim and in it set "EnableDebugging" to "true" (looks like it logs via syslog()). Inside of context_create_new_ccache(), it calls: heim_krb5_parse_name heim_krb5_cc_new_unique heim_krb5_cc_initialize So one of those is failing and I think the log information will tell you which one. From THERE ... well, there's a lot of squinting at the source code and seeing which function you're in to try to determine what is happening. It looks like you're mostly in open-source bits so I think it is possible to get much closer to the issue. I really don't understand why I can't reproduce this here, though. Rather frustrating! I created a second test principal in our realm to see if that is the issue, and I can kinit as two different principals just fine. --Ken From kenh at cmf.nrl.navy.mil Mon Feb 17 21:36:07 2025 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Mon, 17 Feb 2025 21:36:07 -0500 Subject: macOS API ccache, kinit for multiple principals gives internal credentials cache error In-Reply-To: <202502180109.51I19a6e000393@hedwig.cmf.nrl.navy.mil> References: <454ad95255b0e02a0ad42e2f2687740e@kornel.us> <202502130017.51D0Hgug009261@hedwig.cmf.nrl.navy.mil> <5088ed0bca390db875d6322977d681c6@kornel.us> <202502180109.51I19a6e000393@hedwig.cmf.nrl.navy.mil> Message-ID: <202502180236.51I2a87U001062@hedwig.cmf.nrl.navy.mil> >Thanks for digging into this! > >>* cc_context_create_new_ccache returned 2529639136. There we go. Following up to myself ... I realized this actually might be a krb5 error code in unsigned form. 2529639136 is -1765328160 as a signed 32 bit integer, and THAT is: % find . -type f -print0 | xargs -0 grep -- -1765328160 ./MITKerberosShim-MITKerberosShim-87/Kerberos/krb5.h:#define KRB5_CONFIG_NODEFREALM (-1765328160L) There's a few spots that might actually return that: % find . -type f -print0 | xargs -0 grep KRB5_CONFIG_NODEFREALM ./Heimdal-Heimdal-693.60.3/lib/krb5/krb5_err.et:error_code KRB5_CONFIG_NODEFREALM, "Configuration file does not specify default realm" ./Heimdal-Heimdal-693.60.3/lib/krb5/get_default_realm.c: return KRB5_CONFIG_NODEFREALM; ./Heimdal-Heimdal-693.60.3/lib/krb5/get_default_realm.c: krb5_set_error_message(context, KRB5_CONFIG_NODEFREALM, ./Heimdal-Heimdal-693.60.3/lib/krb5/get_default_realm.c: return KRB5_CONFIG_NODEFREALM; ./Heimdal-Heimdal-693.60.3/lib/krb5/verify_user.c: ret = KRB5_CONFIG_NODEFREALM; First, do you have a default_realm set in /etc/krb5.conf ? Maybe that would fix it, and that would explain why it works for me. In api_macos_gen_new(), we call cc_context_create_new_ccache() with: err = cc_context_create_new_ccache(cc_context, cc_credentials_v5, "", &cc_ccache); The third argument is supposed to be the principal name, and I thought "" was valid, but maybe technically it isn't, especially if you don't have a principal name defined? What to put in there is a bit of a puzzle, as in that API call we don't have access to a principal name. I suspect anything that looks like a valid Kerberos principal would work fine. Might have to look at what others do in this situation. --Ken From karl at kornel.us Tue Feb 18 14:05:10 2025 From: karl at kornel.us (A. Karl Kornel) Date: Tue, 18 Feb 2025 11:05:10 -0800 Subject: macOS API ccache, kinit for multiple principals gives internal credentials cache error In-Reply-To: <202502180109.51I19a6e000393@hedwig.cmf.nrl.navy.mil> References: <454ad95255b0e02a0ad42e2f2687740e@kornel.us> <202502130017.51D0Hgug009261@hedwig.cmf.nrl.navy.mil> <5088ed0bca390db875d6322977d681c6@kornel.us> <202502180109.51I19a6e000393@hedwig.cmf.nrl.navy.mil> Message-ID: On 2025-02-17 05:09 PM, Ken Hornstein wrote: > Thanks for digging into this! You're welcome! It's been an interesting experience. > <<>> >> It took me some work, but I eventually realized that >> cc_context_create_new_ccache wasn't an actual function, and was >> resolving to the Kerberos Framework's context_create_new_ccache. > > Right, this is detailed in the header file; it's really this macro: > > #define cc_context_create_new_ccache(context, version, > principal, ccache) \ > ((context) -> functions -> create_new_ccache (context, version, > principal, ccache)) Yup, that's what I discovered. > <<>> > However, some suggestions here. You can get a fair amount of the > source > code for these pieces from opensource.apple.com (go under "View > Releases"). > The latest OS release is 15.2, but it doesn't sound like there were > changes that affected this behavior. You want the "Heimdal" and > "MITKerberosShim" packages. I had found the Heimdal software on http://github.com/apple-oss-distributions/Heimdal. I did not think to look for anything else, but indeed, there it is on GitHub at https://github.com/apple-oss-distributions/MITKerberosShim. > It looks like this is in the MITKerberosShim package, specifically > ccache.c. And it looks like it calls the macro LOG_FAILURE(), which > calls the function mshim_failure(), in misc.c. It looks like THAT > might > turn on logging if you create the preference file When I was stepping through assembly, LLDB was able to give me symbol names from the Frameworks, and I recognize `mshim_failure` in that list. > /Library/Preferences/com.apple.MITKerberosShim > > and in it set "EnableDebugging" to "true" (looks like it logs via > syslog()). > > Inside of context_create_new_ccache(), it calls: > > heim_krb5_parse_name > heim_krb5_cc_new_unique > heim_krb5_cc_initialize > > So one of those is failing and I think the log information will tell > you > which one. From THERE ... well, there's a lot of squinting at the > source > code and seeing which function you're in to try to determine what is > happening. It looks like you're mostly in open-source bits so I think > it is possible to get much closer to the issue. Got it. I'll remember that, in case it's needed. ~ Karl From karl at kornel.us Tue Feb 18 16:39:43 2025 From: karl at kornel.us (A. Karl Kornel) Date: Tue, 18 Feb 2025 13:39:43 -0800 Subject: macOS API ccache, kinit for multiple principals gives internal credentials cache error In-Reply-To: <202502180236.51I2a87U001062@hedwig.cmf.nrl.navy.mil> References: <454ad95255b0e02a0ad42e2f2687740e@kornel.us> <202502130017.51D0Hgug009261@hedwig.cmf.nrl.navy.mil> <5088ed0bca390db875d6322977d681c6@kornel.us> <202502180109.51I19a6e000393@hedwig.cmf.nrl.navy.mil> <202502180236.51I2a87U001062@hedwig.cmf.nrl.navy.mil> Message-ID: <4040dfb6c7974cb50a43f46ff65a8ae0@kornel.us> On 2025-02-17 06:36 PM, Ken Hornstein wrote: > <<>> > > First, do you have a default_realm set in /etc/krb5.conf ? Maybe that > would fix it, and that would explain why it works for me. I did not actually have a krb5.conf installed on my computer. Stanford has the necessary SRV records in DNS for domain-to-realm lookup, KDC lookup, etc.. Plus, my normal workflow involves using bash aliases to do `kinit`, and those `kinit` commands include the realm name. So, I've never been hurt (until now?) by not having a default realm set. Plus, I didn't know that later macOS even supported putting something at path /etc/krb5.conf! I thought that pretty much everything under / was locked down now. Stanford's canonical krb5.conf is at https://web.stanford.edu/dept/its/support/kerberos/dist/krb5.conf -- I just downloaded it, and was able to install it to /etc/krb5.conf. With the krb5.conf installed, I repeated my original test. Here are the results: * MacPorts MIT Kerberos `kdestroy -A` * MacPorts MIT Kerberos `kinit -F akkornel at stanford.edu` -- works * MacPorts MIT Kerberos `kinit -F akkornel/root at stanford.edu` -- works! * MacPorts MIT Kerberos `klist -l` -- lists two credential caches! To confirm your hypothesis, I edited the downloaded /etc/krb5.conf, removing the default_realm entry. I then re-ran the tests with MIT Kerberos: * MacPorts MIT Kerberos `kdestroy -A` * MacPorts MIT Kerberos `kinit -F akkornel at stanford.edu` -- works * MacPorts MIT Kerberos `kinit -F akkornel/root at stanford.edu` -- fails * MacPorts MIT Kerberos `klist -l` -- lists a single credentials cache, for akkornel at stanford.edu And I then did the same tests with the MIT Kerberos that I built: * `~/bin/krb5/bin/kdestroy -A` * `~/bin/krb5/bin/kinit -F akkornel at stanford.edu` -- works * `~/bin/krb5/bin/kinit -F akkornel/root at stanford.edu` -- fails * `~/bin/krb5/bin/klist -l` -- lists a single credentials cache, for akkornel at stanford.edu So, I think your hypothesis is confirmed: If you already have a credentials cache (created against one principal), and you use `kinit` with a different principal, and you do not have a default realm set, then `kinit` will fail with an "Internal credentials cache error while generating new ccache" error. Still, I would like to get confirmation by looking at the syslog. And it's been a heck of a time trying to figure out how to enable logging. > It looks like this is in the MITKerberosShim package, specifically > ccache.c. And it looks like it calls the macro LOG_FAILURE(), which > calls the function mshim_failure(), in misc.c. It looks like THAT > might > turn on logging if you create the preference file > > /Library/Preferences/com.apple.MITKerberosShim In init_log(), it looks like CopyKeyFromFile() is defined up in misc.c, starting at line 60. It ends up looking for the file at path "/Library/Preferences/com.apple.MITKerberosShim.plist". So, I used these two commands to create the plist and populate it: sudo plutil -create xml1 /Library/Preferences/com.apple.MITKerberosShim.plist sudo plutil -insert EnableDebugging -bool True /Library/Preferences/com.apple.MITKerberosShim.plist Even so, when I check in the Console app, I do not see anything being logged. I do see that mshim_failure() calls init_log(), and it seems to have a mechanism to ensure that log init is only performed once. Maybe I need to reboot? I do have an OS update to do, so I'll leave the plist file created, and see if I start getting debug logs after a reboot. > In api_macos_gen_new(), we call cc_context_create_new_ccache() with: > > err = cc_context_create_new_ccache(cc_context, cc_credentials_v5, > "", > &cc_ccache); > > The third argument is supposed to be the principal name, and I thought > "" was valid, but maybe technically it isn't, especially if you don't > have a principal name defined? I had a look through https://github.com/apple-oss-distributions/Heimdal, looking for calls to `create_new_ccache`. I found create_new_ccache was called at three places: * In acc_get_name(): The code calls _krb5_get_default_principal_local(), uses the resulting principal to call krb5_unparse_name(), and then uses the resulting name in create_new_ccache(). * In acc_initialize(): A principal is provided as a function parameter, which is passed to krb5_unparse_name(), and the resulting name is sent to create_new_ccache(). * In acc_move(): The call is only used if the destination cache does not exist. get_principal() is called with the source cache, and the resulting name is sent to create_new_ccache(). So, at least in Heimdal, all of the call sites for create_new_ccache do provide a principal name. I wonder, maybe there's an alternate path for creating a credentials cache? ~ Karl From kenh at cmf.nrl.navy.mil Tue Feb 18 17:26:29 2025 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Tue, 18 Feb 2025 17:26:29 -0500 Subject: macOS API ccache, kinit for multiple principals gives internal credentials cache error In-Reply-To: <4040dfb6c7974cb50a43f46ff65a8ae0@kornel.us> References: <454ad95255b0e02a0ad42e2f2687740e@kornel.us> <202502130017.51D0Hgug009261@hedwig.cmf.nrl.navy.mil> <5088ed0bca390db875d6322977d681c6@kornel.us> <202502180109.51I19a6e000393@hedwig.cmf.nrl.navy.mil> <202502180236.51I2a87U001062@hedwig.cmf.nrl.navy.mil> <4040dfb6c7974cb50a43f46ff65a8ae0@kornel.us> Message-ID: <202502182226.51IMQTRo011303@hedwig.cmf.nrl.navy.mil> >* MacPorts MIT Kerberos `kdestroy -A` >* MacPorts MIT Kerberos `kinit -F akkornel at stanford.edu` -- works >* MacPorts MIT Kerberos `kinit -F akkornel/root at stanford.edu` -- works! >* MacPorts MIT Kerberos `klist -l` -- lists two credential caches! Ok, great! So that explains that. I couldn't actually reproduce that myself, but maybe it requires a reboot. I'll see if testing that inside of a clean VM makes a difference. The difference here is (as you note in the rest of your email) that all of the other calls to the function cc_context_create_new_ccache() have a principal name. I am guessing that using "" works fine when you have a default realm set, but doesn't if you don't. I dug into this further, as the Heimdal and MIT APIs are MOSTLY the same; this all stems from the call to krb5_cc_gen_new() which does NOT take a principal name. All of the Heimdal/MacOS calls to the ccapi functions do the same thing: their implementation of cc_gen_new() just initializes an internal structure, but the call to create the new credential cache is deferred until the call to krb5_cc_initialze() which DOES take a principal name. So this is a MIT Kerberos bug, and it seems like the two solutions are: 1) use a dummy principal name in the cc_gen_new() function, or 2) defer credential cache creation until cc_initialize() is called. Let me think about the best answer, but either way I'll code up a fix and submit it to MIT so it should get fixed upstream eventually. --Ken From stefan at kania-online.de Wed Feb 26 13:39:19 2025 From: stefan at kania-online.de (Stefan Kania) Date: Wed, 26 Feb 2025 19:39:19 +0100 Subject: define own SRV-record Message-ID: <4c320b53-995e-4d44-983e-361380bdc234@kania-online.de> Hi to all, I'm having the following problem: I set up an openldap with kerberos, now I want to add the srv-records for Kerberos, but as DNS-Server we MUST use a DNS-Server from Active Directory. So I can't add a srv-record _kerberos._tcp, because the domain controller of the AD are keeping these records. So I would like to add my own srv-record like _olkerberos._tcp so that I can use these srv-records for krb5.conf. I'm already doing this for sssd, because there I can configure the name of the srv-record. Can I do the same in krb5.conf? If yes what do I have to do? Thanks Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From jhutz at cmu.edu Wed Feb 26 13:46:09 2025 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Wed, 26 Feb 2025 13:46:09 -0500 Subject: define own SRV-record In-Reply-To: <4c320b53-995e-4d44-983e-361380bdc234@kania-online.de> References: <4c320b53-995e-4d44-983e-361380bdc234@kania-online.de> Message-ID: No; the names of these records are fixed by the standards. You can hand-configure the server names in krb5.conf instead of using DNS SRV records. However, even then, your Kerberos realm should not have the same name as a Windows domain -- that's essentially having two realms with the same name, which will not work out well. On Wed, Feb 26, 2025, 13:40 Stefan Kania wrote: > Hi to all, > > I'm having the following problem: > > I set up an openldap with kerberos, now I want to add the srv-records > for Kerberos, but as DNS-Server we MUST use a DNS-Server from Active > Directory. So I can't add a srv-record _kerberos._tcp, because the > domain controller of the AD are keeping these records. So I would like > to add my own srv-record like _olkerberos._tcp so that I can use these > srv-records for krb5.conf. I'm already doing this for sssd, because > there I can configure the name of the srv-record. Can I do the same in > krb5.conf? If yes what do I have to do? > > Thanks > > Stefan > > ________________________________________________ > Kerberos mailing list Kerberos at mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > From simo at redhat.com Wed Feb 26 14:11:20 2025 From: simo at redhat.com (Simo Sorce) Date: Wed, 26 Feb 2025 14:11:20 -0500 Subject: define own SRV-record In-Reply-To: <4c320b53-995e-4d44-983e-361380bdc234@kania-online.de> References: <4c320b53-995e-4d44-983e-361380bdc234@kania-online.de> Message-ID: <27e41f65d41278742d12c88a4ccb3cb96bcc6e05.camel@redhat.com> You are barking up the wrong tree because your request also means you intend to use the same kerberos realm for two distinct realms, and this will not work and end up in pain. Get your own subdomain (or a completely different second level domain), and then you will be able to create your own records there. On Wed, 2025-02-26 at 19:39 +0100, Stefan Kania wrote: > Hi to all, > > I'm having the following problem: > > I set up an openldap with kerberos, now I want to add the srv-records > for Kerberos, but as DNS-Server we MUST use a DNS-Server from Active > Directory. So I can't add a srv-record _kerberos._tcp, because the > domain controller of the AD are keeping these records. So I would like > to add my own srv-record like _olkerberos._tcp so that I can use these > srv-records for krb5.conf. I'm already doing this for sssd, because > there I can configure the name of the srv-record. Can I do the same in > krb5.conf? If yes what do I have to do? > > Thanks > > Stefan > -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc From kenh at cmf.nrl.navy.mil Thu Feb 27 17:59:28 2025 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Thu, 27 Feb 2025 17:59:28 -0500 Subject: Support for PKINIT on Windows now available in MIT Kerberos Message-ID: <202502272259.51RMxS3n027396@hedwig.cmf.nrl.navy.mil> (Since a few people have asked about this over the years, I felt it was worth an announcement). I am pleased to report that MIT Kerberos now supports PKINIT on the Windows platform. The technical details of this can be found in the pull request here: https://github.com/krb5/krb5/pull/1401 This means that with a PKCS#11 library and the appropriate client configuration one can use a smartcard to authenticate with MIT Kerberos. I have tested this support with a PIV card and both the OpenSC and ActivClient PKCS#11 libraries. Right now this support is only on the 'master' branch of MIT Kerberos and you will have to build MIT Kerberos from source to utilize it; the build directions are in the source tree under src/windows/README. Thanks to Greg Hudson working with me to push this across the finish line. --Ken