Multiple KDC's realm heuristic for KRB5CCNAME=DIR:/tmp/mydir/ ccache not working

Discussion:

Martin Gee

2018-07-24 17:56:19 UTC

Added: ***@mit.edu

On Tuesday, July 24, 2018 12:52 PM, Martin Gee <***@yahoo.com> wrote:

I found a google post that describes the rules to resolve ccache entries
1. The .k5identity file allows you to configure a client principal based on the target principal. See:
http://web.mit.edu/kerberos/ krb5-latest/doc/user/user_ config/k5identity.html

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.

3. The primary cache.
*******************
Do the mechanisms you list work for constrained delegation?krb5 version: 1.16.1
I'm testing with t_s4u using the same approach above ( KRB5CCNAME=DIR:/tmp/mydir) etc.
My tests always use #3 (last kinit command run or kswitch). I'd really like to use #2 if possible. I can't seem to get the .k5identity or realm of target service to rules to kick in. As listed belowt_s4u is always using the cache of the last kinit run.
/etc/krb5.conf#START krb5.conf[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
[libdefaults] default_realm = UICSYNERGY.BIZ dns_lookup_realm = true dns_lookup_kdc = true dns_canonicalize_hostname = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true default_client_keytab_name = /etc/krb5.keytab
[realms] UICSYNERGY.BIZ = { kdc = uicsynergy.biz default_domain = uicsynergy.biz } ICSYNERGY.NET = { kdc = icsynergy.net default_domain = icsynergy.net }
[domain_realm] .uicsynergy.biz = UICSYNERGY.BIZ uicsynergy.biz = UICSYNERGY.BIZ .icsynergy.net = ICSYNERGY.NET icsynergy.net = ICSYNERGY.NET#END krb5.conf
Here are my steps:Create a keytab on each AD DC.
[25007] 1532451100.523203: Getting credentials ***@ICSYNERGY.NET -> host/***@UICSYNERGY.BIZ using ccache DIR::/tmp/mydir/tktCzQyfj[25007] 1532451100.523204: Retrieving ***@ICSYNERGY.NET -> host/***@UICSYNERGY.BIZ from DIR::/tmp/mydir/tktCzQyfj with result: -1765328243/Matching credential not found (filename: /tmp/mydir/tktCzQyfj)[25007] 1532451100.523205: Getting credentials host/***@UICSYNERGY.BIZ -> krbtgt/***@UICSYNERGY.BIZ using ccache DIR::/tmp/mydir/tktCzQyfj[25007] 1532451100.523206: Retrieving host/***@UICSYNERGY.BIZ -> krbtgt/***@UICSYNERGY.BIZ from DIR::/tmp/mydir/tktCzQyfj with result: -1765328243/Matching credential not found (filename: /tmp/mydir/tktCzQyfj)[25007] 1532451100.523207: Retrieving host/***@UICSYNERGY.BIZ -> krbtgt/***@UICSYNERGY.BIZ from DIR::/tmp/mydir/tktCzQyfj with result: 0/Success[25007] 1532451100.523208: Starting with TGT for client realm: host/***@UICSYNERGY.BIZ -> krbtgt/***@UICSYNERGY.BIZ[25007] 1532451100.523209: Requesting tickets for krbtgt/***@UICSYNERGY.BIZ, referrals on[25007] 1532451100.523210: Generated subkey for TGS request: aes256-cts/B5F0[25007] 1532451100.523211: etypes requested in TGS request: aes256-cts, aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts[25007] 1532451100.523213: Encoding request body and padata into FAST request[25007] 1532451100.523214: Sending request (1769 bytes) to UICSYNERGY.BIZ[25007] 1532451100.523215: Resolving hostname uicsynergy.biz[25007] 1532451100.523216: Initiating TCP connection to stream 192.168.0.180:88[25007] 1532451100.523217: Sending TCP request to stream 192.168.0.180:88[25007] 1532451100.523218: Received answer (99 bytes) from stream 192.168.0.180:88[25007] 1532451100.523219: Terminating TCP connection to stream 192.168.0.180:88[25007] 1532451100.523220: Sending DNS URI query for _kerberos.UICSYNERGY.BIZ.[25007] 1532451100.523221: No URI records found[25007] 1532451100.523222: Sending DNS SRV query for _kerberos-master._udp.UICSYNERGY.BIZ.[25007] 1532451100.523223: Sending DNS SRV query for _kerberos-master._tcp.UICSYNERGY.BIZ.[25007] 1532451100.523224: No SRV records found[25007] 1532451100.523225: Response was not from master KDC[25007] 1532451100.523226: TGS request result: -1765328377/Server not found in Kerberos database[25007] 1532451100.523227: Requesting tickets for krbtgt/***@UICSYNERGY.BIZ, referrals off[25007] 1532451100.523228: Generated subkey for TGS request: aes256-cts/30A5[25007] 1532451100.523229: etypes requested in TGS request: aes256-cts, aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts[25007] 1532451100.523231: Encoding request body and padata into FAST request[25007] 1532451100.523232: Sending request (1769 bytes) to UICSYNERGY.BIZ[25007] 1532451100.523233: Resolving hostname uicsynergy.biz[25007] 1532451100.523234: Initiating TCP connection to stream 192.168.0.180:88[25007] 1532451100.523235: Sending TCP request to stream 192.168.0.180:88[25007] 1532451100.523236: Received answer (99 bytes) from stream 192.168.0.180:88[25007] 1532451100.523237: Terminating TCP connection to stream 192.168.0.180:88[25007] 1532451100.523238: Sending DNS URI query for _kerberos.UICSYNERGY.BIZ.[25007] 1532451100.523239: No URI records found[25007] 1532451100.523240: Sending DNS SRV query for _kerberos-master._udp.UICSYNERGY.BIZ.[25007] 1532451100.523241: Sending DNS SRV query for _kerberos-master._tcp.UICSYNERGY.BIZ.[25007] 1532451100.523242: No SRV records found[25007] 1532451100.523243: Response was not from master KDC[25007] 1532451100.523244: TGS request result: -1765328377/Server not found in Kerberos databasegss_acquire_cred_impersonate_name: Unspecified GSS failure. Minor code may provide more informationgss_acquire_cred_impersonate_name: Server not found in Kerberos database
<< FAILS

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/l

Greg Hudson

2018-07-24 18:47:38 UTC

Permalink

Please pick one list or the other. I've left the message to
***@mit.edu in the moderation queue and omitted it from the to line
here.

Post by Martin Gee
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 ***@mit.edu
https://mailman.mit.edu/

Martin Gee

2018-07-24 19:26:30 UTC

Permalink

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/***@ICSYNERGY.NET$ export KRB5CCNAME=/tmp/krb5cc_v_uicsynergy_biz$ kinit -k -t ./krb5.keytab host/***@UICSYNERGY.BIZ$klistWill show last kinit result/opt/spgateway/bin/t_s4u u:***@ICSYNERGY.NET h:***@ics-dc-1.icsynergy.net ./krb5.keytab/opt/spgateway/bin/t_s4u u:***@UICSYNERGY.BIZ h:***@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
Please pick one list or the other. I've left the message to
***@mit.edu in the moderation queue and omitted it from the to line
here.

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 ***@mit.edu
https://mailman.mit.edu/mai

Martin Gee

2018-07-25 10:57:54 UTC

Permalink

Note: merging the keytabs does not work.
Should be:export KRB5CCNAME=/tmp/krb5cc_v_icsynergy_net$ kinit -k -t ./krb5_net.keytab host/***@ICSYNERGY.NET$ export KRB5CCNAME=/tmp/krb5cc_v_uicsynergy_biz$ kinit -k -t ./krb5_biz.keytab host/***@UICSYNERGY.BIZ
export KRB5CCNAME=/tmp/krb5cc_v_icsynergy_net
/opt/spgateway/bin/t_s4u u:***@ICSYNERGY.NET h:***@ics-dc-1.icsynergy.net ./krb5_net.keytab$ export KRB5CCNAME=/tmp/krb5cc_v_uicsynergy_biz
/opt/spgateway/bin/t_s4u u:***@UICSYNERGY.BIZ h:***@ics-dc-2.uicsynergy.biz ./krb5_biz.keytab

On Tuesday, July 24, 2018 2:26 PM, Martin Gee <***@yahoo.com> wrote:

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/***@ICSYNERGY.NET$ export KRB5CCNAME=/tmp/krb5cc_v_uicsynergy_biz$ kinit -k -t ./krb5.keytab host/***@UICSYNERGY.BIZ$klistWill show last kinit result/opt/spgateway/bin/t_s4u u:***@ICSYNERGY.NET h:***@ics-dc-1.icsynergy.net ./krb5.keytab/opt/spgateway/bin/t_s4u u:***@UICSYNERGY.BIZ h:***@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
Please pick one list or the other. I've left the message to
***@mit.edu in the moderation queue and omitted it from the to line
here.

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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/kr

Greg Hudson

2018-07-25 14:07:47 UTC

Permalink

On 07/24/2018 03:26 PM, Martin Gee wrote:> Would managing KRB5CCNAME
dynamically via setenv system call be a better

Post by Martin Gee
strategy? Seems like I basically, need to map the REALM to the
appropriate ccache file in a way the gss calles would still work.

That seems like it should work. You could alternatively use
gss_acquire_cred_from() to specify the ccache location. See
t_credstore.c (in the same place as t_s4u.c) for an example, and use the
key "ccache".
_______________________________________________
krbdev mailing list ***@mit.edu
https

Martin Gee

2018-07-25 19:04:01 UTC

Permalink

In order to support my requirements, I need to call gss_acquire_cred or gss_acquire_cred_from with a unique keytab (not /etc/krb5.keytab), one for each KDC. I'd like to use the automatic ccache creation that gss_acquire_cred_* does. gss_acquire_cred is failing with a custom keytab location/name.
http://web.mit.edu/~kerberos/krb5-latest/doc/appdev/gssapi.html
"If the krb5 mechanism acquires initial tickets using the default client keytab, the resulting tickets will be stored in the default cache or collection, and will be refreshed by future calls togss_acquire_cred as they approach their expire time."
Seems gss_acquire_cred only works when /etc/krb5.keytab is present.

I've tried these:export KRB5_KTNAME=/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytabsetenv("KRB5_KTNAME", "/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab", 1)
krb5_gss_register_acceptor_identity("/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab");

Results in:[8053] 1532545049.921505: Retrieving host/***@ICSYNERGY.NET from FILE:/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab (vno 0, enctype 0) with result: 0/Success[8053] 1532545049.921506: Retrieving host/***@ICSYNERGY.NET from FILE:/etc/krb5.keytab (vno 0, enctype 0) with result: 2/Key table file '/etc/krb5.keytab' not foundgss_acquire_cred:851968 - Unspecified GSS failure. Minor code may provide more informationgss_acquire_cred:0 - Unknown error
Where as:$ sudo cp spgateway_icsynergy_net.keytab /etc/krb5.keytab
Results in:[15550] 1532545264.591459: Retrieving host/***@ICSYNERGY.NET from FILE:/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab (vno 0, enctype 0) with result: 0/Success[15550] 1532545264.591460: Retrieving host/***@ICSYNERGY.NET from FILE:/etc/krb5.keytab (vno 0, enctype 0) with result: 0/Success[15550] 1532545264.591461: Getting initial credentials for host/***@ICSYNERGY.NET[15550] 1532545264.591462: Looked up etypes in keytab: des-cbc-crc, des, des-cbc-crc, rc4-hmac, aes256-cts, aes128-cts[15550] 1532545264.591464: Sending unauthenticated request[15550] 1532545264.591465: Sending request (212 bytes) to ICSYNERGY.NET[15550] 1532545264.591466: Resolving hostname icsynergy.net[15550] 1532545264.591467: Sending initial UDP request to dgram 192.168.0.175:88[15550] 1532545264.591468: Received answer (204 bytes) from dgram 192.168.0.175:88[15550] 1532545264.591469: Sending DNS URI query for _kerberos.ICSYNERGY.NET.[15550] 1532545264.591470: No URI records found[15550] 1532545264.591471: Sending DNS SRV query for _kerberos-master._udp.ICSYNERGY.NET.[15550] 1532545264.591472: Sending DNS SRV query for _kerberos-master._tcp.ICSYNERGY.NET.[15550] 1532545264.591473: No SRV records found[15550] 1532545264.591474: Response was not from master KDC[15550] 1532545264.591475: Received error from KDC: -1765328359/Additional pre-authentication required[15550] 1532545264.591478: Preauthenticating using KDC method data[15550] 1532545264.591479: Processing preauth types: 16, 15, 19, 2[15550] 1532545264.591480: Selected etype info: etype aes256-cts, salt "ICSYNERGY.NEThostgw.icsynergy.info", params ""[15550] 1532545264.591481: Retrieving host/***@ICSYNERGY.NET from FILE:/etc/krb5.keytab (vno 0, enctype aes256-cts) with result: 0/Success[15550] 1532545264.591482: AS key obtained for encrypted timestamp: aes256-cts/7DFF[15550] 1532545264.591484: Encrypted timestamp (for 1532545264.807742): plain 301AA011180F32303138303732353139303130345AA10502030C533E, encrypted D61656A4F25F462A6FA7A0A1E278ACD80B7EAB042A3104F75EFDBE4C714EA4DA724B084B5DB684330DBD87C6E75B725E73D9DB8B47D553DC[15550] 1532545264.591485: Preauth module encrypted_timestamp (2) (real) returned: 0/Success[15550] 1532545264.591486: Produced preauth for next request: 2[15550] 1532545264.591487: Sending request (292 bytes) to ICSYNERGY.NET[15550] 1532545264.591488: Resolving hostname icsynergy.net[15550] 1532545264.591489: Sending initial UDP request to dgram 192.168.0.175:88[15550] 1532545264.591490: Received answer (98 bytes) from dgram 192.168.0.175:88[15550] 1532545264.591491: Sending DNS URI query for _kerberos.ICSYNERGY.NET.[15550] 1532545264.591492: No URI records found[15550] 1532545264.591493: Sending DNS SRV query for _kerberos-master._udp.ICSYNERGY.NET.[15550] 1532545264.591494: Sending DNS SRV query for _kerberos-master._tcp.ICSYNERGY.NET.[15550] 1532545264.591495: No SRV records found[15550] 1532545264.591496: Response was not from master KDC[15550] 1532545264.591497: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP[15550] 1532545264.591498: Request or response is too big for UDP; retrying with TCP[15550] 1532545264.591499: Sending request (292 bytes) to ICSYNERGY.NET (tcp only)[15550] 1532545264.591500: Resolving hostname icsynergy.net[15550] 1532545264.591501: Initiating TCP connection to stream 192.168.0.175:88[15550] 1532545264.591502: Sending TCP request to stream 192.168.0.175:88[15550] 1532545264.591503: Received answer (1564 bytes) from stream 192.168.0.175:88[15550] 1532545264.591504: Terminating TCP connection to stream 192.168.0.175:88[15550] 1532545264.591505: Sending DNS URI query for _kerberos.ICSYNERGY.NET.[15550] 1532545264.591506: No URI records found[15550] 1532545264.591507: Sending DNS SRV query for _kerberos-master._tcp.ICSYNERGY.NET.[15550] 1532545264.591508: No SRV records found[15550] 1532545264.591509: Response was not from master KDC[15550] 1532545264.591510: Processing preauth types: 19[15550] 1532545264.591511: Selected etype info: etype aes256-cts, salt "ICSYNERGY.NEThostgw.icsynergy.info", params ""[15550] 1532545264.591512: Produced preauth for next request: (empty)[15550] 1532545264.591513: AS key determined by preauth: aes256-cts/7DFF[15550] 1532545264.591514: Decrypted AS reply; session key is: aes256-cts/7FBD[15550] 1532545264.591515: FAST negotiation: unavailable[15550] 1532545264.591516: Initializing FILE:/tmp/krb5cc_1000 with default princ host/***@ICSYNERGY.NET[15550] 1532545264.591517: Storing host/***@ICSYNERGY.NET -> krbtgt/***@ICSYNERGY.NET in FILE:/tmp/krb5cc_1000[15550] 1532545264.591518: Storing config in FILE:/tmp/krb5cc_1000 for krbtgt/***@ICSYNERGY.NET: pa_type: 2[15550] 1532545264.591519: Storing host/***@ICSYNERGY.NET -> krb5_ccache_conf_data/pa_type/krbtgt\/ICSYNERGY.NET\@***@X-CACHECONF: in FILE:/tmp/krb5cc_1000[15550] 1532545264.591520: Storing config in FILE:/tmp/krb5cc_1000 for : refresh_time: 1532563265[15550] 1532545264.591521: Storing host/***@ICSYNERGY.NET -> krb5_ccache_conf_data/***@X-CACHECONF: in FILE:/tmp/krb5cc_1000[15550] 1532545264.591525: Getting credentials ***@ICSYNERGY.NET -> host/***@ICSYNERGY.NET using ccache FILE:/tmp/krb5cc_1000[15550] 1532545264.591526: Retrieving ***@ICSYNERGY.NET -> host/***@ICSYNERGY.NET from FILE:/tmp/krb5cc_1000 with result: -1765328243/Matching credential not found (filename: /tmp/krb5cc_1000)[15550] 1532545264.591527: Getting credentials host/***@ICSYNERGY.NET -> krbtgt/***@ICSYNERGY.NET using ccache FILE:/tmp/krb5cc_1000[15550] 1532545264.591528: Retrieving host/***@ICSYNERGY.NET -> krbtgt/***@ICSYNERGY.NET from FILE:/tmp/krb5cc_1000 with result: 0/Success[15550] 1532545264.591529: Get cred via TGT krbtgt/***@ICSYNERGY.NET after requesting host/***@ICSYNERGY.NET (canonicalize on)[15550] 1532545264.591530: Generated subkey for TGS request: aes256-cts/B474[15550] 1532545264.591531: etypes requested in TGS request: aes256-cts, aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts[15550] 1532545264.591533: Encoding request body and padata into FAST request[15550] 1532545264.591534: Sending request (2155 bytes) to ICSYNERGY.NET[15550] 1532545264.591535: Resolving hostname icsynergy.net[15550] 1532545264.591536: Initiating TCP connection to stream 192.168.0.175:88[15550] 1532545264.591537: Sending TCP request to stream 192.168.0.175:88[15550] 1532545264.591538: Received answer (1470 bytes) from stream 192.168.0.175:88[15550] 1532545264.591539: Terminating TCP connection to stream 192.168.0.175:88[15550] 1532545264.591540: Sending DNS URI query for _kerberos.ICSYNERGY.NET.[15550] 1532545264.591541: No URI records found[15550] 1532545264.591542: Sending DNS SRV query for _kerberos-master._udp.ICSYNERGY.NET.[15550] 1532545264.591543: Sending DNS SRV query for _kerberos-master._tcp.ICSYNERGY.NET.[15550] 1532545264.591544: No SRV records found[15550] 1532545264.591545: Response was not from master KDC[15550] 1532545264.591546: Decoding FAST response[15550] 1532545264.591547: TGS reply is for ***@ICSYNERGY.NET -> host/***@ICSYNERGY.NET with session key rc4-hmac/D92A[15550] 1532545264.591548: Got cred; 0/Success[15550] 1532545264.591549: Resolving unique ccache of type MEMORY[15550] 1532545264.591550: Initializing MEMORY:aelDQjj with default princ ***@ICSYNERGY.NET[15550] 1532545264.591551: Storing host/***@ICSYNERGY.NET -> krbtgt/***@ICSYNERGY.NET in MEMORY:aelDQjj[15550] 1532545264.591552: Storing host/***@ICSYNERGY.NET -> krb5_ccache_conf_data/pa_type/krbtgt\/ICSYNERGY.NET\@***@X-CACHECONF: in MEMORY:aelDQjj[15550] 1532545264.591553: Storing host/***@ICSYNERGY.NET -> krb5_ccache_conf_data/***@X-CACHECONF: in MEMORY:aelDQjj[15550] 1532545264.591554: Storing config in MEMORY:aelDQjj for : proxy_impersonator: host/***@ICSYNERGY.NET[15550] 1532545264.591555: Storing ***@ICSYNERGY.NET -> krb5_ccache_conf_data/***@X-CACHECONF: in MEMORY:aelDQjj[15550] 1532545264.591556: Storing ***@ICSYNERGY.NET -> host/***@ICSYNERGY.NET in MEMORY:aelDQjj[15550] 1532545264.591560: Getting credentials ***@ICSYNERGY.NET -> host/***@ICSYNERGY.NET using ccache MEMORY:aelDQjj[15550] 1532545264.591561: Retrieving ***@ICSYNERGY.NET -> host/***@ICSYNERGY.NET from MEMORY:aelDQjj with result: 0/Success[15550] 1532545264.591563: Creating authenticator for ***@ICSYNERGY.NET -> host/***@ICSYNERGY.NET, seqnum 1044310048, subkey rc4-hmac/AE37, session key rc4-hmac/D92A[15550] 1532545264.591568: Retrieving host/***@ICSYNERGY.NET from FILE:/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab (vno 3, enctype rc4-hmac) with result: 0/Success[15550] 1532545264.591569: Decrypted AP-REQ with specified server principal host/***@ICSYNERGY.NET: rc4-hmac/AAC7[15550] 1532545264.591570: AP-REQ ticket: ***@ICSYNERGY.NET -> host/***@ICSYNERGY.NET, session key rc4-hmac/D92A[15550] 1532545264.591571: Negotiated enctype based on authenticator: rc4-hmac[15550] 1532545264.591572: Authenticator contains subkey: rc4-hmac/AE37[15550] 1532545264.591573: Resolving unique ccache of type MEMORY[15550] 1532545264.591574: Initializing MEMORY:0ox1opP with default princ ***@ICSYNERGY.NET[15550] 1532545264.591575: Storing host/***@ICSYNERGY.NET -> krbtgt/***@ICSYNERGY.NET in MEMORY:0ox1opP[15550] 1532545264.591576: Storing host/***@ICSYNERGY.NET -> krb5_ccache_conf_data/pa_type/krbtgt\/ICSYNERGY.NET\@***@X-CACHECONF: in MEMORY:0ox1opP[15550] 1532545264.591577: Storing host/***@ICSYNERGY.NET -> krb5_ccache_conf_data/***@X-CACHECONF: in MEMORY:0ox1opP[15550] 1532545264.591578: Storing config in MEMORY:0ox1opP for : proxy_impersonator: host/***@ICSYNERGY.NET[15550] 1532545264.591579: Storing ***@ICSYNERGY.NET -> krb5_ccache_conf_data/***@X-CACHECONF: in MEMORY:0ox1opP[15550] 1532545264.591580: Storing ***@ICSYNERGY.NET -> host/***@ICSYNERGY.NET in MEMORY:0ox1opP[15550] 1532545264.591585: Destroying ccache MEMORY:aelDQjj[15550] 1532545264.591589: Getting credentials ***@ICSYNERGY.NET -> HTTP/ics-dc-***@ICSYNERGY.NET using ccache MEMORY:0ox1opP[15550] 1532545264.591590: Retrieving ***@ICSYNERGY.NET -> HTTP/ics-dc-***@ICSYNERGY.NET from MEMORY:0ox1opP with result: -1765328243/Matching credential not found[15550] 1532545264.591591: Retrieving ***@ICSYNERGY.NET -> host/***@ICSYNERGY.NET from MEMORY:0ox1opP with result: 0/Success[15550] 1532545264.591592: Getting credentials host/***@ICSYNERGY.NET -> HTTP/ics-dc-***@ICSYNERGY.NET using ccache MEMORY:0ox1opP[15550] 1532545264.591593: Retrieving host/***@ICSYNERGY.NET -> krbtgt/***@ICSYNERGY.NET from MEMORY:0ox1opP with result: 0/Success[15550] 1532545264.591594: Starting with TGT for client realm: host/***@ICSYNERGY.NET -> krbtgt/***@ICSYNERGY.NET[15550] 1532545264.591595: Requesting tickets for HTTP/ics-dc-***@ICSYNERGY.NET, referrals on[15550] 1532545264.591596: Generated subkey for TGS request: aes256-cts/CAB1[15550] 1532545264.591597: etypes requested in TGS request: aes256-cts, aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts[15550] 1532545264.591599: Encoding request body and padata into FAST request[15550] 1532545264.591600: Sending request (3855 bytes) to ICSYNERGY.NET[15550] 1532545264.591601: Resolving hostname icsynergy.net[15550] 1532545264.591602: Initiating TCP connection to stream 192.168.0.175:88[15550] 1532545264.591603: Sending TCP request to stream 192.168.0.175:88[15550] 1532545264.591604: Received answer (1622 bytes) from stream 192.168.0.175:88[15550] 1532545264.591605: Terminating TCP connection to stream 192.168.0.175:88[15550] 1532545264.591606: Sending DNS URI query for _kerberos.ICSYNERGY.NET.[15550] 1532545264.591607: No URI records found[15550] 1532545264.591608: Sending DNS SRV query for _kerberos-master._udp.ICSYNERGY.NET.[15550] 1532545264.591609: Sending DNS SRV query for _kerberos-master._tcp.ICSYNERGY.NET.[15550] 1532545264.591610: No SRV records found[15550] 1532545264.591611: Response was not from master KDC[15550] 1532545264.591612: Decoding FAST response[15550] 1532545264.591613: TGS reply is for ***@ICSYNERGY.NET -> HTTP/ics-dc-***@ICSYNERGY.NET with session key aes256-cts/CD25[15550] 1532545264.591614: TGS request result: 0/Success[15550] 1532545264.591615: Received creds for desired service HTTP/ics-dc-***@ICSYNERGY.NET[15550] 1532545264.591616: Storing ***@ICSYNERGY.NET -> HTTP/ics-dc-***@ICSYNERGY.NET in MEMORY:0ox1opP[15550] 1532545264.591618: Creating authenticator for ***@ICSYNERGY.NET -> HTTP/ics-dc-***@ICSYNERGY.NET, seqnum 186715939, subkey aes256-cts/1AFF, session key aes256-cts/CD25<<< RUNNING TEST: t_getImpSecurityToken service principal: host/***@ICSYNERGY.NET host: ***@ics-dc-1.icsynergy.net user: ***@ICSYNERGY.NET[15550] 1532545264.591623: Destroying ccache MEMORY:0ox1opPSUCCESS service principal: host/***@ICSYNERGY.NET host: ***@ics-dc-1.icsynergy.net user: ***@ICSYNERGY.NET!!!GSSAPIMemory END!!!

On Wednesday, July 25, 2018 9:07 AM, Greg Hudson <***@mit.edu> wrote:

On 07/24/2018 03:26 PM, Martin Gee wrote:> Would managing KRB5CCNAME
dynamically via setenv system call be a better

Post by Martin Gee
strategy? Seems like I basically, need to map the REALM to the
appropriate ccache file in a way the gss calles would still work.

That seems like it should work. You could alternatively use
gss_acquire_cred_from() to specify the ccache location. See
t_credstore.c (in the same place as t_s4u.c) for an example, and use the
key "ccache".

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman

Greg Hudson

2018-07-25 20:22:58 UTC

Permalink

Post by Martin Gee
I'd like to use the automatic ccache creation that
gss_acquire_cred_* does. gss_acquire_cred is failing with a custom
keytab location/name.

Have a look at:

http://web.mit.edu/kerberos/krb5-latest/doc/basic/keytab_def.html#default-client-keytab

The client keytab is located separately from the server keytab.

Post by Martin Gee
Seems gss_acquire_cred only works when /etc/krb5.keytab is present.

I wouldn't expect gss_acquire_cred() to use /etc/krb5.keytab unless one
of the locators for the client keytab was explicitly set to point to it.
So this and the corresponding attempts to use /etc/krb5.keytab in the
trace logs are confusing to me. Precisely what GSS calls are being traced?

Post by Martin Gee
export
KRB5_KTNAME=/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab
setenv("KRB5_KTNAME",
"/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab",
1)
krb5_gss_register_acceptor_identity("/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab");

These all set the server keytab location.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mail

Martin Gee

2018-07-25 20:45:38 UTC

Permalink

krb5_gss_register_acceptor_identity("../file.keytab");
gss_acquire_cred(minor, gss_spn_name, GSS_C_INDEFINITE, &mechset_krb5, GSS_C_BOTH, &impersonator_cred, NULL, &time_rec);
gss_acquire_cred_impersonate_name(minor, impersonator_cred, gss_user_name, GSS_C_INDEFINITE, &mechset_krb5, GSS_C_INITIATE, &user_cred, NULL, &time_rec);
gss_init_sec_context(minor, user_cred, &ictx, gss_spn_name, &mech_krb5, GSS_C_REPLAY_FLAG | GSS_C_SEQUENCE_FLAG, GSS_C_INDEFINITE, GSS_C_NO_CHANNEL_BINDINGS, &atok, NULL, &itok, NULL, NULL);
gss_accept_sec_context(minor, &actx, impersonator_cred, &itok, GSS_C_NO_CHANNEL_BINDINGS, &source_name, &mech, &atok, NULL, NULL, &delegated_cred);

Post by Martin Gee
I'd like to use the automatic ccache creation that
gss_acquire_cred_* does. gss_acquire_cred is failing with a custom
keytab location/name.

Have a look at:

http://web.mit.edu/kerberos/krb5-latest/doc/basic/keytab_def.html#default-client-keytab

The client keytab is located separately from the server keytab.

Post by Martin Gee
Seems gss_acquire_cred only works when /etc/krb5.keytab is present.

These all set the server keytab location.

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mail

Martin Gee

2018-07-26 15:54:16 UTC

Permalink

Greg, I have something working :) I had to set both KRB5_KTNAME and KRB5_CLIENT_KTNAME to my desired keytab file.
Can you plz help me confirm my understanding of why both env variables are necessary?

e.g. where t_getImpSecurityToken does what t_s4u w/ ccache creation
setenv("KRB5CCNAME", "/tmp/krb5cc_v_icsynergy_net", 1); setenv("KRB5_KTNAME", "/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab", 1); setenv("KRB5_CLIENT_KTNAME", "/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab", 1); const char* service_name = "host/***@ICSYNERGY.NET"; const char* user_name = "***@ICSYNERGY.NET"; const char* host_name = "***@ics-dc-1.icsynergy.net"; t_getImpSecurityToken(service_name, user_name, host_name);
KRB_KTNAME is logged:[2606] 1532615727.367867: Retrieving host/***@ICSYNERGY.NET from FILE:/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab (vno 0, enctype 0) with result: 0/Success

KRB5_CLIENT_KTNAME is logged:
[4694] 1532615787.103586: Retrieving host/***@ICSYNERGY.NET from FILE:/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab (vno 0, enctype 0) with result: 0/Success
Here is my gss_acquire_cred (seems to be all rooted in this call):gss_acquire_cred(minor, gss_spn_name, GSS_C_INDEFINITE, &mechset_krb5, GSS_C_BOTH, &impersonator_cred, NULL, &time_rec);
GSS_C_BOTH - (acquire_cred.c) acquire_accept_cred uses KRB_KTNAME(acquire_cred.c) acquire_init_cred uses KRB5_CLIENT_KTNAME which overrides:
/etc/krb5.conf[libdefaults]
default_client_keytab_name = /etc/krb5.keytab

The main diff from t_s4u is; gss_spn_name (host/***@ICSYNERGY.NET) is being used instead of GSS_C_NO_NAME

I'm assuming gss_spn_name + GSS_C_BOTH is exercising both env variables?

On Wednesday, July 25, 2018 3:45 PM, Martin Gee <***@yahoo.com> wrote:

krb5_gss_register_acceptor_identity("../file.keytab");
gss_acquire_cred(minor, gss_spn_name, GSS_C_INDEFINITE, &mechset_krb5, GSS_C_BOTH, &impersonator_cred, NULL, &time_rec);
gss_acquire_cred_impersonate_name(minor, impersonator_cred, gss_user_name, GSS_C_INDEFINITE, &mechset_krb5, GSS_C_INITIATE, &user_cred, NULL, &time_rec);
gss_init_sec_context(minor, user_cred, &ictx, gss_spn_name, &mech_krb5, GSS_C_REPLAY_FLAG | GSS_C_SEQUENCE_FLAG, GSS_C_INDEFINITE, GSS_C_NO_CHANNEL_BINDINGS, &atok, NULL, &itok, NULL, NULL);
gss_accept_sec_context(minor, &actx, impersonator_cred, &itok, GSS_C_NO_CHANNEL_BINDINGS, &source_name, &mech, &atok, NULL, NULL, &delegated_cred);

Post by Martin Gee
I'd like to use the automatic ccache creation that
gss_acquire_cred_* does. gss_acquire_cred is failing with a custom
keytab location/name.

Have a look at:

http://web.mit.edu/kerberos/krb5-latest/doc/basic/keytab_def.html#default-client-keytab

The client keytab is located separately from the server keytab.

Post by Martin Gee
Seems gss_acquire_cred only works when /etc/krb5.keytab is present.

These all set the server keytab location.

_______________________________________________
krbdev mailing list ***@mi

Greg Hudson

2018-07-26 16:05:38 UTC

Permalink

I'm assuming *gss_spn_name +* GSS_C_BOTH is exercising both env variables?

Yes. GSS_C_BOTH asks for both client and server credentials in the
resulting cred. The client side of the cred uses $KRB5_CLIENT_KTNAME
(or the "client_keytab" key in gss_acquire_cred_from()) as well as the
$KRB5CCNAME (or the "ccache" key), while the server side uses
$KRB5_KTNAME (or the "keytab" key).

I get that you are working from t_s4u at the moment, and that program
does an init_sec_context and accept_sec_context to itself for testing
purposes. But I would guess that your actual application should not
need to call accept_sec_context(), so you can probably acquire the cred
with GSS_C_INITIATE and not bother with $KRB5_KTNAME.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbd