The problem here is that ASP will impersonate the authenticated user and there isn't an easy way to make it behave differently.

About the only way i can think of would be to write a COM component that actually handles putting the uploaded file on the remote file share, put it in a server package in COM+ and configure it to run as whatever user you want it to be.

This way you can still scrape the user's credentials but the actual access of the remote file system would be done using the COM components credentials.

Dave Dietz

I found the following link in Microsoft site.
I'm not sure if that's the information you are looking for but you can check it out.
http://support.microsoft.com/kb/154501

Hi,

Microsoft seems to indicate that it is possible to access remote content as a specified user account:

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/8a0e917a-795c-49b7-8896-f46291b289d6.mspx?mfr=true

Key quote:

"If you want IIS to use a specific user when accessing remote content, set the UNCUsername and UNCPassword properties in the IIS metabase. For information about setting these properties, see the UNCUserName Metabase Property and the UNCPassword Metabase Property."

Now, the script itself is probably running under the client user's context, but does the file access happen under the account that the script is under? In other words, there is no way to get the UNCUsername to work for files created by an ASP script?

The file server is seeing a null session, so I can tell that IIS is trying to delegate the user's account for the file access (see http://www.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsDelegation.html for a very good description of delegation).

Here's another good URL I looked at that also indicates that delegation can be disabled:

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/remstorg.mspx#EFIAC

It's not that I don't trust you Dave, I just want to be sure ;)

The documentation you found is for things like virtual directories where IIS is what is accessing them.  When you start using an ISAPI extension (such as asp.dll) the rules change a bit.

If your script is saving the files to a relative path (/savedfiles or /vdir1/stuff) then it will likely end up using the UNCUserName and UNCPassword values.  If it is using a physical path (c:\files\saved or \\fileserver\share) or the results of Server.MapPath then it is making its own connection and will use the credentials of whatever account it is impersonating.

Dave Dietz

Thanks for the quick response.

Is there some way I can use a virtual directory to point to the remote share? I tried it, configured with the static username that I want to use, and it didn't seem to work.

Virtual directory code:

Set oFile = oFS.CreateTextFile(server.mappath("/UserFiles") & "\" & strSaveFile, True)

Non-virtual directory code:

Set oFile = oFS.CreateTextFile("\\geofiles\UserFiles\" & strSaveFile, True)

These two code samples are functionally the same.  The server.mappath in the first sample will give you the same thing you hard code in the second sample.

It *might* work if you tried this:
Set oFile = oFS.CreateTextFile("/UserFiles" & "/" & strSaveFile, True)

I am not at all positive this would work but if it did it would likely end up using the UNCUsernName and UNCUserPass to access the remote location.

Give it a whirl and let us know if it works.

Dave Dietz

Hi Dave,

I'm getting a "path not found" error with the following:

Set oFile = oFS.CreateTextFile("../../UserFiles" & "/" & strSaveFile, True)

The script that this is run from is at http://webserver/testbed/custom/fileupload.asp.
The virtual directory is at http://webserver/UserFiles.

Is my syntax incorrect?

Note that I also tried setting the app pool identity to a domain account that has remote access permissions for the file server, but now any credentials I enter fail when I try to access the fileupload.asp page. Any idea why changing the app pool identity would prevent authentication to the file upload page?

This explained the cause of the above credential failure problem:

 http://support.microsoft.com/kb/871179/en-us

I disabled Kerberos authentication, to just use NTLM, and the credentials passed but I still got a "permission denied" error when accessing the remote server.  So changing the app pool context didn't resolve the issue.

I think the problem with the path is that the filesystem object needs a physical path and doesn't understand virtual directories.

Changing the app pool identity won't make a difference since the ASP script is impersonating the logged on user.  Additionally, using NTLM the user's credentials cannot be passed to a different machine.

Dave Dietz

-----------
 Additionally, using NTLM the user's credentials cannot be passed to a different machine.
-----------

You're correct, but that's what I don't want to do. I just want the remote file access to be done with UNCUserName. I don't want any pass-through delegation or anything like that. Microsoft seems to say that all I have to do is specify UNCUserName in the metabase and it will override the client user name (see Figure 6 of http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/remstorg.mspx ).

I just cannot figure out why this isn't the case.

For some extra details, this is the configuration I have for the file upload page in the Metabase Explorer:

KeyType: IIsWebFile
UNCUserName: mydomain\MyDomainAccount
UNCPassword: mypassword
AuthFlags: 4
WAMUserName: mydomain\MyDomainAccount
WAMUserPass: mypassword

Is this the correct way to specify UNCUserName?

-------
If you were to try browsing directly to this location the access would take place as the specified UNC user.  Since you are accessing the UNC path with the filesystem object it completely bypasses the IIS configuration for the UNC.
-------

I see! This makes sense. it was driving me crazy why what Microsoft was saying in many different documents (that UNCUserName overrides the authenticated user credentials for remote file access) didn't seem to jive with what I was experiencing. I suppose this is what you've been trying to tell me all along, though.

So, when I specify the following for the uploadfile.asp page:

UNCUserName: mydomain\MyDomainAccount
UNCPassword: mypassword

This mean that the UNCUserName will only apply to the script when the user accesses the script over a UNC path, correct? I was originally under the impression that defining the UNCUserName and UNCPassword for a script set the credentials that are used when an object accesses remote content over a UNC, but I'm starting to realize that instead it sets the credentials to use when accessing THAT object over a UNC.

I think we're on the same brainwave now Dave, because (if I understand you correctly) you're suggesting that I have the user access the script over a UNC path. I'll play with this idea some when I get to work. I'm guessing that this means I'll need to put the script in the file server's share and access it through a virtual directory, which wouldn't be a problem.

I'll get back with the results.

>This mean that the UNCUserName will only apply to the script when
>the user accesses the script over a UNC path, correct?

Yes.  :-)  The UNCUserName and UNCPassword apply to all access made via that virtual directory.

By putting the script in the virtual directory that would mean any access of the script would end up using the UNCUsername and UNCPassword.

I am curious now to hear your results.

Dave Dietz

Sorry, it was a while before I had a chance to try it out.

After all of this time I never thought there would be a simple way to do what I wanted to do, but it works perfectly! Here's what I did:

* Created a new virtual directory called "Scripts".
* I pointed the virtual directory to the file directory on the web server that contains the same old ASP script I was using before, except now I used a UNC path, tricking IIS into thinking that I am referring to a remote share.
* The virtual directory was configured with the UNCUserName and UNCPassword of the static domain account I was trying to use (the variables are set transparently through the options in the properties window for the share... meaning I didn't edit the metabase manually).
* Disabled anonymous access on the virtual directory and enabled Windows Integrated Authentication.

The LOGON_USER request variable contains the domain username of the client, but the script runs under the static domain account, exactly as I wanted it to.

I appreciate you hanging in there with me Dave.

File Server Shared Folders
The default share permission for shares is Everyone Read. If you're using IIS as a publishing server (WebDAV, Microsoft FrontPage®, FTP, etc.) and the file server is the back end, you'll need to set permissions for share and NTFS sufficient to allow writing to the resource. Share permissions should be Change or Full Control, and will require the Modify Write permissions for these applications to work correctly. The specific settings required are dependent on how you implement publishing.

To set share permissions
1.
 Right-click on the folder you want to share.
 
2.
 Select Sharing and Security.
 
3.
 Select the Sharing tab (set ShareName and Comment as appropriate).
 
4.
 Click Permissions.
 
5.
 Remove the Everyone group (if it exists); this may allow unexpected access.
 
6.
 Add the appropriate User or Group (Authenticated Users is a good choice) that should have access to the share. For delegated access, this will typically be Domain groups or users. It is recommended that you use groups to control access to local resources.
 
7.
 Give this user or group the minimum permissions required to access the content. Read is the least share privilege allowed. If this location is to be used for FrontPage publishing, Change or Full Control permissions may be required.
 

To set NTFS permissions
Important: Be careful when editing any of the default NTFS ACL settings; you'll need to make sure the administrators can still control the file content.

1.
 Right-click on the folder or file you want to secure.
 
2.
 Select Sharing and Security.
 
3.
 Select the Security tab.
 
4.
 Click the Add button.
 
5.
 Type in the name of the domain user or group that you want to have access to this resource, and then click OK. The default NTFS settings apply only to local accounts on the server. Domain users must be explicitly allowed appropriate access.
 
6.
 Verify that the Allow checkboxes are set to permit minimum access. (For IIS to retrieve content, it needs only Read access to be checked.)
 

Note: Unchecking Allow List Folder Contents does not disable IIS Directory Browsing in IIS Manager. Unchecking Allow Read and Execute does not disable IIS Script or Execute permission in IIS Manager.

In some environments, such as a shared hosting provider, it is common to leave the share permissions reasonably open and rely on NTFS permissions to control security. Remember that share and NTFS permissions combine to provide the least privilege allowed by both. Regardless of how you choose to integrate share and NTFS permissions, be certain they are set up corr