Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Creating a principal using the kadmin C API
53 views
Skip to first unread message
Lars Francke
Apr 7, 2022, 4:21:02 PM4/7/22
to kerb...@mit.edu
Hi everyone,
we're trying to create principals and keys using the kadmin C API.
The normal API has some documentation[1] but unfortunately the kadmin API
doesn't have any we could find.
We tried to use kadm5_create_principal_3 and kadm5_randkey_principal_3 but
we seem to be running into an issue. Ideally we'd like to call this
function with a handle (+ context) with an in-memory krb5.conf but that
does not seem to work so we create the files and refer to them in the
profile but kadmin still seems to load (is this related to the
"alt_profile"?) a file from a default location which means it'll use the
wrong connection details.
I am sorry for the vague description, it's been two weeks since we tried
and I only now get around to writing it down. I'm happy to provide more
details.
In general though my question is whether there's a good way (maybe even an
example and/or docs) to programatically create principals and keys using
the kadmin API without resorting to calling kadmin and parsing stdout etc.
Thank you very much for your help.
Cheers,
Lars
[1] <https://web.mit.edu/kerberos/krb5-1.19/doc/appdev/refs/api/index.html>
we're trying to create principals and keys using the kadmin C API.
The normal API has some documentation[1] but unfortunately the kadmin API
doesn't have any we could find.
We tried to use kadm5_create_principal_3 and kadm5_randkey_principal_3 but
we seem to be running into an issue. Ideally we'd like to call this
function with a handle (+ context) with an in-memory krb5.conf but that
does not seem to work so we create the files and refer to them in the
profile but kadmin still seems to load (is this related to the
"alt_profile"?) a file from a default location which means it'll use the
wrong connection details.
I am sorry for the vague description, it's been two weeks since we tried
and I only now get around to writing it down. I'm happy to provide more
details.
In general though my question is whether there's a good way (maybe even an
example and/or docs) to programatically create principals and keys using
the kadmin API without resorting to calling kadmin and parsing stdout etc.
Thank you very much for your help.
Cheers,
Lars
[1] <https://web.mit.edu/kerberos/krb5-1.19/doc/appdev/refs/api/index.html>
Chris Hecker
Apr 7, 2022, 9:40:48 PM4/7/22
to kerb...@mit.edu
I use the kadm5 api to create princs and change keys. I do this with a
memory keytab (well, I load a disk keytab while root, copy it to a
memory keytab, and then drop privs), but I assume it's using the default
system /etc/krb5.conf. I do have my krb5 client stuff build an
in-memory conf and I hacked an API in for using that because there
didn't used to be a way to do that, I think there is now, but I don't do
kadm5 stuff the same way.
I'm happy to post my code for making princs and randkeying if you'd
like.
Chris
>Kerberos mailing list Kerb...@mit.edu
>https://mailman.mit.edu/mailman/listinfo/kerberos
Greg Hudson
Apr 8, 2022, 12:35:44 AM4/8/22
to Lars Francke, kerb...@mit.edu
On 4/7/22 16:19, Lars Francke wrote:
> We tried to use kadm5_create_principal_3 and kadm5_randkey_principal_3 but
> we seem to be running into an issue. Ideally we'd like to call this
> function with a handle (+ context) with an in-memory krb5.conf but that
> does not seem to work so we create the files and refer to them in the
> profile but kadmin still seems to load (is this related to the
> "alt_profile"?) a file from a default location which means it'll use the
> wrong connection details.
krb5_init_context_profile() lets you supply a profile object. If this
> We tried to use kadm5_create_principal_3 and kadm5_randkey_principal_3 but
> we seem to be running into an issue. Ideally we'd like to call this
> function with a handle (+ context) with an in-memory krb5.conf but that
> does not seem to work so we create the files and refer to them in the
> profile but kadmin still seems to load (is this related to the
> "alt_profile"?) a file from a default location which means it'll use the
> wrong connection details.
is created with profile_init_path(), the application should be able to
strictly control which file is used.
It is possible to create an in-memory profile with
profile_init_vtable(). Perhaps it would be nicer if one could create an
empty in-memory profile object and populate it with
profile_add_relation(), but that is not currently implemented.
Lars Francke
Apr 8, 2022, 5:55:03 AM4/8/22
to Chris Hecker, kerb...@mit.edu
Thank you!
Yeah, our problem is that we want to create Keytabs for multiple different
KDCs automatically.
I would still be very much interested in your code, I assume we can still
learn something and then - together with Greg's answer - figure out what we
need to do.
On Fri, Apr 8, 2022 at 3:49 AM Chris Hecker <che...@d6.com> wrote:
>
> I use the kadm5 api to create princs and change keys. I do this with a
> memory keytab (well, I load a disk keytab while root, copy it to a
> memory keytab, and then drop privs), but I assume it's using the default
> system /etc/krb5.conf. I do have my krb5 client stuff build an
> in-memory conf and I hacked an API in for using that because there
> didn't used to be a way to do that, I think there is now, but I don't do
> kadm5 stuff the same way.
>
> I'm happy to post my code for making princs and randkeying if you'd
> like.
>
> Chris
>
>
>
> ------ Original Message ------
> From: "Lars Francke" <lars.f...@gmail.com>
> To: kerb...@mit.edu
> Sent: 2022-04-07 13:19:50
> Subject: Creating a principal using the kadmin C API
>
> >Hi everyone,
> >
> >we're trying to create principals and keys using the kadmin C API.
> >The normal API has some documentation[1] but unfortunately the kadmin API
> >doesn't have any we could find.
> >
Yeah, our problem is that we want to create Keytabs for multiple different
KDCs automatically.
I would still be very much interested in your code, I assume we can still
learn something and then - together with Greg's answer - figure out what we
need to do.
On Fri, Apr 8, 2022 at 3:49 AM Chris Hecker <che...@d6.com> wrote:
>
> I use the kadm5 api to create princs and change keys. I do this with a
> memory keytab (well, I load a disk keytab while root, copy it to a
> memory keytab, and then drop privs), but I assume it's using the default
> system /etc/krb5.conf. I do have my krb5 client stuff build an
> in-memory conf and I hacked an API in for using that because there
> didn't used to be a way to do that, I think there is now, but I don't do
> kadm5 stuff the same way.
>
> I'm happy to post my code for making princs and randkeying if you'd
> like.
>
> Chris
>
>
>
> ------ Original Message ------
> From: "Lars Francke" <lars.f...@gmail.com>
> To: kerb...@mit.edu
> Sent: 2022-04-07 13:19:50
> Subject: Creating a principal using the kadmin C API
>
> >Hi everyone,
> >
> >we're trying to create principals and keys using the kadmin C API.
> >The normal API has some documentation[1] but unfortunately the kadmin API
> >doesn't have any we could find.
> >
> >We tried to use kadm5_create_principal_3 and kadm5_randkey_principal_3 but
> >we seem to be running into an issue. Ideally we'd like to call this
> >function with a handle (+ context) with an in-memory krb5.conf but that
> >does not seem to work so we create the files and refer to them in the
> >profile but kadmin still seems to load (is this related to the
> >"alt_profile"?) a file from a default location which means it'll use the
> >wrong connection details.
> >
> >we seem to be running into an issue. Ideally we'd like to call this
> >function with a handle (+ context) with an in-memory krb5.conf but that
> >does not seem to work so we create the files and refer to them in the
> >profile but kadmin still seems to load (is this related to the
> >"alt_profile"?) a file from a default location which means it'll use the
> >wrong connection details.
> >
Lars Francke
Apr 8, 2022, 5:57:23 AM4/8/22
to Greg Hudson, kerb...@mit.edu
Thank you. We'll look into this again next week and will see if we can get
it running.
We must have taken a wrong turn somewhere.
Good to hear that it _should_ work!
On Fri, Apr 8, 2022 at 6:35 AM Greg Hudson <ghu...@mit.edu> wrote:
> On 4/7/22 16:19, Lars Francke wrote:
it running.
We must have taken a wrong turn somewhere.
Good to hear that it _should_ work!
On Fri, Apr 8, 2022 at 6:35 AM Greg Hudson <ghu...@mit.edu> wrote:
> On 4/7/22 16:19, Lars Francke wrote:
> > We tried to use kadm5_create_principal_3 and kadm5_randkey_principal_3
> but
> > we seem to be running into an issue. Ideally we'd like to call this
> > function with a handle (+ context) with an in-memory krb5.conf but that
> > does not seem to work so we create the files and refer to them in the
> > profile but kadmin still seems to load (is this related to the
> > "alt_profile"?) a file from a default location which means it'll use the
> > wrong connection details.
>
> but
> > we seem to be running into an issue. Ideally we'd like to call this
> > function with a handle (+ context) with an in-memory krb5.conf but that
> > does not seem to work so we create the files and refer to them in the
> > profile but kadmin still seems to load (is this related to the
> > "alt_profile"?) a file from a default location which means it'll use the
> > wrong connection details.
>
Chris Hecker
Apr 8, 2022, 1:54:55 PM4/8/22
to Greg Hudson, Lars Francke, kerb...@mit.edu
> Perhaps it would be nicer if one could create an empty in-memory profile
object and populate it with profile_add_relation(), but that is not
currently implemented.
I think I did it this way when I hacked my API in back in days of yore and
object and populate it with profile_add_relation(), but that is not
currently implemented.
it was nice and clean. I’ll look when I’m at my computer.
Chris
On Thu, Apr 7, 2022 at 22:42 Greg Hudson <ghu...@mit.edu> wrote:
> On 4/7/22 16:19, Lars Francke wrote:
> > We tried to use kadm5_create_principal_3 and kadm5_randkey_principal_3
> but
> > we seem to be running into an issue. Ideally we'd like to call this
> > function with a handle (+ context) with an in-memory krb5.conf but that
> > does not seem to work so we create the files and refer to them in the
> > profile but kadmin still seems to load (is this related to the
> > "alt_profile"?) a file from a default location which means it'll use the
> > wrong connection details.
>
> krb5_init_context_profile() lets you supply a profile object. If this
> is created with profile_init_path(), the application should be able to
> strictly control which file is used.
>
> It is possible to create an in-memory profile with
> profile_init_vtable(). Perhaps it would be nicer if one could create an
> empty in-memory profile object and populate it with
> profile_add_relation(), but that is not currently implemented.
Teo Klestrup Röijezon
Apr 11, 2022, 11:10:09 AM4/11/22
to Greg Hudson, kerb...@mit.edu
Hey, I'm a coworker of Lars' and working on this project.
On Friday, 8 April 2022 06.35.29 CEST Greg Hudson wrote:
> krb5_init_context_profile() lets you supply a profile object. If this
> is created with profile_init_path(), the application should be able to
> strictly control which file is used.
>
> It is possible to create an in-memory profile with
> profile_init_vtable(). Perhaps it would be nicer if one could create an
> empty in-memory profile object and populate it with
> profile_add_relation(), but that is not currently implemented.
profile_init_vtable() (or building it with profile_add_relation()) would be
ideal, yes. Our current prototype uses krb5_init_context_profile() for the sake
of simplicity (vtables are annoying to build up and maintain across the Rust-C
border, so I didn't want to go there until we could confirm that the rest
works).
However, the kadm5_init_*() family of functions (via init_any()) calls
kadm5_get_config_params(), which in turn always loads its own profile by calling
krb5_aprof_init() with a hard-coded choice of either DEFAULT_PROFILE_PATH or
DEFAULT_KDC_PROFILE. This _is_ possible to override with environment
variables, but that's a pretty big ask when linking to the library in-process.
On Friday, 8 April 2022 06.35.29 CEST Greg Hudson wrote:
> krb5_init_context_profile() lets you supply a profile object. If this
> is created with profile_init_path(), the application should be able to
> strictly control which file is used.
>
> It is possible to create an in-memory profile with
> profile_init_vtable(). Perhaps it would be nicer if one could create an
> empty in-memory profile object and populate it with
> profile_add_relation(), but that is not currently implemented.
ideal, yes. Our current prototype uses krb5_init_context_profile() for the sake
of simplicity (vtables are annoying to build up and maintain across the Rust-C
border, so I didn't want to go there until we could confirm that the rest
works).
However, the kadm5_init_*() family of functions (via init_any()) calls
kadm5_get_config_params(), which in turn always loads its own profile by calling
krb5_aprof_init() with a hard-coded choice of either DEFAULT_PROFILE_PATH or
DEFAULT_KDC_PROFILE. This _is_ possible to override with environment
variables, but that's a pretty big ask when linking to the library in-process.
Greg Hudson
May 7, 2022, 2:25:13 AM5/7/22
to Teo Klestrup Röijezon, kerb...@mit.edu
Many apologies; this got filed into my spam folder and I only just found it.
On 4/11/22 11:09, Teo Klestrup Röijezon wrote:
> profile_init_vtable() (or building it with profile_add_relation()) would be
> ideal, yes.
[...]
should use the profile object from the context argument. I have a
candidate patch that passes tests.
Unfortunately I don't think there's a viable workaround beyond the
options you have already considered.
On 4/11/22 11:09, Teo Klestrup Röijezon wrote:
> profile_init_vtable() (or building it with profile_add_relation()) would be
> ideal, yes.
> However, the kadm5_init_*() family of functions (via init_any()) calls
> kadm5_get_config_params(), which in turn always loads its own profile by calling
> krb5_aprof_init() with a hard-coded choice of either DEFAULT_PROFILE_PATH or
> DEFAULT_KDC_PROFILE. This _is_ possible to override with environment
> variables, but that's a pretty big ask when linking to the library in-process.
I think this is a bug; the init functions and kadm5_get_config_params()
> kadm5_get_config_params(), which in turn always loads its own profile by calling
> krb5_aprof_init() with a hard-coded choice of either DEFAULT_PROFILE_PATH or
> DEFAULT_KDC_PROFILE. This _is_ possible to override with environment
> variables, but that's a pretty big ask when linking to the library in-process.
should use the profile object from the context argument. I have a
candidate patch that passes tests.
Unfortunately I don't think there's a viable workaround beyond the
options you have already considered.
Teo Klestrup Röijezon
May 9, 2022, 10:10:15 AM5/9/22
to Greg Hudson, kerb...@mit.edu
On Saturday, May 7, 2022 8:24:58 AM CEST Greg Hudson wrote:
> I think this is a bug; the init functions and kadm5_get_config_params()
> should use the profile object from the context argument. I have a
> candidate patch that passes tests.
I think that would be great from our perspective, with the only caveat being
> I think this is a bug; the init functions and kadm5_get_config_params()
> should use the profile object from the context argument. I have a
> candidate patch that passes tests.
that this might break users who rely on the current behaviour for whatever
reason. But I guess that's kind of a https://xkcd.com/1172/ situation...
> Unfortunately I don't think there's a viable workaround beyond the
> options you have already considered.
fork I'm not massively worried about backporting to older versions. Especially
since this is purely a client issue.
Greg Hudson
Jun 9, 2022, 4:43:19 PM6/9/22
to Teo Klestrup Röijezon, kerb...@mit.edu
On 5/9/22 10:09, Teo Klestrup Röijezon wrote:
> On Saturday, May 7, 2022 8:24:58 AM CEST Greg Hudson wrote:
>> I think this is a bug; the init functions and kadm5_get_config_params()
>> should use the profile object from the context argument. I have a
>> candidate patch that passes tests.
[...]
> On Saturday, May 7, 2022 8:24:58 AM CEST Greg Hudson wrote:
>> I think this is a bug; the init functions and kadm5_get_config_params()
>> should use the profile object from the context argument. I have a
>> candidate patch that passes tests.
> As long as we can get it working with either a new release or a temporary soft
> fork I'm not massively worried about backporting to older versions. Especially
> since this is purely a client issue.
I made this change on the mainline, though it didn't make it into the
> fork I'm not massively worried about backporting to older versions. Especially
> since this is purely a client issue.
1.20 release.
https://github.com/krb5/krb5/commit/49a857808b918440793daa81c8fe352326623fef
0 new messages