[38505] in Kerberos
Re: kadm5 API questions
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Mar 21 11:20:41 2019
To: Rick van Rein <rick@openfortress.nl>,
"kerberos@mit.edu" <kerberos@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <5f5ab412-9d06-3278-26ea-c8bf81b47e23@mit.edu>
Date: Thu, 21 Mar 2019 11:20:21 -0400
MIME-Version: 1.0
In-Reply-To: <5C934386.8070006@openfortress.nl>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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 Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
