Not getting delegation credential from gss_accept_sec_context()
Xie, Hugh
hugh.xie at bankofamerica.com
Wed Oct 8 15:41:04 EDT 2014
After switching version 1.12.2, as a follow up question to the next step of S4U2Proxy.
I passed the delegated_cred_handle from *gss_accept_sec_context()* to *gss_init_sec_context*. I got a "No context has been established" error since the context_handle is reinitialized to GSS_C_NO_CONTEXT. This is not a problem when I am not using delegated_cred_handle. When I attempt to pass the same context handle from gss_accept_sec_context(), I got a segmentation error.
Can you tell me what context_handle to use?
Thanks again.
-----Original Message-----
From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On Behalf Of Xie, Hugh
Sent: Wednesday, October 08, 2014 1:29 PM
To: Kerberos at mit.edu; Greg Hudson
Subject: RE: Not getting delegation credential from gss_accept_sec_context()
Switched to 1.12 resolved this issue. Thanks.
-----Original Message-----
From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On Behalf Of Xie, Hugh
Sent: Wednesday, October 08, 2014 10:30 AM
To: Kerberos at mit.edu; Greg Hudson
Subject: RE: Not getting delegation credential from gss_accept_sec_context()
We are using version 1.9.1. When I turn on backback in debugger, I see the gss_accept_sec_context was in turn called internally inside spnego_mech.c that pass a NULL verifier_cred_handle krb5_gss_accept_sec_context_ext. Anyway I can resolve this issue? Here are the full backtrace:
(gdb) backtrace
#0 kg_accept_krb5 (minor_status=0x7fffffffe2d4, context_handle=0x60a510, verifier_cred_handle=0x0, input_token=0x60a520,
input_chan_bindings=0x0, src_name=0x7fffffffd748, mech_type=0x7fffffffd738, output_token=0x7fffffffd870, ret_flags=0x7fffffffd758,
time_rec=0x0, delegated_cred_handle=0x7fffffffd750, exts=0x7fffffffd290) at accept_sec_context.c:440
#1 0x00002aaaaaaca23a in krb5_gss_accept_sec_context_ext (minor_status=0x7fffffffe2d4, context_handle=0x60a510, verifier_cred_handle=0x0,
input_token=0x60a520, input_chan_bindings=0x0, src_name=0x7fffffffd748, mech_type=0x7fffffffd738, output_token=0x7fffffffd870,
ret_flags=0x7fffffffd758, time_rec=0x0, delegated_cred_handle=0x7fffffffd750, exts=0x7fffffffd290) at accept_sec_context.c:1369
#2 0x00002aaaaaaca396 in krb5_gss_accept_sec_context (minor_status=0x7fffffffe2d4, context_handle=0x60a510, verifier_cred_handle=0x0,
input_token=0x60a520, input_chan_bindings=0x0, src_name=0x7fffffffd748, mech_type=0x7fffffffd738, output_token=0x7fffffffd870,
ret_flags=0x7fffffffd758, time_rec=0x0, delegated_cred_handle=0x7fffffffd750) at accept_sec_context.c:1398
#3 0x00002aaaaaabcd90 in gss_accept_sec_context (minor_status=0x7fffffffe2d4, context_handle=<optimized out>,
verifier_cred_handle=<optimized out>, input_token_buffer=<optimized out>, input_chan_bindings=<optimized out>, src_name=0x60c888,
mech_type=0x7fffffffddc8, output_token=0x7fffffffd870, ret_flags=0x60c880, time_rec=0x0, d_cred=0x7fffffffdde0)
at g_accept_sec_context.c:220
#4 0x00002aaaaaae0618 in acc_ctx_call_acc (tokflag=<optimized out>, negState=<optimized out>, delegated_cred_handle=<optimized out>,
time_rec=<optimized out>, ret_flags=<optimized out>, mechtok_out=<optimized out>, mech_type=<optimized out>, mechtok_in=<optimized out>,
spcred=<optimized out>, sc=<optimized out>, minor_status=<optimized out>) at spnego_mech.c:1535
#5 spnego_gss_accept_sec_context (minor_status=0x7fffffffe2d4, context_handle=0x608420, verifier_cred_handle=0x52435f4f4e5f435f,
input_token=<optimized out>, input_chan_bindings=<optimized out>, src_name=<optimized out>, mech_type=0x7fffffffddc8,
output_token=0x7fffffffe2a0, ret_flags=0x7fffffffdde8, time_rec=0x0, delegated_cred_handle=0x7fffffffdde0) at spnego_mech.c:1703
#6 0x00002aaaaaabcd90 in gss_accept_sec_context (minor_status=0x7fffffffe2d4, context_handle=<optimized out>,
verifier_cred_handle=<optimized out>, input_token_buffer=<optimized out>, input_chan_bindings=<optimized out>, src_name=0x607020,
mech_type=0x0, output_token=0x7fffffffe2a0, ret_flags=0x7fffffffe29c, time_rec=0x0, d_cred=0x7fffffffe288) at g_accept_sec_context.c:220
#7 0x00000000004014ec in authenticate_gss_server_init (service=0x4016a7 "HTTP", state=0x607010) at server_init.c:264
#8 0x0000000000401544 in main () at server_init.c:299
-----Original Message-----
From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On Behalf Of Xie, Hugh
Sent: Monday, October 06, 2014 4:50 PM
To: Kerberos at mit.edu
Subject: Not getting delegation credential from gss_accept_sec_context()
Hi,
I am having trouble with S4U2Proxy. Looking into *accept_sec_context.c*, it has :
* if (delegated_cred_handle != NULL &&
deleg_cred == NULL && /* no unconstrained delegation */
cred->usage == GSS_C_BOTH &&
(ticket->enc_part2->flags & TKT_FLG_FORWARDABLE)) {
/*
* Now, we always fabricate a delegated credentials handle
* containing the service ticket to ourselves, which can be
* used for S4U2Proxy.
*/
major_status = create_constrained_deleg_creds(minor_status, cred,
ticket, &deleg_cred,
context);
if (GSS_ERROR(major_status))
goto fail;
ctx->gss_flags |= GSS_C_DELEG_FLAG;
}
*
I created some printf to check verifier_cred_handle I passed into *gss_accept_sec_context()* are set back to GSS_C_NO_CREDENTIAL once it reach kg_accept_krb5(). That in turn cause one of the condition * cred->usage == GSS_C_BOTH * to be false. I definite verified verifier_cred_handle before I called gss_accept_sec_context(). And it is coming from a call:
*
maj_stat = gss_acquire_cred(&min_stat, GSS_C_NO_NAME, GSS_C_INDEFINITE,
GSS_C_NO_OID_SET, GSS_C_BOTH, &state->server_creds, NULL, NULL);
*
So my assumption cred->usage flag should be GSS_C_BOTH.
Anyway, please let me know I can debug this issue.
Thanks.
----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
________________________________________________
Kerberos mailing list Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
________________________________________________
Kerberos mailing list Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
________________________________________________
Kerberos mailing list Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
More information about the Kerberos
mailing list