Find logged-in domain user 2

[guitarzan]

I have an ASP intranet application that currently uses anonymous authentication, and has a login screen that verifies user info from a database. All is fine.

I'm making some changes to this program, and as a result, users will be jumping in and out of the application constantly, closing and reopening it many times a day. So, I want to eliminate all login screens. Instead, I want the program to determine which Windows domain user account the user is logged in as, and take appropriate action from there.

At first, I thought disabling Anonymous access and enabling "Integrated Windows Authentication" would work, and it DOES set the "AUTH_USER" servervarialbes to the info I need. But when I access the application, I get a windows authentication screen, which I don't want. (it only asks you to authenticate once, but still, I dont want any extra login screens).

Then I put Ananymous access back, but all the ServerVariables I tried (AUTH_USER, REMOTE_USER, LOGON_USER, etc). returned blanks.

Is there a scenario where I can get all that I am looking for?

 

[jontout]

Is your dev box a domain member, have you tried renewing the IP address? Is the user a domain member?

What gets returned when you echo Request.ServerVariables ("LOGON_USER") is it blank or null?

 

[guitarzan]

Thanks for the reply, jontout. Domain controller is SBS 2008. Server with the asp site is Server 2003 / IIS 6, and is joined to the domain. The 2003 box is also a Terminal Server, and has no problem accessing resources over the domain. IP is obtained from the DC via a DHCP reservation. All users are logged onto the domain when accessing this site.

I'm using this code to look at the server variables to test the configurations:

response.write _
	" AUTH_USER=" & Request.ServerVariables("AUTH_USER") & "<BR>" & _
	" AUTH_TYPE=" & Request.ServerVariables("AUTH_TYPE") & "<BR>" & _
	" LOGON_USER=" & Request.ServerVariables("LOGON_USER") & "<BR>" & _
	" REMOTE_USER=" & Request.ServerVariables("REMOTE_USER")
response.end

With anonymous access, everything is blank, which I understand is by design... so, if I wanted to use anonymous access, I would need another way of retrieving the user's name or id.

With "anonymous access" unchecked and "Integrated Windows authentication" checked, I get the windows authentication dialog box, asking for a username and password. If I enter a domain username/password, I can access the site and the results of the code are what I want:

AUTH_USER=MYDOMAIN\user1
AUTH_TYPE=Negotiate
LOGON_USER=MYDOMAIN\user1
REMOTE_USER=MYDOMAIN\user1

But when I close internet explorer, then go back, I get the authentication dialog again. Same behavior if I'm logged in as a Domain Admin.

 

[foxbox]

at the moment i cannot check the settings on our IIS/ TS servers, but we solved this. Somewhere you can tell windows that it tries to connect to another server by using the logged on user credentials (i'm no MCSE). i believe you have 3 different settings for this.
It is not in IIS.

 

[guitarzan]

Foxbox,

Thanks for the clue! I was able to find this page:

http://forums.asp.net/t/371553.aspx

By default, IE will only submit the user's current logged on credentials in an intranet zone. This is customizable behavior that can be set in Tools > Internet Options > Security > Custom Level. The reason that you are now seeing the prompt is because the production site is not recognized as an intranet zone. You can fix this in 2 ways:

1.) You can set this site as an intranet site using Tools > Internet Options > Security, Select Local Intranet, click the Sites... button, click Advanced and add it under that dialog.

-OR -

2.) Goto Tools > Internet Options > Security > Custom Level > User Authentication, and select "Automatic logon with current username and password".

If you need to deploy this to a large # of client browsers, you might consider scripting it, or prepopulating the necessary registry keys and distributing it.

I tried both methods, with anonymous off and windows authentication on, and they both work in IE. Is this the setting you were referring to? I would prefer not to hve to make this change to user's browsers, but I suppose I could write a GPO to do this.

 

[foxbox]

Yes. Although we have added our intranet to TRUSTED sites.

Tools > Internet Options > Security, TRUSTED SITES, click the Sites... button

but i expect that to result in the same effect.

 

[guitarzan]

foxbox,
Thanks for the nudge in the right direction

 

[guitarzan]

Actually, I need a bit more help, any opinions are welcome... Of the three possible solutions, I'm having slightly different results with each:

If I add the site (

http://192.168.2.3)

to my "Local Intranet" sites, my original problem is solved. HOWEVER, when I browse to any share on that server using windows explorer and double-click an Access database (.MDB), I get a message "Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.". I even explicitly added myself to the the ACL list, with full permissions... same message when opening an MDB. If I remove

http://192.168.2.3

from my "Local Intranet" sites, I can open .MDB's on the server (but my original problem is back).

If I add the site to my "Trusted Sites" list, my original problem still exists, and I cannot open .MDB's. Double-whammy.

Finally, if I go to Tools > Internet Options > Security > Custom Level > User Authentication, and change Logon to "Automatic logon with current username and password" (instead of "Automatic logon only in Intranet Zone"), both my original problem are solved and I can open .MDB's on that server. But this would need to be rolled out to many workstations, plus the terminal server... I wonder if there are any negative security implications to this setting?

 

[foxbox]

you added YOURSELF. but most probably that access is done via de webserver I_USR user. . . .????

 

[guitarzan]

Not sure what you mean... 192.168.2.3 is a terminal server that is running IIS and hosting the intranet site, and yes, most users (not all) access the site from the terminal server.

But all my tests so far have been from a workstation joined to the domain (192.168.2.11).

 

[jontout]

Guitarzan, my first step would be to try to connect to the server via Explorer - type in \\192.168.2.11\c$ or whichever location the .mdb files are located and see if you have problems opening them.

 

[foxbox]

If you are logged on as domain\guitarzan and run a script on server YOURSERVER, you are accessing the file system as user IUSR_YOURSERVER and **not** as domain\guitarzan

 

[guitarzan]

Thnks for the patience, sorry if im missing something:

jontout: my workstation is 192.168.2.11. when I browse from there to the server \\192.168.2.3\c$\etc and open an MDB file in Access by double-clicking it, I am fine... unless I add 192.168.2.3 to my trusted sites or intranet sites... then I cannot open the MDB in Access by double-clicking it. Instead, i get the error "Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item."

foxbox:

If you are logged on as domain\guitarzan and run a script on server YOURSERVER, you are accessing the file system as user IUSR_YOURSERVER and **not** as domain\guitarzan

Correct me if I'm wrong, but this is only true if my site is using "anonymous access". If uncheck that, and check "Integrated Windows Authentication" (which is what I am doing now), then it should in fact be using domain\guitarzan, not IUSR_YOURSERVER, to execute the script. And in fact, this works if I add 192.168.2.3 to my intranet sites! but doing so prevents me from opening an MDB file in MS Access, which is what has me puzzled.

 

[foxbox]

you checked all the NTFS right? you know of course that Access need rigths for a temp folder?
looks like we need a MVP from the IIS forum....

 

[guitarzan]

Oooookay, got it sorted I think:

So originally, my site would not use windows authentication (without prompting for username/password, anyway). But I could open MDB's from \\servername\c$\etc. NTFS permissions were fine.

Adding

http://192.168.2.3

to my intranet sites fixed the windows authentication issue, but blocked some things (including opening MDB's)

Also adding \\192.168.2.3 (which shows up as file://192.168.2.3) to my intranet sites fixed the MDB issue.

Thanks for the help!

 

[guitarzan]

... and through experimenting, I see that if you put the FQDN (as in

http://mysite.domain.local)

into the intranet zone, that solves all problems in one shot.