Classic ASP Impersonation | Windows authentication | File Access Denied IIS 7

Question

I have a classic ASP/VBScript website (landing page - default.asp) that writes the website user access (LOGON_USER) activity to a simple txt file via the Scripting.FileSystemObject.

VBScript creates an FSO to open/create a new file under the folder 'logs'

Windows 2008 R2 64 bit environment

IIS 7.5 -

• Authentication - Windows Authetication enabled. All other authentication disabled.
• AppPool running in Classic PipeLine mode;
• Enable 32 bit applications set to true;
• Identity is NetworkService.
• Load User Profile set to false
• ASP: executeInMta set to false

ACL for logs folder

• Users group - Read and Execute;
• SYSTEM - Full Control (Inherited);
• Administrators - Full Control (Inherited);
• IIS_IUSRS - Full Control;
• Network Service - Full Control.

This setting yields me a '800A0046 - Permission Denied'. Please note that windows authentication is enabled. And I map the LOGON_USER value to a value in DB to permit a user access my website. AppPool is set to NT Authority\NetworkService. Though the apppool identity is set to NetworkService, after a user autheticates, the files are accesses via the authenticated user (impersonated). Sample Process monitor activity below.

Process Monitor File System Activity

• default.asp - Desired Access - SUCCESS - Impersonation: domainname\username
• logs\log3011.txt - Desired Access - DENIED - Impersonation: domainname\username

Now, this puts me in a situation where I have to go to the security properties of 'logs' folder and grant every permissible user Read/Write permission. What I am looking for is, since my apppool runs as NetworkService(logs folder is given full control for NetworkService), I want the logs folder to be accessed via Network Service and not the user authenticated via windows authentication. I understand that this is the expected result when using Windows authentication. However, I use windows autnetication just to verify if the user is allowed to access the website. I need all other website actitivities to use NT Authority\NetworkService. (I am asking for a solution to stop Classic ASP impersonating the windows authenticated user, and rather use the appool identity - networkservice in my case - to access the resources)

Is that too much to ask for? Please guide me with appropriate explanations. Thx.

Solution 1

Yup. Classic ASP impersonates. Don't know of a way around this that's built in to ASP - you might find StackOverflow more knowledgeable on this, as I'd suggest it's a programming topic.

Your desired model is usually referred to as the "trusted subsystem" model in the ASP.Net Patterns and Practices documentation (from years ago).

In the past, I've used an ASP.net page with to do the writing, called via WinHTTP from an ASP page; using a COM object with its own identity specified is the other alternative. You could (as easily) convert the page to ASP.Net, and just use that with impersonation off. And then there's the "call RevertToSelf()" option, which forgets your thread identity; you may need a COM object to do that for your thread as well, from memory again.

Edit: Or use a database that runs as a different identity; the file system's only problematic because it's so easy to use!

Also, if the users all write to the same file, the "write to a log" scheme isn't viable when multiple users access it concurrently, and it'll at best introduce a delay in that scenario.

If each user only needs to write to their own log (and you hope they don't hit refresh too soon while writing to avoid concurrency issues), you might be able to simply grant Write permission to those users to that folder. Without Read, it's a bit useless; without actually attacking the box (it's Windows Integrated so you're on an intranet) it'd be hard for them to accidentally overpopulate the username and DoS the machine.

Solution 2

Verify that you do not have executeinMTA set to true. You verify this in the asp settings of the website.

Comments

[gmaran23]

executeinMTA set to false. I believe false is the default for executeinMTA. I have updated my question too. Thanks.

[raja]

Yes false is the default, setting it to true is a common issue that could cause this

[gmaran23]

ok. anything else that strikes you Jim?

[raja]

the only other thing I can think of that might be (but shouldn't) affect this is ensuring the apppool framework as no manged code. You might try changing to digest authentication

[gmaran23]

I didnt quite understand what you meant by "ensuring the apppool framework as no manged code". The apppool does not contain any managed (.Net) code. but my classic asp calls a COM+ for some other operation. I am yet to try digest autnentication. I am eploring options to get rid of the log file by all means :)

[gmaran23]

I agree with that COM+ option with it's own identity. matter of fact I already have a couple of COM+ and they work seamlessly. your suggesstions are good, I gonna consider using a ASP.net page wth impersonation set to false or a DB table instead.