[16493] in Kerberos_V5_Development
Re: X-CACHECONF in cache type 0504
daemon@ATHENA.MIT.EDU (Tim Alsop)
Fri Nov 19 13:37:31 2010
From: Tim Alsop <Tim@cybersafe.com>
To: Tim Alsop <Tim@cybersafe.com>, Greg Hudson <ghudson@mit.edu>
Date: Fri, 19 Nov 2010 17:14:50 +0000
Message-ID: <C90C5FE0.27A3A%Tim.Alsop@CyberSafe.com>
In-Reply-To: <C90C5B23.27A31%Tim.Alsop@CyberSafe.com>
Content-Language: en-US
MIME-Version: 1.0
Cc: "krbdev@MIT.EDU" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Greg,
I used MIT 1.8.1 to get TGT. I captured and analyzed the network traffic
using wireshark, and this is what I found:
AS-REQ send to AD
KRB-ERROR returned, with PREAUTH_REQUIRED. The padata contained
PA-ENCTYPE-INFO, PA-ENC-TIMESTAMP, PA-PK-AS-REP
AS-REQ sent to AD with PA-ENC-TIMESTAMP
AS-REP received from AD.
So, above looks normal. There is no padata seen suggesting that the KDC
supports FAST, but when I look at the ticket cache I see:
[talsop@shrek ~]$ /opt/mitkrb5-1.6.3/bin/klist
Ticket cache: FILE:/tmp/krb5cc_4000
Default principal: talsop@DEV.LOCAL
Valid starting Expires Service principal
11/19/10 17:10:47 11/20/10 03:06:09 krbtgt/DEV.LOCAL@DEV.LOCAL
renew until 11/20/10 17:10:47
01/01/70 01:00:00 01/01/70 01:00:00
krb5_ccache_conf_data/fast_avail/krbtgt\/DEV.LOCAL\@DEV.LOCAL@X-CACHECONF:
Kerberos 4 ticket cache: /tmp/tkt4000
klist: You have no tickets cached
[talsop@shrek ~]$
I therefore conclude that MIT 1.8.1 has a bug. Or, we have compiled it on
our system and something went wrong during the compile/link/install phase
- unlikely, but possible...
Thanks,
Tim
On 19/11/2010 16:50, "Tim Alsop" <Tim@CyberSafe.com> wrote:
>Ok, thanks.
>
>Next I am going to capture data between MIT 1.8.1 kinit and MS AD, to find
>out why this cache entry is being written, when KDC does not support FAST
>
>Tim
>
>On 19/11/2010 16:43, "Greg Hudson" <ghudson@mit.edu> wrote:
>
>>On Fri, 2010-11-19 at 11:27 -0500, Tim Alsop wrote:
>>> Ok, so we can use krb5_ccache_conf_data at the start with the
>>>X-CACHECONF:
>>> as realm, but the data between these two elements can be anything we
>>>want.
>>>
>>> e.g. This is valid and acceptable if found in a cache:
>>> krb5_ccache_conf_data/foo/bar/hello/world@X-CACHECONF:
>>
>>Well, any service principal is valid and acceptable according to the
>>cache format.
>>
>>To work with the Heimdal/MIT krb5_cc_get_config API, the principal must
>>have three components: "krb5_ccache_conf_data", the config key, and the
>>unparsed name of the cache's default client principal.
>>
>>
>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
