Negotiate authenticates computer account instead of user

I am using the Tomcat Negotiate Auth Valve with Tomcat 6.0 and have recently ran into an issue where a user was receiving an HTTP 403 using IE 7.0 At this point I set logging level to DEBUG and was surprised to find that he was authenticated via his computer
name (COMPUTERNAME$) and as such obviously lacked the needed roles to gain access.

The user advised me that he was able to log in the day prior and I once again checked the logs and indeed he was properly authenticated via his domain user ID.

Below is the WAFFLE debug log. As you can tell USER1 is first authenticated by NTLM and the second user for some reason is authenticated by his computer account via Negotiate (KRB). Any ideas on how to resolve this? Thanks in advance!

This needs some work. NTLM is a connection-based protocol, so you have two connections going on (probably simultaneously) and both require authentication. Note how Tomcat establishes two separate session IDs, which validates my theory so far.

First, lets trust Waffle and SSPI - the first request is indeed made on behalf of the user and the second request is made on behalf of the local system account on that COMPUTER_NAME.

Is the COMPUTER_NAME authenticated in the second request the server's or the client's computer name?

Dig through the application - find where the second connection is coming from (eg. this is an Ajax call implemented with MS XMLHTTP).

If you own the application, try to debug it and track those two requests. Is there a timing/synchronization problem (could be a waffle bug) where depening how fast the second request comes in the results are different?

First let me clarify that these are two seperate logins. That computer name is the name of the remote client's workstation.
I was actually on-site at the time of this issue and the two users were sitting nearby.
The first session and NTLM request is for an actual user (USER1) who successfully authenticated.

The second session is for a different user (the one with a computer_name$ logon via KRB).
I also checked the Event log and the computer account logon was the only event (event ID 540) that I could find.
So I went over and checked the computer name of the user in question and it was indeed the computer_name$ that we see in the logs.

However, what you say with respect to two connections does appear to be correct in general.
Looking through the security event log, a lot of the time I see authentication for both, computer accounts and user accounts, but some of those are caused by UNC path (SMB) connections.

So am I correct restating the problem: user1 always logs-in as domain\user1, while user2 logs in as domain\user2_computer$? And this is random (aka not consistent - sometimes user2 logs in as domain\user2 and sometimes as domain\user2_computer$)?

User2 advised he was able to login fine the day before (I confirmedi n logs as his userID) and despite several attempts and restarts of IE (closed all windows) it kept authenticating him as user2_computer$.

Further as this is a shared workstation, when the next person on shift arrived and logged in, they were able to log in just fine.

The user however had no problems authenticating to other protected realms, for example I saw him accessing applications using JCIFS without an issue.

I have previously had random reports of user not being able to log-on getting a 403, but this is the first time I was really able to debug it, which leads me to believe that this happens once in a blue moon, but it is not a one off.

I just noticed something that was right there. Look at the first login - it says
NTLM in the header, so the client chose to do NTLM. The second one said
Negotiate in the header, and it looks like a Kerberos token to me (much longer)! So with Kerberos you login as user2_computer$, while with NTLM you're logging in as the user. You should examine other failures to confirm.

This got to be a client-side decision of which ticket to send. Which version of the browser are we looking at here? Same version(s)? I bet you have something on the client or in the domain setup that's telling the browser not to send user's credetials
but to remain "anonymous". I really have no idea how Kerberos works domain-wide, but at least this should narrow down the problem. I would start by checking whether the server has a proper SPN and try to make sure all clients are doing
Kerberos (which will cause failure everywhere I presume :)).

As a last resort you can disable Negotiate in the Waffle settings and just force NTLM and move on with your life :)

That's the quick fix, but it would be nice if you contributed a patch where the list of protocols is made optional in WaffleAuthenticatorBase, with unit tests, doc edit & al. I created a feature request to track this. A great place to start contributing
:)

> From: dblock
>
> That's the quick fix, but it would be nice if you contributed a patch
> where the list of protocols is made optional in
> WaffleAuthenticatorBase, with unit tests, doc edit & al. I created a
> feature request to track this. A great place to start contributing :)
>
>
>