[19782] in Kerberos_V5_Development
Re: Multiple KDC's realm heuristic for KRB5CCNAME=DIR:/tmp/mydir/
daemon@ATHENA.MIT.EDU (Martin Gee)
Tue Jul 24 15:30:45 2018
Date: Tue, 24 Jul 2018 19:26:30 +0000 (UTC)
From: Martin Gee <geemang_2000@yahoo.com>
To: Greg Hudson <ghudson@mit.edu>, "krbdev@mit.edu" <krbdev@mit.edu>
Message-ID: <1711573979.1735063.1532460390651@mail.yahoo.com>
In-Reply-To: <32508cd8-6736-97b4-b16a-7ac933d6f560@mit.edu>
MIME-Version: 1.0
Reply-To: Martin Gee <geemang_2000@yahoo.com>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Thanks Greg, truly appreciate the detailed response.
My main requirement is to offer delegation to one or more AD KDC's based upon the AD UPN.
This testcase works:NOTE: I've merged the 2 keytabs into krb5.keytab
$ export KRB5CCNAME=/tmp/krb5cc_v_icsynergy_net$ kinit -k -t ./krb5.keytab host/gw.icsynergy.info@ICSYNERGY.NET$ export KRB5CCNAME=/tmp/krb5cc_v_uicsynergy_biz$ kinit -k -t ./krb5.keytab host/gw.icsynergy.info@UICSYNERGY.BIZ$klistWill show last kinit result/opt/spgateway/bin/t_s4u u:tuser1@ICSYNERGY.NET h:HTTP@ics-dc-1.icsynergy.net ./krb5.keytab/opt/spgateway/bin/t_s4u u:tuser2@UICSYNERGY.BIZ h:HTTP@ics-dc-2.uicsynergy.biz ./krb5.keytab
I've created my own library (copying most of what t_s4u does), hence using t_s4u as my testcase. Would managing KRB5CCNAME dynamically via setenv system call be a better strategy? Seems like I basically, need to map the REALM to the appropriate ccache file in a way the gss calles would still work.
Cheers,
Martin
On Tuesday, July 24, 2018 1:47 PM, Greg Hudson <ghudson@mit.edu> wrote:
On 07/24/2018 01:56 PM, Martin Gee wrote:
> Added: krbdev@mit.edu
Please pick one list or the other. I've left the message to
kerberos@mit.edu in the moderation queue and omitted it from the to line
here.
> 2. If the realm of the target service is known via a [domain_realm]
> mapping in krb5.conf, a client principal in that realm will be selected.
> Do the mechanisms you list work for constrained delegation?
They do not.
Constrained delegation (S4U2Proxy) requires an evidence ticket. MIT's
library supports two ways of getting an evidence ticket: either by using
protocol transition (S4U2Self) via a call to
gss_acquire_cred_impersonate_name(), or by receiving the evidence ticket
from a Kerberos-using client via gss_accept_sec_context().
In the first case (which is what t_s4u does),
gss_acquire_cred_impersonate_name() has no idea what the constrained
delegation target server will be, so it has to resolve the
impersonator_cred_handle with no target name, which means picking the
primary cache. The TGT from that same cache will be used for the
constrained delegation step.
In the second case, gss_accept_sec_context() constructs an evidence cred
containing the TGT from the verifier cred handle and the ticket
presented by the client. Again, gss_accept_sec_context() has no idea
what the constrained delegation target server will be, so it picks the
TGT from the primary cache. This could possibly be improved by looking
for a TGT which matches the server key the client authenticated to, but
that is not implemented.
To make S4U2Self+S4U2Proxy work with credential cache selection, I think
we would need a way to do it in one step. I can't think of an easy way
to express that with current GSS function signatures.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
