[29510] in Kerberos
Re: SPNEGO NTLM / Kerberos over HTTP (aka RFC4559) confusion
daemon@ATHENA.MIT.EDU (Michael B Allen)
Tue Mar 18 00:59:40 2008
Message-ID: <78c6bd860803172159p4b6e63d7j2cf72b9968126497@mail.gmail.com>
Date: Tue, 18 Mar 2008 00:59:10 -0400
From: "Michael B Allen" <ioplex@gmail.com>
To: kerberos@mit.edu
In-Reply-To: <4afc32ad-f116-48e6-9d09-b267e25d90e7@s50g2000hsb.googlegroups.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On 3/17/08, john@feith.com <john@feith.com> wrote:
> On Mar 17, 9:12 pm, "Michael B Allen" <iop...@gmail.com> wrote:
> > The problem is that the client will not or cannot initiate Kerberos.
>
>
> Nice try, however no. The client has no problems using Kerberos.
> There are credentials in the cache for user. There's no problem
> fetching credentials for the webserver. The problem has specifically
> been traced by Microsoft to a bit of code in the Negotiate SSPI
> which causes a raw NTLM to be returned instead of a SPNEGO
> in some situations even though Kerberos is available / working.
If the HTTP server returns "WWW-Authenticate: NTLM" then the client
must use NTLMSSP tokens. If it returns "WWW-Authenticate: Negotiate"
then the tokens must be SPNEGO. If it returns both, then the client
can pick.
Otherwise, you need to explain the point of failure in more detail. Is
it gss_accept_sec_context that is returning a token you didn't expect,
or InitializeSecurityContext, or what? If you're not sure then provide
an HTTP client / server call sequence w/ headers that illustrates the
point of failure.
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
