Cross realm kadmin

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

Cross realm kadmin

Kenneth MacDonald
We have two MIT krb5 realms: LIVE and TEST.

I would like to add principals from LIVE into TEST's kadm5.acl file so
they can manage the TEST realm's principals, authenticating from
keytabs.

>From what I can glean in the archives this isn't possible due to to
kadmin/admin@TEST being denied to TGS requests, which includes cross
realm trust links.

I tried removing the DISALLOW_TGT_BASED flag from kadmin/admin@TEST
with no effect.

The kadmin command on a host in the LIVE realm obtained a
kadmin/admin@LIVE ticket and presented that to the TEST kadmin server
which of course couldn't verify it.

If this behaviour is impossible, I will have to ensure all my
management hosts default to the same realm that they are managing.  Or
is there something I am missing?

Cheers,

Kenny.



--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

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

Re: Cross realm kadmin

Greg Hudson
On 3/25/19 7:28 AM, Kenneth MacDonald wrote:
> If this behaviour is impossible, I will have to ensure all my
> management hosts default to the same realm that they are managing.  Or
> is there something I am missing?

I don't think it can work with kadmin -k (authenticating from keytab),
because kadmin will try to use the keytab to directly get credentials
for the server realm with an AS request.  Since is no cross-realm for AS
requests, it winds up getting credentials for the client realm instead.

I was able to make cross-realm kadmin work in a test environment with
kadmin -c.  I ran kinit normally, then used kvno to explicitly get
tickets for kadmin/admin@TEST.  The kvno step is necessary because
kadmin -c expects the necessary credential to already be present in the
ccache; it won't make a TGS request for them.  Then I ran kadmin -c
/path/to/ccache -r TEST.  Of course I also had to remove the
DISALLOW_TGT_BASED flag from the kadmin/admin@TEST principal entry, as
you did in your tests.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Cross realm kadmin

Kenneth MacDonald
On Mon, 2019-03-25 at 12:16 -0400, Greg Hudson wrote:

> On 3/25/19 7:28 AM, Kenneth MacDonald wrote:
> > If this behaviour is impossible, I will have to ensure all my
> > management hosts default to the same realm that they are
> > managing.  Or
> > is there something I am missing?
>
> I don't think it can work with kadmin -k (authenticating from
> keytab),
> because kadmin will try to use the keytab to directly get credentials
> for the server realm with an AS request.  Since is no cross-realm for
> AS
> requests, it winds up getting credentials for the client realm
> instead.
>
> I was able to make cross-realm kadmin work in a test environment with
> kadmin -c.  I ran kinit normally, then used kvno to explicitly get
> tickets for kadmin/admin@TEST.  The kvno step is necessary because
> kadmin -c expects the necessary credential to already be present in
> the
> ccache; it won't make a TGS request for them.  Then I ran kadmin -c
> /path/to/ccache -r TEST.  Of course I also had to remove the
> DISALLOW_TGT_BASED flag from the kadmin/admin@TEST principal entry,
> as
> you did in your tests.

Thank you very much for this pointer - I will see if our automation can
be convinced to follow this route if we are willing to accept the lower
security on the TEST realm.

Cheers,

Kenny.



--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos