[30128] in Kerberos
Re: SSO
daemon@ATHENA.MIT.EDU (Michael B Allen)
Fri Jul 18 11:59:31 2008
Message-ID: <78c6bd860807180858x2f1bb4e4hb73937bf0d6e1d2b@mail.gmail.com>
Date: Fri, 18 Jul 2008 11:58:31 -0400
From: "Michael B Allen" <ioplex@gmail.com>
To: "=?ISO-8859-1?Q?Michael_Str=F6der?=" <michael@stroeder.com>
In-Reply-To: <ofa6l5-70c.ln1@nb2.stroeder.com>
MIME-Version: 1.0
Content-Disposition: inline
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="iso-8859-1"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Fri, Jul 18, 2008 at 7:13 AM, Michael Ströder <michael@stroeder.com> wrote:
> Michael B Allen wrote:
>> On Thu, Jul 17, 2008 at 6:46 PM, Russ Allbery <rra@stanford.edu> wrote:
>>>> And that is the scenario where direct SPNEGO / NTLMSSP solutions are
>>>> going to perform better.
>>> If by "better" you mean "pretty much the same," yes, modulo the
>>> configuration note that I mentioned.
>>
>> No, I definitely meant "better".
>>
>> With direct SPNEGO we 401 the initial HTTP request, accept one GSSAPI
>> token and get a TGT.
>
> Is the TGT sent by the browser in the SPNEGO blob? Up to now I thought
> it's just a service ticket.
Yes, the relevant SPNEGO token is basically a wrapped AP-REQ wihch is
composed of a service ticket and an authenticator. I believe the TGT
or what is used to build a TGT is in the authenticator (at least
that's what WireShark calls it). Incidentally the encrypted part of
the service ticket contains the authorization data (the PAC if it was
issued by AD) which I assume is combined with the TGT data in the
authenticator to build a TGT with authorization data. Otherwise it
would have to dupe that data and the size of blobs in the SPNEGO token
doesn't represent that.
Mike
--
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
