Skip Menu |
 

From: Hong Ye <hy93@cornell.edu>
To: "krb5-bugs@mit.edu" <krb5-bugs@mit.edu>
Subject: KFW 4.1 credential cache issue
Date: Tue, 24 Apr 2018 15:51:24 +0000
Download (untitled) / with headers
text/plain 1.2KiB

Hello,

 

We have an in house developed IIS extension that does authentication and authorization. We have a Windows 2012 server and have KFW 4.1 installed. It works fine for single request. But when sending concurrent requests to IIS, it generated Kerberos error when requesting Kerberos service ticket( function gss_init_sec_context is called )

 

Here are the error in our log:

“Credential cache is empty” or “No credentials cache found”

 

I would like to debug KFW code myself and tried to build the source. But I keep getting error when run nmake, any idea how to fix the build issue?

 

Faulting application name: libecho.exe, version: 0.0.0.0, time stamp: 0x5adf3b6a

Faulting module name: ntdll.dll, version: 6.3.9600.18969, time stamp: 0x5aa29ff0

Exception code: 0xc0000005

Fault offset: 0x000000000003b709

Faulting process id: 0xb10

Faulting application start time: 0x01d3dbdc839ddfe7

Faulting application path: c:\kfw-4.1\src\util\windows\obj\AMD64\dbg\libecho.exe

Faulting module path: C:\Windows\SYSTEM32\ntdll.dll

Report Id: c14b17cb-47cf-11e8-81cd-0ea29ef5ed10

Faulting package full name:

Faulting package-relative application ID:

 

Thanks,

Hong Ye

Identity Management

CIT

Cornell University

Download (untitled) / with headers
text/plain 1.3KiB
[hy93@cornell.edu - Tue Apr 24 12:15:01 2018]:

Show quoted text
> Hello,
>
>
> We have an in house developed IIS extension that does authentication
> and authorization. We have a Windows 2012 server and have KFW 4.1
> installed. It works fine for single request. But when sending
> concurrent requests to IIS, it generated Kerberos error when
> requesting Kerberos service ticket( function gss_init_sec_context
> is called )
>
>
>
> Here are the error in our log:
>
> “Credential cache is empty” or “No credentials cache found”
>
> I would like to debug KFW code myself and tried to build the source.
> But I keep getting error when run nmake, any idea how to fix the
> build issue?
>
> Faulting application name: libecho.exe, version: 0.0.0.0, time stamp:
> 0x5adf3b6a
> Faulting module name: ntdll.dll, version: 6.3.9600.18969, time stamp:
> 0x5aa29ff0
> Exception code: 0xc0000005
> Fault offset: 0x000000000003b709
> Faulting process id: 0xb10
> Faulting application start time: 0x01d3dbdc839ddfe7
> Faulting application path: c:\kfw-
> 4.1\src\util\windows\obj\AMD64\dbg\libecho.exe
> Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
> Report Id: c14b17cb-47cf-11e8-81cd-0ea29ef5ed10
> Faulting package full name:
> Faulting package-relative application ID:

What credentials cache type is being used by the application (e.g.,
FILE, LSA, etc.)?
From: Hong Ye <hy93@cornell.edu>
To: "rt-comment@krbdev.mit.edu" <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #8672] KFW 4.1 credential cache issue
Date: Wed, 25 Apr 2018 13:16:10 +0000
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.6KiB
We use memory cache type.

Thanks,
Hong

On 4/25/18, 8:12 AM, "Benjamin Kaduk via RT" <rt-comment@krbdev.mit.edu> wrote:

[hy93@cornell.edu - Tue Apr 24 12:15:01 2018]:

Show quoted text
> Hello,
>
>
> We have an in house developed IIS extension that does authentication
> and authorization. We have a Windows 2012 server and have KFW 4.1
> installed. It works fine for single request. But when sending
> concurrent requests to IIS, it generated Kerberos error when
> requesting Kerberos service ticket( function gss_init_sec_context
> is called )
>
>
>
> Here are the error in our log:
>
> “Credential cache is empty” or “No credentials cache found”
>
> I would like to debug KFW code myself and tried to build the source.
> But I keep getting error when run nmake, any idea how to fix the
> build issue?
>
> Faulting application name: libecho.exe, version: 0.0.0.0, time stamp:
> 0x5adf3b6a
> Faulting module name: ntdll.dll, version: 6.3.9600.18969, time stamp:
> 0x5aa29ff0
> Exception code: 0xc0000005
> Fault offset: 0x000000000003b709
> Faulting process id: 0xb10
> Faulting application start time: 0x01d3dbdc839ddfe7
> Faulting application path: c:\kfw-
> 4.1\src\util\windows\obj\AMD64\dbg\libecho.exe
> Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
> Report Id: c14b17cb-47cf-11e8-81cd-0ea29ef5ed10
> Faulting package full name:
> Faulting package-relative application ID:

What credentials cache type is being used by the application (e.g.,
FILE, LSA, etc.)?


Download (untitled) / with headers
text/plain 2.3KiB
[hy93@cornell.edu - Wed Apr 25 09:16:14 2018]:

Show quoted text
> We use memory cache type.

Thanks for the quick reply -- I don't think we know of any issues with
the memory cache type that could cause this behavior, so proceeding
with your original debugging plan seems wise.

Could you say a bit more about what build environment you are using and
what build instructions you are following?

In particular, what versions of (at least) windows, visual studio,
windows SDK, and perl are in use, as well as a pointer to the
documentation from which you are getting the build commands to run
(even if it is just the README in the source of the tarball).

Thanks,

Ben

Show quoted text
> Thanks,
> Hong
>
> On 4/25/18, 8:12 AM, "Benjamin Kaduk via RT" <rt-
> comment@krbdev.mit.edu> wrote:
>
> [hy93@cornell.edu - Tue Apr 24 12:15:01 2018]:
>
> > Hello,
> >
> >
> > We have an in house developed IIS extension that does
> authentication
> > and authorization. We have a Windows 2012 server and have
KFW
Show quoted text
> 4.1
> > installed. It works fine for single request. But when
sending
Show quoted text
> > concurrent requests to IIS, it generated Kerberos error when
> > requesting Kerberos service ticket( function
> gss_init_sec_context
> > is called )
> >
> >
> >
> > Here are the error in our log:
> >
> > “Credential cache is empty” or “No credentials cache
> found”
> >
> > I would like to debug KFW code myself and tried to build the
> source.
> > But I keep getting error when run nmake, any idea how to fix
> the
> > build issue?
> >
> > Faulting application name: libecho.exe, version: 0.0.0.0, time
> stamp:
> > 0x5adf3b6a
> > Faulting module name: ntdll.dll, version: 6.3.9600.18969, time
> stamp:
> > 0x5aa29ff0
> > Exception code: 0xc0000005
> > Fault offset: 0x000000000003b709
> > Faulting process id: 0xb10
> > Faulting application start time: 0x01d3dbdc839ddfe7
> > Faulting application path: c:\kfw-
> > 4.1\src\util\windows\obj\AMD64\dbg\libecho.exe
> > Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
> > Report Id: c14b17cb-47cf-11e8-81cd-0ea29ef5ed10
> > Faulting package full name:
> > Faulting package-relative application ID:
>
> What credentials cache type is being used by the application
> (e.g.,
> FILE, LSA, etc.)?
>
>
From: Hong Ye <hy93@cornell.edu>
To: "rt-comment@krbdev.mit.edu" <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #8672] KFW 4.1 credential cache issue
Date: Thu, 26 Apr 2018 13:25:54 +0000
RT-Send-Cc:
Thanks for your reply. I followed the instruction from the README in the source of the tarball. Here is my build environment:

Windows 2012 R2
Microsoft visual studio 12.0
Windows SDK 8
Perl 5.12.4

Thanks for your help,
Hong

On 4/25/18, 3:43 PM, "Benjamin Kaduk via RT" <rt-comment@krbdev.mit.edu> wrote:

[hy93@cornell.edu - Wed Apr 25 09:16:14 2018]:

Show quoted text
> We use memory cache type.

Thanks for the quick reply -- I don't think we know of any issues with
the memory cache type that could cause this behavior, so proceeding
with your original debugging plan seems wise.

Could you say a bit more about what build environment you are using and
what build instructions you are following?

In particular, what versions of (at least) windows, visual studio,
windows SDK, and perl are in use, as well as a pointer to the
documentation from which you are getting the build commands to run
(even if it is just the README in the source of the tarball).

Thanks,

Ben

Show quoted text
> Thanks,
> Hong
>
> On 4/25/18, 8:12 AM, "Benjamin Kaduk via RT" <rt-
> comment@krbdev.mit.edu> wrote:
>
> [hy93@cornell.edu - Tue Apr 24 12:15:01 2018]:
>
> > Hello,
> >
> >
> > We have an in house developed IIS extension that does
> authentication
> > and authorization. We have a Windows 2012 server and have
KFW
Show quoted text
> 4.1
> > installed. It works fine for single request. But when
sending
Show quoted text
> > concurrent requests to IIS, it generated Kerberos error when
> > requesting Kerberos service ticket( function
> gss_init_sec_context
> > is called )
> >
> >
> >
> > Here are the error in our log:
> >
> > “Credential cache is empty” or “No credentials cache
> found”
> >
> > I would like to debug KFW code myself and tried to build the
> source.
> > But I keep getting error when run nmake, any idea how to fix
> the
> > build issue?
> >
> > Faulting application name: libecho.exe, version: 0.0.0.0, time
> stamp:
> > 0x5adf3b6a
> > Faulting module name: ntdll.dll, version: 6.3.9600.18969, time
> stamp:
> > 0x5aa29ff0
> > Exception code: 0xc0000005
> > Fault offset: 0x000000000003b709
> > Faulting process id: 0xb10
> > Faulting application start time: 0x01d3dbdc839ddfe7
> > Faulting application path: c:\kfw-
> > 4.1\src\util\windows\obj\AMD64\dbg\libecho.exe
> > Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
> > Report Id: c14b17cb-47cf-11e8-81cd-0ea29ef5ed10
> > Faulting package full name:
> > Faulting package-relative application ID:
>
> What credentials cache type is being used by the application
> (e.g.,
> FILE, LSA, etc.)?
>
>




Download (untitled) / with headers
text/plain 1.1KiB
[hy93@cornell.edu - Thu Apr 26 09:25:58 2018]:

Show quoted text
> Thanks for your reply. I followed the instruction from the README in
> the source of the tarball. Here is my build environment:
>
> Windows 2012 R2
> Microsoft visual studio 12.0
> Windows SDK 8
> Perl 5.12.4

I don't have a whole lot of experience with VS 2013 (or access to such
a setup at the moment), but one common source of trouble is ensuring
that all the moving pieces agree on whether 32- or 64-bit code is being
built (and potentially also what processor architecture). This
includes at least the way that the cmd.exe shell is spawned and/or
initialized, and the value of the CPU environment variable. The build
log snippet implies that something is trying to build 64-bit code (the
"obj/AMD64" in the path to libecho), but I note that the README
instructions start off by building the 32-bit code. (It's okay to just
build the 64-bit code and not the 32-bit code for local testing; the
32-bit build is included in the instructions there so that the 32-bit
libraries can be included in the 64-bit MSI installer.)

Separately, sometimes the source of the perl binary can be relevant --
do you have Strawberry Perl, ActiveState Perl, or something else?
From: Hong Ye <hy93@cornell.edu>
To: "rt-comment@krbdev.mit.edu" <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #8672] KFW 4.1 credential cache issue
Date: Mon, 30 Apr 2018 17:11:39 +0000
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.6KiB
I first used Strawberry perl, it gave me error when doing nmake -f Makefile.in prep-windows . Then I used ActivateState perl, it generated error when doing nmake.

What is the build environment that you can successfully build KFW 4.1?

Hong


On 4/29/18, 10:13 AM, "Benjamin Kaduk via RT" <rt-comment@krbdev.mit.edu> wrote:

[hy93@cornell.edu - Thu Apr 26 09:25:58 2018]:

Show quoted text
> Thanks for your reply. I followed the instruction from the README in
> the source of the tarball. Here is my build environment:
>
> Windows 2012 R2
> Microsoft visual studio 12.0
> Windows SDK 8
> Perl 5.12.4

I don't have a whole lot of experience with VS 2013 (or access to such
a setup at the moment), but one common source of trouble is ensuring
that all the moving pieces agree on whether 32- or 64-bit code is being
built (and potentially also what processor architecture). This
includes at least the way that the cmd.exe shell is spawned and/or
initialized, and the value of the CPU environment variable. The build
log snippet implies that something is trying to build 64-bit code (the
"obj/AMD64" in the path to libecho), but I note that the README
instructions start off by building the 32-bit code. (It's okay to just
build the 64-bit code and not the 32-bit code for local testing; the
32-bit build is included in the instructions there so that the 32-bit
libraries can be included in the 64-bit MSI installer.)

Separately, sometimes the source of the perl binary can be relevant --
do you have Strawberry Perl, ActiveState Perl, or something else?


Download (untitled) / with headers
text/plain 2.1KiB
I don't have that configuration on the machine in front of me, but from
memory, it was Windows 7 Enterprise (I used the subsystem for unix
applications to get awk/sed, but I understand the SUA was removed in a
later release), Visual Studio 2010 Professional, Strawberry Perl, and
Windows SDK 7.1. (The perl 5.12.4 version you cite below seems a
rather old version, though I don't know for sure that that version is
old enough to cause problems.)

-Ben


[hy93@cornell.edu - Mon Apr 30 13:11:42 2018]:

Show quoted text
> I first used Strawberry perl, it gave me error when doing nmake -f
> Makefile.in prep-windows . Then I used ActivateState perl, it
> generated error when doing nmake.
>
> What is the build environment that you can successfully build KFW
4.1?
Show quoted text
>
> Hong
>
>
> On 4/29/18, 10:13 AM, "Benjamin Kaduk via RT" <rt-
> comment@krbdev.mit.edu> wrote:
>
> [hy93@cornell.edu - Thu Apr 26 09:25:58 2018]:
>
> > Thanks for your reply. I followed the instruction from the
> README in
> > the source of the tarball. Here is my build environment:
> >
> > Windows 2012 R2
> > Microsoft visual studio 12.0
> > Windows SDK 8
> > Perl 5.12.4
>
> I don't have a whole lot of experience with VS 2013 (or access to
> such
> a setup at the moment), but one common source of trouble is
> ensuring
> that all the moving pieces agree on whether 32- or 64-bit code is
> being
> built (and potentially also what processor architecture). This
> includes at least the way that the cmd.exe shell is spawned
and/or
Show quoted text
> initialized, and the value of the CPU environment variable. The
> build
> log snippet implies that something is trying to build 64-bit code
> (the
> "obj/AMD64" in the path to libecho), but I note that the README
> instructions start off by building the 32-bit code. (It's okay
to
Show quoted text
> just
> build the 64-bit code and not the 32-bit code for local testing;
> the
> 32-bit build is included in the instructions there so that the
32-
Show quoted text
> bit
> libraries can be included in the 64-bit MSI installer.)
>
> Separately, sometimes the source of the perl binary can be
> relevant --
> do you have Strawberry Perl, ActiveState Perl, or something else?
>
>
From: Hong Ye <hy93@cornell.edu>
To: "rt-comment@krbdev.mit.edu" <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #8672] KFW 4.1 credential cache issue
Date: Thu, 3 May 2018 18:33:32 +0000
RT-Send-Cc:
Thanks Ben. Finally I built it successfully on a Windows 2008 R2 server. The latest release of strawberry Perl doesn't work. I have to use a version released in 2016. Also after install visual studio 2010 professional , I also need to install visual studio 2010 SP1 to get rid of a link error.

Now could you tell me how to enable the debug log? I might need to add debugging log in the source code, do you have a function for logging?

Thanks,
Hong

On 5/1/18, 6:38 AM, "Benjamin Kaduk via RT" <rt-comment@krbdev.mit.edu> wrote:

I don't have that configuration on the machine in front of me, but from
memory, it was Windows 7 Enterprise (I used the subsystem for unix
applications to get awk/sed, but I understand the SUA was removed in a
later release), Visual Studio 2010 Professional, Strawberry Perl, and
Windows SDK 7.1. (The perl 5.12.4 version you cite below seems a
rather old version, though I don't know for sure that that version is
old enough to cause problems.)

-Ben


[hy93@cornell.edu - Mon Apr 30 13:11:42 2018]:

Show quoted text
> I first used Strawberry perl, it gave me error when doing nmake -f
> Makefile.in prep-windows . Then I used ActivateState perl, it
> generated error when doing nmake.
>
> What is the build environment that you can successfully build KFW
4.1?
Show quoted text
>
> Hong
>
>
> On 4/29/18, 10:13 AM, "Benjamin Kaduk via RT" <rt-
> comment@krbdev.mit.edu> wrote:
>
> [hy93@cornell.edu - Thu Apr 26 09:25:58 2018]:
>
> > Thanks for your reply. I followed the instruction from the
> README in
> > the source of the tarball. Here is my build environment:
> >
> > Windows 2012 R2
> > Microsoft visual studio 12.0
> > Windows SDK 8
> > Perl 5.12.4
>
> I don't have a whole lot of experience with VS 2013 (or access to
> such
> a setup at the moment), but one common source of trouble is
> ensuring
> that all the moving pieces agree on whether 32- or 64-bit code is
> being
> built (and potentially also what processor architecture). This
> includes at least the way that the cmd.exe shell is spawned
and/or
Show quoted text
> initialized, and the value of the CPU environment variable. The
> build
> log snippet implies that something is trying to build 64-bit code
> (the
> "obj/AMD64" in the path to libecho), but I note that the README
> instructions start off by building the 32-bit code. (It's okay
to
Show quoted text
> just
> build the 64-bit code and not the 32-bit code for local testing;
> the
> 32-bit build is included in the instructions there so that the
32-
Show quoted text
> bit
> libraries can be included in the 64-bit MSI installer.)
>
> Separately, sometimes the source of the perl binary can be
> relevant --
> do you have Strawberry Perl, ActiveState Perl, or something else?
>
>




If you set the environment variable KRB5_TRACE to a filename, trace
logging information will be written to that file.

I expect to push some patches to the master branch some time this week
which should fix the Perl problem you ran into, and most likely the
linker error (assuming it was when linking Leash), among other issues.
From: Hong Ye <hy93@cornell.edu>
To: "rt-comment@krbdev.mit.edu" <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #8672] KFW 4.1 credential cache issue
Date: Tue, 8 May 2018 15:45:23 +0000
RT-Send-Cc:
I set the environment variable KRB5_TRACE. But only the log from MIT Kerberos application showed up in the log. Our IIS extension call Kerberos library function krb5_cc_initialize. In krb5_cc_initialize , it calls TRACE_CC_INIT. But I didn't see anything in the request when this function was called. Could you help?

Thanks,
Hong

On 5/6/18, 5:58 PM, "Greg Hudson via RT" <rt-comment@krbdev.mit.edu> wrote:

If you set the environment variable KRB5_TRACE to a filename, trace
logging information will be written to that file.

I expect to push some patches to the master branch some time this week
which should fix the Perl problem you ran into, and most likely the
linker error (assuming it was when linking Leash), among other issues.


From: Hong Ye <hy93@cornell.edu>
To: "rt-comment@krbdev.mit.edu" <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #8672] KFW 4.1 credential cache issue
Date: Tue, 8 May 2018 15:53:45 +0000
RT-Send-Cc:
Never mind. It was log file permission issue.

On 5/8/18, 11:45 AM, "Hong Ye" <hy93@cornell.edu> wrote:

I set the environment variable KRB5_TRACE. But only the log from MIT Kerberos application showed up in the log. Our IIS extension call Kerberos library function krb5_cc_initialize. In krb5_cc_initialize , it calls TRACE_CC_INIT. But I didn't see anything in the request when this function was called. Could you help?

Thanks,
Hong

On 5/6/18, 5:58 PM, "Greg Hudson via RT" <rt-comment@krbdev.mit.edu> wrote:

If you set the environment variable KRB5_TRACE to a filename, trace
logging information will be written to that file.

I expect to push some patches to the master branch some time this week
which should fix the Perl problem you ran into, and most likely the
linker error (assuming it was when linking Leash), among other issues.




From: Hong Ye <hy93@cornell.edu>
To: Greg Hudson via RT <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #8672] KFW 4.1 credential cache issue
Date: Wed, 9 May 2018 16:07:04 +0000
RT-Send-Cc:
Download (untitled) / with headers
text/plain 4.8KiB
Download (untitled) / with headers
text/html 10.1KiB

Hello,

 

I had the trace now. Our code is simply doing

code = krb5_init_context(&priv->ctx);

code = krb5_cc_resolve(priv->ctx, cache_name, &priv->cache);

code = gss_krb5_ccache_name(&minor_status, cache_name, NULL);

code = krb5_cc_initialize(priv->ctx, priv->cache, creds.client);

code = gss_init_sec_context(&minor_status, delegate_cred, &priv->ctx,

                                target_name, (gss_OID) gss_mech_krb5, (delegate?GSS_C_DELEG_FLAG:0), GSS_C_INDEFINITE,

                                GSS_C_NO_CHANNEL_BINDINGS, GSS_C_NO_BUFFER, &actual_mech,

                                &priv->buf, &avail_services, NULL);

 

Sometimes gss_init_sec_context called failed with error “No Credentials cache found”.

 

Here is the Kerberos trace when it worked. When the “No credentials cache found” error occurred, the whole block in red was missing in the trace. Any idea?

[2736] 1525805800.352010: Getting initial credentials for http-external/webauthtest.security.cucloud.net@CIT.CORNELL.EDU

[2736] 1525805800.352011: Looked up etypes in keytab: aes256-cts, aes128-cts

[2736] 1525805800.352013: Sending request (215 bytes) to CIT.CORNELL.EDU

[2736] 1525805800.352014: Resolving hostname kerberos.test.login.cornell.edu

[2736] 1525805800.352015: Sending initial UDP request to dgram 132.236.200.162:88

[2736] 1525805800.368000: Received answer (903 bytes) from dgram 132.236.200.162:88

[2736] 1525805802.55000: Response was not from master KDC

[2736] 1525805802.55001: Processing preauth types: 19

[2736] 1525805802.55002: Selected etype info: etype aes256-cts, salt "CIT.CORNELL.EDUhttp-externalwebauthtest.security.cucloud.net", params ""

[2736] 1525805802.55003: Produced preauth for next request: (empty)

[2736] 1525805802.55004: Getting AS key, salt "CIT.CORNELL.EDUhttp-externalwebauthtest.security.cucloud.net", params ""

[2736] 1525805802.55005: Retrieving http-external/webauthtest.security.cucloud.net@CIT.CORNELL.EDU from FILE:c:\cuwebauth64\http-external.webauthtest.security.cucloud.net.keytab (vno 0, enctype aes256-cts) with result: 0/Success

[2736] 1525805802.55006: AS key obtained from gak_fct: aes256-cts/0F3F

[2736] 1525805802.55007: Decrypted AS reply; session key is: aes256-cts/F497

[2736] 1525805802.55008: FAST negotiation: available

[2736] 1525805802.55009: Storing http-external/webauthtest.security.cucloud.net@CIT.CORNELL.EDU -> krbtgt/CIT.CORNELL.EDU@CIT.CORNELL.EDU in MEMORY:CUWAkutilDD4

[2736] 1525805802.55013: Getting credentials http-external/webauthtest.security.cucloud.net@CIT.CORNELL.EDU -> permitd/test@CIT.CORNELL.EDU using ccache MEMORY:CUWAkutilDD4

[2736] 1525805802.55014: Retrieving http-external/webauthtest.security.cucloud.net@CIT.CORNELL.EDU -> permitd/test@CIT.CORNELL.EDU from MEMORY:CUWAkutilDD4 with result: -1765328243/Matching credential not found

[2736] 1525805802.55015: Retrieving http-external/webauthtest.security.cucloud.net@CIT.CORNELL.EDU -> krbtgt/CIT.CORNELL.EDU@CIT.CORNELL.EDU from MEMORY:CUWAkutilDD4 with result: 0/Success

[2736] 1525805802.55016: Starting with TGT for client realm: http-external/webauthtest.security.cucloud.net@CIT.CORNELL.EDU -> krbtgt/CIT.CORNELL.EDU@CIT.CORNELL.EDU

[2736] 1525805802.55017: Requesting tickets for permitd/test@CIT.CORNELL.EDU, referrals on

[2736] 1525805802.55018: Generated subkey for TGS request: aes256-cts/FFCF

[2736] 1525805802.55019: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts

[2736] 1525805802.55021: Encoding request body and padata into FAST request

[2736] 1525805802.55022: Sending request (1029 bytes) to CIT.CORNELL.EDU

[2736] 1525805802.55023: Resolving hostname kerberos.test.login.cornell.edu

[2736] 1525805802.55024: Sending initial UDP request to dgram 132.236.200.162:88

[2736] 1525805802.71000: Received answer (1036 bytes) from dgram 132.236.200.162:88

[2736] 1525805803.759000: Response was not from master KDC

[2736] 1525805803.759001: Decoding FAST response

[2736] 1525805803.759002: FAST reply key: aes256-cts/D871

[2736] 1525805803.759003: TGS reply is for http-external/webauthtest.security.cucloud.net@CIT.CORNELL.EDU -> permitd/test@CIT.CORNELL.EDU with session key des3-cbc-sha1/28A7

[2736] 1525805803.759004: TGS request result: 0/Success

[2736] 1525805803.759005: Received creds for desired service permitd/test@CIT.CORNELL.EDU

[2736] 1525805803.759006: Storing http-external/webauthtest.security.cucloud.net@CIT.CORNELL.EDU -> permitd/test@CIT.CORNELL.EDU in MEMORY:CUWAkutilDD4

[2736] 1525805803.759008: Creating authenticator for http-external/webauthtest.security.cucloud.net@CIT.CORNELL.EDU -> permitd/test@CIT.CORNELL.EDU, seqnum 574934456, subkey des3-cbc-sha1/C958, session key des3-cbc-sha1/28A7

[2736] 1525805803.790000: Destroying ccache MEMORY:CUWAkutilDD4

 

Thanks,

Hong

From: Hong Ye <hy93@cornell.edu>
To: Greg Hudson via RT <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #8672] KFW 4.1 credential cache issue
Date: Fri, 11 May 2018 16:59:49 +0000
RT-Send-Cc:
Download (untitled) / with headers
text/plain 12.2KiB

Message body is not shown because it is too large.

Because gss_init_sec_context() is passed a claimant credential object
(delegate_cred), it uses the ccache associated with that credential
object, not the default ccache as set by gss_krb5_ccache_name().
From: Hong Ye <hy93@cornell.edu>
To: "rt-comment@krbdev.mit.edu" <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #8672] KFW 4.1 credential cache issue
Date: Fri, 11 May 2018 17:49:54 +0000
RT-Send-Cc:
In my test cases, the value of delegate_cred is always null. I confirmed that in our log

[Fri May 11 09:34:40 2018] 10.94.4.17 5036|1144 kutil.c(1177),87C31F2EFF386F52,|7|cuwa.cred|init_sec_ctx: delegate cred = 0000000000000000
[Fri May 11 09:34:40 2018] 10.94.4.8 5036|880 kutil.c(1177),EB379309A62A546F,|7|cuwa.cred|init_sec_ctx: delegate cred = 0000000000000000

On 5/11/18, 1:30 PM, "Greg Hudson via RT" <rt-comment@krbdev.mit.edu> wrote:

Because gss_init_sec_context() is passed a claimant credential object
(delegate_cred), it uses the ccache associated with that credential
object, not the default ccache as set by gss_krb5_ccache_name().


The only way I can think of for one thread to get another thread's GSS
ccache name is if the sources were built without thread support, which
seems unlikely. I verified that a default build under Windows does
include thread support (as I expected), both through code inspection
and through looking at the preprocessor output of
util/support/threads.c.

Since that theory seems unlikely, I don't have any useful ideas; you
may need to add more instrumentation to make things clearer.
From: Hong Ye <hy93@cornell.edu>
To: "rt-comment@krbdev.mit.edu" <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #8672] KFW 4.1 credential cache issue
Date: Thu, 31 May 2018 16:11:15 +0000
RT-Send-Cc:
Hi Greg,

Any update on this issue? We have the same code in a module developed for Apache on Linux and never had any issue.

Thanks,
Hong

On 5/11/18, 1:49 PM, "Hong Ye" <hy93@cornell.edu> wrote:

In my test cases, the value of delegate_cred is always null. I confirmed that in our log

[Fri May 11 09:34:40 2018] 10.94.4.17 5036|1144 kutil.c(1177),87C31F2EFF386F52,|7|cuwa.cred|init_sec_ctx: delegate cred = 0000000000000000
[Fri May 11 09:34:40 2018] 10.94.4.8 5036|880 kutil.c(1177),EB379309A62A546F,|7|cuwa.cred|init_sec_ctx: delegate cred = 0000000000000000

On 5/11/18, 1:30 PM, "Greg Hudson via RT" <rt-comment@krbdev.mit.edu> wrote:

Because gss_init_sec_context() is passed a claimant credential object
(delegate_cred), it uses the ccache associated with that credential
object, not the default ccache as set by gss_krb5_ccache_name().




You responded to my note of May 11. On May 13 I wrote:

The only way I can think of for one thread to get another thread's
GSS ccache name is if the sources were built without thread
support, which seems unlikely. I verified that a default build
under Windows does include thread support (as I expected), both
through code inspection and through looking at the preprocessor
output of util/support/threads.c.

Since that theory seems unlikely, I don't have any useful ideas;
you may need to add more instrumentation to make things clearer.