Negotiate authenticates computer account instead of user

Oct 29, 2010 at 6:09 PM

Hi I have what seems to me like a rather odd issue.

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!

 

2010-10-28-13:02:30.538-0400

http-80-1

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

GET /INCO/..., contentlength: -1

2010-10-28-13:02:30.538-0400

http-80-1

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

authorization: NTLM TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAAAAABIAAAADgAOAEgAAAAUABQAVgAAAAAAAACaAAAABYKIogUBKAoAAAAPYgBvAHMAYQBpAG4AaQBCAE8AUwBBAEkATgBJAC0ATABUAC+GVX9QgqwHAAAAAAAAAAAAAAAAAAAAAETWRpsNdIxFLcxPXq8xys9Jv0NheA/T+g==, ntlm post: false

2010-10-28-13:02:30.538-0400

http-80-1

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

security package: NTLM, connection id: 10.xx.xx.xx:4993

2010-10-28-13:02:30.538-0400

http-80-1

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

token buffer: 154 byte(s)

2010-10-28-13:02:30.554-0400

http-80-1

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

continue required: false

2010-10-28-13:02:30.616-0400

http-80-1

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

logged in user: DOMAIN\user1(S-1-5....)

2010-10-28-13:02:30.897-0400

http-80-1

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

roles: ...

2010-10-28-13:02:30.897-0400

http-80-1

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

session id:A7AF5B05B7510FD9BD06ABACE46F0BD7

2010-10-28-13:02:30.897-0400

http-80-1

INFO

waffle.apache.NegotiateAuthenticator

?:?

successfully logged in user: DOMAIN\user1

2010-10-28-13:02:38.210-0400

http-80-7

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

GET /INCO/, contentlength: -1

2010-10-28-13:02:38.210-0400

http-80-7

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

authorization: <none>, ntlm post: false

2010-10-28-13:02:38.210-0400

http-80-7

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

authorization required

2010-10-28-13:02:38.241-0400

http-80-7

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

GET /INCO/, contentlength: -1

2010-10-28-13:02:38.241-0400

http-80-7

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

authorization: Negotiate YIIFQAYGKwYBBQUCoIIFNDCCBTCgJDAiBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICCqKCBQYEggUCYIIE/gYJKoZIhvcSAQICAQBuggTtMIIE6aADAgEFoQMCAQ6iBwMFACAAAACjggQPYYIECzCCBAegAwIBBaEJGwdSSU0uTkVUoiMwIaADAgECoRowGBsESFRUUBsQd254NTB5a2YucmltLm5ldKOCA84wggPKoAMCARehAwIBFKKCA7wEggO4sak8WpjrNgrPby5/a6ZNSYFbP1Jth2nh7/IbTQsS51qQGKdwwih6wud0YITZMYTnRQ/dVeis3GfanQAv1cEd1y1dLJAr/C1MgxIWb/R39Schz/WTAFpp5FsuzeslW0KAIbzDnbd9hvxoLYvfHWAVT8IVruxp0rzSLBv8g0Eb3UXjDYs3WYra8wm7GnhYdaIUNQvn4PHzw1OwcOBQJLQuzn8oWkcwOgW6oVuXKzhKpQoGMA9zAke9S9mCMw5sKiqRD6sLM61Ktaa7F9nxxghT7FiHqgP6AT6288Hvm0iaAJ6lrWGZRSBp1HQ4Bb/v0530KwRP2PuQSReyvSfBNQfwD8KByVGiQcMMYDAODZui4FBdoUSUeLuxfhdyRJjTypgBY95j4NuhLjv6inOFlpzkjyHxtEs+SmYrbRvVac51GZfGjoddRDWobUpgefsuFo++SYjY+6BBBz/utk7ytDDwzfAFr0hky+H02zVMHkyDCK6XGrD3rRtSZTY7K6Xs8elgZcVJa2veediFcxuzE64N2lhRHkFrOGHXGRhvE1bdeecmXwkzfhJ8iFgOf7IvXmKzRtTkUxnQJlYwZkDeV4V6Y0BAK25UDfuIFH2z2nsgUO7z2+QuEXC5xCFBEyd5Dj5iWiMf5Tc3ECbquIm4Wt2MBc4oDVtVICC0bZ4Iic4oVU1Ljqn1m/lxs7UIfl6RSqCMw7oH4uV2LCSbKo1RHXSDYUD7TqU8SII66PTWGOwyYtIf6Xbel0UiZBFW8qu3828q0D/xmOOwz6QriDFiI1mCxEjsP9ipIEoMDoKvHeBiFP5kcs8qEaD1cU0ZzOtWBnHKcTD6wf9arjM9wcO274ZtKG19Tj3xQlbdVX/TwHuQxKV6hX2F4g4NeTH8IpVD4maIU0k/nxmwesZjy6iwLtRDXarEPjISu5iuZy9GnmIAdeNoLtu1hZQCRTxcnD8bbA4lqRQrV1Dnl6Avme6KrSAMSlrAELgRVRCaz9NjdcPemE4Zu5tOAdqfF8ke+Buqn7eZqxUZ6EkOKnvf4RcqF1pV77C21IujNjmk8ouQD14EDC1ft957NVHpkpo+kLwJRNc3hlBPFSh+qE2mu9/rcnH8/mCf+x2y6j70DTHFcXyyupjov9kULp8WqBZva9cHXjufGU2WT1SzDLQSnk9Nr4g48ihNa/lgfKQjipudOsF4smo5Gp79K9zH7DCI8YU2Dir8rhxQ35raI3G5ZMeBDh6X123akT4BFwvrlHAN5u1D8Aiptb1tbyZ3UqSBwDCBvaADAgEXooG1BIGy6CckCFaQaD25C9aY+umu/ZeA1ULQfUTcSBbXiDijNNSNy2LWHkhYJbW4ooiFIKK2I7nz7MHvOZFDGddBISy4b5P78Wrg7fUqCh/+XDfaQqaZF30jwQ/FjqNCfLXstOwYRx9WADWFiyP9qN61THLJ5Kk1oc/N/WEcZZVymrAwqtkaYvexVtjxENK6zHcfwhdr3ev8rASg5wX2wGVO/RIvVhz94slu8aOpL1jO4nKxSpyDlA==, ntlm post: false

2010-10-28-13:02:38.241-0400

http-80-7

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

security package: Negotiate, connection id: 10.xx.xx.xx:2173

2010-10-28-13:02:38.241-0400

http-80-7

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

token buffer: 1348 byte(s)

2010-10-28-13:02:38.241-0400

http-80-7

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

continue required: false

2010-10-28-13:02:38.241-0400

http-80-7

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

continue token: oYGgMIGdoAMKAQChCwYJKoZIgvcSAQICooGIBIGFYIGCBgkqhkiG9xIBAgICAG9zMHGgAwIBBaEDAgEPomUwY6ADAgEXolwEWkOHZXcmM9gNF8JGOcmHWrpnFUvX1vRxfjRg+kJUu7nDKrzZkZqDJy7vJbnJtTfhkZTOla1bK5fyuWdYG6okggHAdVX+Glh5ovv2YAvIiY3fjK3eRkqwyI15zw==

2010-10-28-13:02:38.257-0400

http-80-7

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

logged in user: DOMAIN\COMPUTER_NAME$ (S-1-5-....)

2010-10-28-13:02:38.288-0400

http-80-7

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

roles: BUILTIN\Users, Everyone, NT AUTHORITY\Authenticated Users, NT AUTHORITY\NETWORK, NT AUTHORITY\This Organization, DOMAIN\Domain Computers, DOMAIN\COMPUTER_NAME$...

2010-10-28-13:02:38.303-0400

http-80-7

DEBUG

waffle.apache.NegotiateAuthenticator

?:?

session id:AA82617F557CAA6D1EED5C8FBA271242

2010-10-28-13:02:38.303-0400

http-80-7

INFO

waffle.apache.NegotiateAuthenticator

?:?

successfully logged in user: DOMAIN\COMPUTER_NAME$

Coordinator
Oct 29, 2010 at 7:01 PM

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.

  1. Is the COMPUTER_NAME authenticated in the second request the server's or the client's computer name?
  2. Dig through the application - find where the second connection is coming from (eg. this is an Ajax call implemented with MS XMLHTTP).
  3. 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?

 

 

Oct 29, 2010 at 7:35 PM

Hi dblock,

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. 

Coordinator
Oct 29, 2010 at 7:38 PM

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$)?

Oct 29, 2010 at 7:44 PM

Yes user1 has never reported a problem.

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.

Coordinator
Oct 29, 2010 at 7:58 PM

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 :)

Oct 29, 2010 at 8:05 PM
Edited Oct 29, 2010 at 8:15 PM

The browse is IE7.

Just looked at the log for today and most people are using HTTP Negotiate only few are falling back to NTLM, the event log confirms this. I see no consistency! ; (

How do I disable Negotiate? I looked at the chm file but did not find a setting to siable KRB/Negotiate.  am content with using NTLM.

Oct 29, 2010 at 9:59 PM

Do I just comment this out?

 

 protected void sendUnauthorized(Response response) {
  try {
//   response.addHeader("WWW-Authenticate", "Negotiate");
   response.addHeader("WWW-Authenticate", "NTLM");
   response.setHeader("Connection", "close");
   response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
   response.flushBuffer();  
  } catch (IOException e) {
   throw new RuntimeException(e);
  }
  
 }

Coordinator
Oct 29, 2010 at 10:59 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Oct 29, 2010 at 11:00 PM

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 :)

Coordinator
Oct 29, 2010 at 11:02 PM
AndreiK wrote:

Just looked at the log for today and most people are using HTTP Negotiate only few are falling back to NTLM, the event log confirms this. I see no consistency! ; ( 

Look at failed ones only. There should be something in common between them (same protocol, coming from the same set of machines, same versions of browser, etc.).

Oct 29, 2010 at 11:37 PM
Will do.

----- Original Message -----
From: dblock <[email removed]>
Date: Friday, October 29, 2010 7:00 pm
Subject: Re: Negotiate authenticates computer account instead of user [waffle:232821]
To: [email removed]


> 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 :)
>
>
>