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

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

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

Martin Gee
Added:  [hidden email]

    On Tuesday, July 24, 2018 12:52 PM, Martin Gee <[hidden email]> 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.
$ mkdir /tmp/mydir $ export KRB5CCNAME=DIR:/tmp/mydir $ kinit -k -t ./spgateway_icsynergy_net.keytab host/[hidden email]$ kinit -k -t ./spgateway_uicsynergy_biz.keytab host/[hidden email]$ klist -ATicket cache: DIR::/tmp/mydir/tktCzQyfjDefault principal: host/[hidden email]
Valid starting       Expires              Service principal07/24/2018 16:49:20  07/25/2018 02:49:20  krbtgt/[hidden email] renew until 07/31/2018 16:49:20
Ticket cache: DIR::/tmp/mydir/tktVQeLF4Default principal: host/[hidden email]
Valid starting       Expires              Service principal07/24/2018 16:48:47  07/25/2018 02:48:47  krbtgt/[hidden email] renew until 07/31/2018 16:48:47
>> WORKS$ /opt/spgateway/bin/t_s4u u:[hidden email] h:[hidden email] ./spgateway_uicsynergy_biz.keytab<< WORKS
>> FAILS $ /opt/spgateway/bin/t_s4u u:[hidden email] h:[hidden email] ./spgateway_icsynergy_net.keytabProtocol transition tests follow-----------------------------------
[25007] 1532451100.523203: Getting credentials [hidden email] -> host/[hidden email] using ccache DIR::/tmp/mydir/tktCzQyfj[25007] 1532451100.523204: Retrieving [hidden email] -> host/[hidden email] from DIR::/tmp/mydir/tktCzQyfj with result: -1765328243/Matching credential not found (filename: /tmp/mydir/tktCzQyfj)[25007] 1532451100.523205: Getting credentials host/[hidden email] -> krbtgt/[hidden email] using ccache DIR::/tmp/mydir/tktCzQyfj[25007] 1532451100.523206: Retrieving host/[hidden email] -> krbtgt/[hidden email] from DIR::/tmp/mydir/tktCzQyfj with result: -1765328243/Matching credential not found (filename: /tmp/mydir/tktCzQyfj)[25007] 1532451100.523207: Retrieving host/[hidden email] -> krbtgt/[hidden email] from DIR::/tmp/mydir/tktCzQyfj with result: 0/Success[25007] 1532451100.523208: Starting with TGT for client realm: host/[hidden email] -> krbtgt/[hidden email][25007] 1532451100.523209: Requesting tickets for krbtgt/[hidden email], 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/[hidden email], 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On 07/24/2018 01:56 PM, Martin Gee wrote:
> Added:  [hidden email]

Please pick one list or the other.  I've left the message to
[hidden email] 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Martin Gee
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/[hidden email]$ export KRB5CCNAME=/tmp/krb5cc_v_uicsynergy_biz$ kinit -k -t ./krb5.keytab host/[hidden email]$klistWill show last kinit result/opt/spgateway/bin/t_s4u u:[hidden email] h:[hidden email] ./krb5.keytab/opt/spgateway/bin/t_s4u u:[hidden email] h:[hidden email] ./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 <[hidden email]> wrote:
 

 On 07/24/2018 01:56 PM, Martin Gee wrote:
> Added:  [hidden email]

Please pick one list or the other.  I've left the message to
[hidden email] 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Martin Gee
Note: merging the keytabs does not work.
Should be:export KRB5CCNAME=/tmp/krb5cc_v_icsynergy_net$ kinit -k -t ./krb5_net.keytab host/[hidden email]$ export KRB5CCNAME=/tmp/krb5cc_v_uicsynergy_biz$ kinit -k -t ./krb5_biz.keytab host/[hidden email]
export KRB5CCNAME=/tmp/krb5cc_v_icsynergy_net
/opt/spgateway/bin/t_s4u u:[hidden email] h:[hidden email] ./krb5_net.keytab$ export KRB5CCNAME=/tmp/krb5cc_v_uicsynergy_biz
/opt/spgateway/bin/t_s4u u:[hidden email] h:[hidden email] ./krb5_biz.keytab

 

    On Tuesday, July 24, 2018 2:26 PM, Martin Gee <[hidden email]> 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/[hidden email]$ export KRB5CCNAME=/tmp/krb5cc_v_uicsynergy_biz$ kinit -k -t ./krb5.keytab host/[hidden email]$klistWill show last kinit result/opt/spgateway/bin/t_s4u u:[hidden email] h:[hidden email] ./krb5.keytab/opt/spgateway/bin/t_s4u u:[hidden email] h:[hidden email] ./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 <[hidden email]> wrote:
 

 On 07/24/2018 01:56 PM, Martin Gee wrote:
> Added:  [hidden email]

Please pick one list or the other.  I've left the message to
[hidden email] 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
In reply to this post by Martin Gee
On 07/24/2018 03:26 PM, Martin Gee wrote:> 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.

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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Martin Gee
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/[hidden email] 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/[hidden email] 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/[hidden email] 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/[hidden email] from FILE:/etc/krb5.keytab (vno 0, enctype 0) with result: 0/Success[15550] 1532545264.591461: Getting initial credentials for host/[hidden email][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/[hidden email] 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/[hidden email][15550] 1532545264.591517: Storing host/[hidden email] -> krbtgt/[hidden email] in FILE:/tmp/krb5cc_1000[15550] 1532545264.591518: Storing config in FILE:/tmp/krb5cc_1000 for krbtgt/[hidden email]: pa_type: 2[15550] 1532545264.591519: Storing host/[hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/ICSYNERGY.NET\@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/[hidden email] -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in FILE:/tmp/krb5cc_1000[15550] 1532545264.591525: Getting credentials [hidden email] -> host/[hidden email] using ccache FILE:/tmp/krb5cc_1000[15550] 1532545264.591526: Retrieving [hidden email] -> host/[hidden email] from FILE:/tmp/krb5cc_1000 with result: -1765328243/Matching credential not found (filename: /tmp/krb5cc_1000)[15550] 1532545264.591527: Getting credentials host/[hidden email] -> krbtgt/[hidden email] using ccache FILE:/tmp/krb5cc_1000[15550] 1532545264.591528: Retrieving host/[hidden email] -> krbtgt/[hidden email] from FILE:/tmp/krb5cc_1000 with result: 0/Success[15550] 1532545264.591529: Get cred via TGT krbtgt/[hidden email] after requesting host/[hidden email] (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 [hidden email] -> host/[hidden email] 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 [hidden email][15550] 1532545264.591551: Storing host/[hidden email] -> krbtgt/[hidden email] in MEMORY:aelDQjj[15550] 1532545264.591552: Storing host/[hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/ICSYNERGY.NET\@ICSYNERGY.NET@X-CACHECONF: in MEMORY:aelDQjj[15550] 1532545264.591553: Storing host/[hidden email] -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:aelDQjj[15550] 1532545264.591554: Storing config in MEMORY:aelDQjj for : proxy_impersonator: host/[hidden email][15550] 1532545264.591555: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:aelDQjj[15550] 1532545264.591556: Storing [hidden email] -> host/[hidden email] in MEMORY:aelDQjj[15550] 1532545264.591560: Getting credentials [hidden email] -> host/[hidden email] using ccache MEMORY:aelDQjj[15550] 1532545264.591561: Retrieving [hidden email] -> host/[hidden email] from MEMORY:aelDQjj with result: 0/Success[15550] 1532545264.591563: Creating authenticator for [hidden email] -> host/[hidden email], seqnum 1044310048, subkey rc4-hmac/AE37, session key rc4-hmac/D92A[15550] 1532545264.591568: Retrieving host/[hidden email] 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/[hidden email]: rc4-hmac/AAC7[15550] 1532545264.591570: AP-REQ ticket: [hidden email] -> host/[hidden email], 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 [hidden email][15550] 1532545264.591575: Storing host/[hidden email] -> krbtgt/[hidden email] in MEMORY:0ox1opP[15550] 1532545264.591576: Storing host/[hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/ICSYNERGY.NET\@ICSYNERGY.NET@X-CACHECONF: in MEMORY:0ox1opP[15550] 1532545264.591577: Storing host/[hidden email] -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:0ox1opP[15550] 1532545264.591578: Storing config in MEMORY:0ox1opP for : proxy_impersonator: host/[hidden email][15550] 1532545264.591579: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:0ox1opP[15550] 1532545264.591580: Storing [hidden email] -> host/[hidden email] in MEMORY:0ox1opP[15550] 1532545264.591585: Destroying ccache MEMORY:aelDQjj[15550] 1532545264.591589: Getting credentials [hidden email] -> HTTP/[hidden email] using ccache MEMORY:0ox1opP[15550] 1532545264.591590: Retrieving [hidden email] -> HTTP/[hidden email] from MEMORY:0ox1opP with result: -1765328243/Matching credential not found[15550] 1532545264.591591: Retrieving [hidden email] -> host/[hidden email] from MEMORY:0ox1opP with result: 0/Success[15550] 1532545264.591592: Getting credentials host/[hidden email] -> HTTP/[hidden email] using ccache MEMORY:0ox1opP[15550] 1532545264.591593: Retrieving host/[hidden email] -> krbtgt/[hidden email] from MEMORY:0ox1opP with result: 0/Success[15550] 1532545264.591594: Starting with TGT for client realm: host/[hidden email] -> krbtgt/[hidden email][15550] 1532545264.591595: Requesting tickets for HTTP/[hidden email], 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 [hidden email] -> HTTP/[hidden email] with session key aes256-cts/CD25[15550] 1532545264.591614: TGS request result: 0/Success[15550] 1532545264.591615: Received creds for desired service HTTP/[hidden email][15550] 1532545264.591616: Storing [hidden email] -> HTTP/[hidden email] in MEMORY:0ox1opP[15550] 1532545264.591618: Creating authenticator for [hidden email] -> HTTP/[hidden email], seqnum 186715939, subkey aes256-cts/1AFF, session key aes256-cts/CD25<<< RUNNING TEST: t_getImpSecurityToken service principal: host/[hidden email] host: [hidden email] user: [hidden email][15550] 1532545264.591623: Destroying ccache MEMORY:0ox1opPSUCCESS service principal: host/[hidden email] host: [hidden email] user: [hidden email]!!!GSSAPIMemory END!!!
 

    On Wednesday, July 25, 2018 9:07 AM, Greg Hudson <[hidden email]> wrote:
 

 On 07/24/2018 03:26 PM, Martin Gee wrote:> 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.

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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On 07/25/2018 03:04 PM, Martin Gee wrote:
> 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.

> 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?

> I've tried these:
> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Martin Gee

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);

 

    On Wednesday, July 25, 2018 3:23 PM, Greg Hudson <[hidden email]> wrote:
 

 On 07/25/2018 03:04 PM, Martin Gee wrote:
> 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.

> 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?

> I've tried these:
> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Martin Gee
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/[hidden email]";        const char* user_name = "[hidden email]";        const char* host_name =  "[hidden email]";        t_getImpSecurityToken(service_name, user_name,  host_name);
KRB_KTNAME is logged:[2606] 1532615727.367867: Retrieving host/[hidden email] 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/[hidden email] 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/[hidden email]) 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 <[hidden email]> 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);

 

    On Wednesday, July 25, 2018 3:23 PM, Greg Hudson <[hidden email]> wrote:
 

 On 07/25/2018 03:04 PM, Martin Gee wrote:
> 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.

> 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?

> I've tried these:
> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On 07/26/2018 11:54 AM, Martin Gee wrote:
> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev