Classic ASP Request.ServerVariables("LOGON_USER") returning wrong username

Question

Hi,

Classic ASP Request.ServerVariables("LOGON_USER") is returning wrong username. Here is the scenario:

I have two accounts on the domain, one for administration and one for normal use. The admin account is set as admin (in the Administrators group) on the server where the ASP script is running on. Server is Windows 2003 running IIS 6.0.

I log in to my machine with my normal user account and go to the page and it is returning my admin account user name. Why is this happening ? This works fine for others.

<%
Response.Write "LOGON_USER: " & Request.ServerVariables("LOGON_USER") & "<br>"
Response.Write "REMOTE_USER: " & Request.ServerVariables("REMOTE_USER") & "<br>"
Response.Write "AUTH_USER: " & Request.ServerVariables("AUTH_USER") & "<br>"
Response.Write "<br>"
'Show all server variables
For Each Item In Request.ServerVariables
Response.Write Item & " = " & Request.ServerVariables(Item) & "<br>"
Next
%>

Anonymous access is off and Windows authentication is on.

Thanks,

Jari

Answer 1

The IIS is probably running under the Admin user and so you are getting that name. Please check it at your side.

Answer 2

According to the MSDN docs on this variable:

The Windows account that the user is impersonating while connected to your Web server. Use REMOTE_USER, UNMAPPED_REMOTE_USER, or AUTH_USER to view the raw user name that is contained in the request header. The only time LOGON_USER holds a different value than these other variables is if you have an authentication filter installed.

Perhaps you have an authentication filter.

Answer 3

I can't explain what you are seeing on the basis of the information so far supplied. I can tell you that the account under which App pool is running is irrelevent.

Classic ASP always impersonates a user either the anonymous user account or the user associated with the connection the request arrives on. Therein may be the clue to your problem.

Authentication in ASP is handled at the connection level, once a connection has been authenticated it is associated with a user. A connection may be kept open by clients and other HTTP devices downstream. All subsequent requests arriving on the connection will not need re-authentication, the current user associated with the connection is used to provide the user context that the thread processing the request impersonates.

I've seen intermedatory devices or debugging proxies (such as fiddler) maintain connections and re-use them for subsequent request from a variety of clients. In this situation its possible to have a client running in one user context to have a request processed by the Web server under a different user's context. Nasty!

I've seen the same sort of thing on older Citrix Terminal servers. HTTP connections were shared by multiple clients running on the terminal server resulting in cross-over of security context. Ouch!

Another variation for this is where access of a resource on a server is rejected for the current user on the intranet. The browser displays a Net logon dialog and the user enters an Admin user. For the duration of the session the browser now uses the Admin user logon credentials to access other resources on that same server even though the current logged on user would do.