kadm5 API questions

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

kadm5 API questions

Rick van Rein (OpenFortress)
Hello,

I am programming to the kadm5 API, and a few things are not clear to me.
 Can anyone help?

1.
There is some mention in the code about old and new GSS-API
authentication (kadmin options -O and -N to force).  What is the
difference, and is the new style still based on GSS-API?

2.
IIRC, a property of GSS-API is that it will automatically
re-authenticate when a credential has expired.  Does this apply to the
old and new GSS-API mechanisms too?

3.
Even if I have a krb5_context already, I seem to need a separate one for
kadm5 use.  Is this because the plain context is about local management,
and the kadm5 is more like a client-to-a-service context, possibly using
its own identity, addressing another realm, that sort of thing?

4.
Is it true that kadmind can only serve one realm?  That would be
different from the KDC, and a bit of a surprise.  It increases the
burden of adding a new realm, especially when this is automated.

5.
My KXOVER daemon identifies as kxover/public.  Do I need to have that
name in every realm it manages, or is it sufficient to have an ACL
setting permitting an identity from another realm adding and removing
principals through kadm5?  [inconsistent test results]


FWIW, the software I am working on is for automated realm crossover, and
(the module for MIT krb5) develops at
https://github.com/arpa2/kxover/blob/tls-based-attempt/src/mitkrb5.c

It is mostly a wrapper around the KDC, adding TCP/TLS and running a
DANE/X.509-protected key exchange over the connection.  Inside the KDC,
all that is required is a dynamic facility for host2realm mapping (like
a DNSSEC-protected lookup).


Thanks,
 -Rick
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kadm5 API questions

Greg Hudson
On 3/21/19 3:55 AM, Rick van Rein wrote:
> There is some mention in the code about old and new GSS-API
> authentication (kadmin options -O and -N to force).  What is the
> difference, and is the new style still based on GSS-API?

They are both based on GSS-API.  I'd have to review the code to detail
the differences.  You'd only want to use old-style authentication when
talking to a very old server, and even then it should fall back without
explicit prompting.

> IIRC, a property of GSS-API is that it will automatically
> re-authenticate when a credential has expired.  Does this apply to the
> old and new GSS-API mechanisms too?

That is not a property of GSS-API, and it can't be.  The message
exchanges needed for re-authentication wouldn't fit into the application
protocol, since the application is just passing gss_wrap() tokens from
one side to the other.

> Even if I have a krb5_context already, I seem to need a separate one for
> kadm5 use.  Is this because the plain context is about local management,
> and the kadm5 is more like a client-to-a-service context, possibly using
> its own identity, addressing another realm, that sort of thing?

The context initialized with kadm5_init_krb5_context() can be used for
other purposes as well, so you don't need a separate context.

kadm5_init_krb5_context() just calls krb5_init_context() when you link
with the libkadm5clnt.  When you link with libkadm5srv, it initializes a
context that reads kdc.conf as well as krb5.conf.

> Is it true that kadmind can only serve one realm?  That would be
> different from the KDC, and a bit of a surprise.  It increases the
> burden of adding a new realm, especially when this is automated.

Yes.  I would consider a patch for multi-realm support.

> My KXOVER daemon identifies as kxover/public.  Do I need to have that
> name in every realm it manages, or is it sufficient to have an ACL
> setting permitting an identity from another realm adding and removing
> principals through kadm5?  [inconsistent test results]

The kadm5 protocol ordinarily requires initial tickets.  Since
cross-realm tickets can only be obtained through a TGS request, there
are some obstacles to using kadmin across realms.

>From memory and a brief look at the code, it might be possible to use
cross-realm tickets if:

* You use kadm5_init_with_creds() or kadm5_init_with_skey(), not
kadm5_init_with_password().

* You remove the DISALLOW_TGT_BASED flag on the kadmin/admin and
kadmin/<hostname> principal entries.

* You don't perform self-service key change operations (principals
changing their own passwords or keys).
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos