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> >________________________________________________
Kerberos mailing list Kerberos@mit.edu >https://mailman.mit.edu/mailman/listinfo/kerberos
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.
On 4/7/22 16:19, Lars Francke wrote:
We tried to use kadm5_create_principal_3 and kadm5_randkey_principal_3but
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.
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.francke@gmail.com>
To: kerberos@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.
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> >________________________________________________
Kerberos mailing list Kerberos@mit.edu >https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________
Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Perhaps it would be nicer if one could create an empty in-memory profileobject and populate it with profile_add_relation(), but that is not
On 4/7/22 16:19, Lars Francke wrote:
We tried to use kadm5_create_principal_3 and kadm5_randkey_principal_3but
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. ________________________________________________
Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
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.[...]
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() 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 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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 76:38:28 |
| Calls: | 6,657 |
| Calls today: | 3 |
| Files: | 12,203 |
| Messages: | 5,332,734 |
| Posted today: | 1 |