I have an asp page that saves a file to disk.
Currently it works locally, but I need to save the file to a share and I get permission denied.
I had assumed I could just set the app pool to the user that has access to the folder, but it doesn't seem to work.
How do you make classic asp run as a specific user?
I believe that by default classic asp will run under the iis user which is IUSR_MachineName. This can be changed in the IIS Manager.
Good references:
http://kb2.adobe.com/cps/153/tn_15378.html
http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=287
IIS Admin - Website Properties - Directory Security - Edit...
By default it's IUSR_MACHINENAME
Look at who is running the following:
"inetinfo.exe" process
"World Wide Web Publishing service"
It should be one of those I believe.
Is the program attempting to go to a share on another computer (or this computer), or a folder on the web server which happens to also be a share? When you access it through the \\server\share notation, you are going to have different issues than through the local drive driveletter:\folder\ notation.
If it is a share on another computer, the account will need to have rights to the share as well as rights to the underlying files and must be a domain account.
It depends on what you are actually doing but you would probably want to avoid giving the whole application a user identity that has network access just to service the needs of this one file.
You can configure in IIS the user identity for anonymous access on that one ASP file, that would be better than setting it for the whole application.
Another option in the intranet environment is to turn off anonymous access for the ASP file and turn on windows integrated access. The clients user account is used for the security context for running the ASP and any subsequent network access it might make.
I've encountered a similar problem : Unable to Execute Bat EXE or CMD.exe from classic ASP pages on IIS 7.
As I have found a solution, I HOPE it will help the folks to save time !
For a solution look there : (I've Marked the very last post as Answer).
http://forums.iis.net/t/1193937.aspx/1?+BAT+and+vbs+Files+does+not+run+anymore+from+Classic+ASP+was+running+on+Win+2003+Server+
Have a great starting 2013 !
Related
I am trying to deploy an asp.net 4 app to a new microsoft server 2008 R2
I have set up the application as I have done dozens of times before and set the folder permissions appropriately.
I have tried setting the application pool name directly to have write permissions
I have tried setting IUSR, IIS_IUSRS, NETWORK SERVICE and Users.
I have confirmed that windows authentication is disabled and anonymous is enabled as well as forms authentication is enabled. Logging in works fine i can access all pages normally except if i try to write to the folder. Then a password is required box pops up which looks like windows authentication (even though its disabled)
Every post here states and in my past experience says if I set the folder permissions for the defaultidentity application pool it should work, but for some reason this server wont let me do it!
Any help would be most appreciated.
Welp this turns out to be a really weird one. For some reason when SQL reporting services is installed it reserves the folder name "Reports" in any IIS Web application folder regardless of whether your actually using Reporting services. Its not created by default or anything, but if you happen to create folder titled "Reports" dont expect to access anything from it. After many hours of frustration it turns out it's a random reservation which doesn't throw any error just somehow overrides your authentication protocol to use windows authentication for their reserved folder.
Thanks Microsoft!
Unfortunately I don't have a whole lot of information on this.
I have a customer who has moved their site from an ancient system to IIS7 on Windows 2008 Server. Info about the error is below:
Error:
E:\wwwroot\sp\xxx\online_data.xls
Microsoft VBScript runtime error '800a0046'
Permission denied
/xxx/oat/exceldata.asp, line 52
Code:
49 response.write(server.mappath("online_data.xls"))
50
51 set fso = createobject("scripting.filesystemobject")
52 Set act = fso.CreateTextFile(server.mappath("online_data.xls"), true)
The only suggestion so far is to:
grant the application pool
(DefaultAppPool / Classic AppPool)’s
impersonated identity read and write
permission to the physical folder
which the asp page reside
Will look at this when I get access, but other suggestions would be appreciated.
The provided answer is correct, but I needed a little more detail on how to accomplish it. To make it really easy, follow the steps below. I was setting up an asp page counter on a sandbox system in our intranet.
Open Computer Management.
Drill down to the IIS server
Management
In the Connections pane, click on
Application Pools
In the Application Pools pane,
right-click on DefaultAppPool and
choose Advanced Settings. Look in
the Process Model section.
By default, the Identity property is
set to ApplicationPoolIdentity.
This is a built-in account.
If it's set to the default, then you
can use the built-in user
machinename\IUSR for your
permissions settings. I had to
specify the machine name because
this is a virtualized server, YMMV.
If it's not set to the default, use
that username for your permissions
settings.
Cancel out of the dialog and return
to Windows Explorer, to the folder
where you need to add permission.
Right-click to get Permission
settings.
Set up machinename\IUSR or the
non-default username you determined
in steps 6/7 above. Grant
permissions as needed.
This helped:
http://learn.iis.net/page.aspx/140/understanding-built-in-user-and-group-accounts-in-iis-7/
The suggestion is correct. If the path to the solution is not immediately obvious for whatever configuration reasons, try running procmon (filter on "online_data.xls") and see who's failing, why, and what user account they run under. Then check the ACLs.
I had a similar problem in Windows 7 and my solution was changing the Authentication. From IIS, select the site, go to Authentication, disable Anonymous Authentication and enable Windows Authentication.
Spent a bit of time with something similar. Even with the correct settings it wasn't working.
I then tried create the actual file first on the server. Turned out to be the trick that worked. Now my ASP page writes to the existing file no problem.
Must be something about creating a new doc from scratch that is another issue.
I have been trying to configure a small website on a Windows Server 2008 running IIS 7. Unfortunately, when trying to load the website I keep getting the error: Server Error 401 - Unauthorized: Access is denied due to invalid credentials.
The permissions on the website folder include read, write, and execute for user ASP.NET v4.0. I even clicked "Check names" before adding the user to folder, to make sure that I spelled everything correctly. But the error continues to show. Also, I noticed that everything works okay if I add "Users" to the permissions for the folders containing the website, but I don't see why this should be necessary. I only want to give ASP.NET v4.0 access to the folder.
Some other noteworthy points include that I'm using the ASP.NET v4.0 application pool, that the managed pipeline is integrated, and that load user profile is set to true.
If anyone has any ideas, I'd appreciated the help. I'm stumped!
EDIT: Does it matter that the website is on the d: drive? I just assumed this wasn't important...
I find I always need to give IIS_IUSRS access.
I'd recommend you to use the Process Monitor to detect which user is actually accessing the file.
Here you'll find an explanation about how to achieve that.
Open IIS7 on the server. Highlight the site, and double-click on the Authentication icon in the Security Section. Check that Anonymous Authentication is enabled.
Some troubleshooting links for this particular issue:
http://support.microsoft.com/kb/902160
http://support.microsoft.com/kb/907273
Im trying to use the fileupload control. Im using Visual Web Developer Express on my desktop.
My web application is working fine except I cant use the fileUpload control. I get the following error:
ERROR: Access to the path (My_Directory) is denied
I searched and it appears to be a permissions problem. So I attempted to add the user ASPNET and give appropriate permissions to the directory, however, I was unable to add user "ASPNET". User "ASPNET" was not found.
So then I followed the following directions to add user ASPNET via Control Panel > Administration > Computer management. So now I was able to add user ASPNET to the directory and give appropriate permissions but I still got the above error.
http://p2p.wrox.com/net-web-services/5918-creating-aspnet-user.html
Any ideas on why I cant access the directory?
If you're using Vista/Windows 7/Win2003/Win2008, the user you need is the Network Service account. You can verify by seeing what user your application pool is running under.
Grant the proper permissions to that account (if indeed it's the account that your application pool is running under) and you'll be golden. Note also that with Windows 7 and Win2008, the default account could be the ApplicationPoolIdentity, which you can find out more information about at http://forums.iis.net/t/1156692.aspx. Regardless, you can simply switch the account that your application pool is running under to the Network Service account to verify that that is the issue.
Ever figure this out? If you're overwriting files check to make sure they aren't set to read-only.
I've handled these permissions plenty before and had tried everything in the book and on this site and others (I'm on Win7, IIS7.5 also). Sometimes it's the silly little things...
I have code running in an ascx within PageLayout within SharePoint 2007 that accesses files on a remote server i.e. File.Create("\servername\sharename\folder\file.txt"). The code runs within a SharePoint web application that has CAS trust set to Full in the web.config. The File.Create throws the following exception:-
System.UnauthorizedAccessException
Access to the path '\\servername\sharename\folder\file.txt' is denied.
The share is shared to Everyone with Full Control and the NTFS permissions are set to Everyone with Full Control. The web application app pool is running under a domain account also with explicit permissions to access that resource (not that this should be needed).
I ran Process Monitor on the remote machine and no hits were being recorded on the server. This leads me to believe that it is an issue with the SharePoint Code Access Security settings. Like I've said above, the trust in the web.config is set to Full.
Is it possible that CAS is still blocking the remote access? Can anyone think of any other area to review?
Update
A bit more information...
I've tried making the app pool acct domain admin and the problem still occurs. When using the same method to access a drive on the local machine it works fine. Running the same code in SnippetCompiler outside of sharepoint using the app pool account works fine.
Hope this helps, let me know if you can think of any more avenues of investigation or tests I can try.
Update
Im not sure if this would affect the issue but the local server is running Windows Server 2003 and the remote server is running Windows 2000.
Update
I've just tried running the code through a web part and it works fine. The file structure I use in the project that is failing is as follows:-
wss
- VirtualDirectories
- SharePointWebApp
- ...sp web app files
- .
- .
- PageLayoutControls
- control.ascx
- .
- .
Then in IIS I have the following structure:-
IIS
- Websites
- SharePointWebApp (pointing to \wss\VirtualDirectories\SharePointWebApp)
- PageLayoutControls (virtual directory pointing to \wss\VirtualDirectories\PageLayoutControls)
Then within the PageLayouts I reference the controls using the following:-
<%# Register TagPrefix="TEST" TagName="MyControl" Src="~/PageLayoutControls/control.ascx" %>
<asp:Content ContentPlaceholderID="PlaceHolderMain" runat="server">
<TEST:MyControl id="myControl" runat="server"/>
</asp:Content>Let me know if you need more info.
Update
The mystery deepens...
When I access the sharepoint site from Internet Explorer (6 or 7) on the SharePoint web front end server I do NOT get the exception.
When I access the sharepoint site from Mozilla Firefox from the SP web front end server I DO get the exception.
When I access the sharepoint site remotely from ANY browser I get the exception.
Also, it makes no difference what user I use to log on to the site, as long as they have permissions to access the sharepoint site.
Any thoughts?
Update
Hmm, I've now found that if I access the sharepoint site remotely and the sharepoint site tries to do a File.Create() locally (i.e. File.Create("C:\temp\abc.txt")) then it works. If I access the sharepoint site from the sharepoint box and do a File.Create() remotely (i.e. File.Create("\ServerName\ShareName\FolderName\file.txt")) then it works.
It only fails when I access the sharepoint site remotely and have the sharepoint site try to do a File.Create() remotely as well. Kind of a double hop problem. This makes me think it may be an NTLM / Kerberos issue.
Currently, we are running using NTLM authentication.
Has anyone else experienced this sort of issue?
Update
Yep, I'm pretty sure this is an NTLM issue not allowing a double hop. I just changed the authentication on the sharepoint site to use Basic Authentication and its worked. Changed it back to Integrated Authentication and it failed.
Now to decide whether to move the farm to use Kerberos or find another way around the issue. :-/
Update
Just giving SPSecurity.RunWithElevatedPrivileges a shot now. One thing though, is RunWithElevatedPrivileges meant to be used in this context? Previously, I've only used it to get access to lists and libraries within SharePoint rather than accessing a file access the network.
Any thoughts?
Update
Yep, SPSecurity.RunWithElevatedPrivileges resolves the issue. :-)
I wonder if this is the double-hop issue and that your code is trying to access the resource as the impersonated user, but that fails because NTLM will not impersonate to another server (Kerberos would).
Have you tried SPSecurity.RunWithElevatedPrivileges? That would remove the impersonation (RevertToSelf) and then maybe the application pool owner can just act as himself (herself?) whereas maybe it couldn't before.
Just a thought and should be pretty easy to try out.