I'm running into a (hopefully) small issue. I have a web app written in ASP.NET, that will be running off of a Windows 2003 Server machine using IIS 6.0. When I run it locally, it works perfect. When I run it from the server, the site works fine. The issue lies in writing to a remote folder. I have a network folder using AD permissions that the application writes to. With my AD account (when I write it locally) it authenticates properly, but when using the IIS account it does not. Has anyone come across this? Any solutions available?
So far, I've tried using my AD account as the "Guest Account" in IIS that the site runs off of, but that still didn't work.
Any thoughts, explanations, or suggestions would be greatly appreciated!
Thanks.
By default ASP.NET runs under the context of a local user account, which will not have access to your AD machines. You can reconfigure the connection pool to run as a domain account and lo, it gets access. You should give the domain account as little privileges as possible, and add it to the IIS_WPG on the IIS machine and give it Run as service rights on that box.
The way I normally tackle these situations is to do a couple of steps.
In AD create an account for the service.
Add this account to the network share you wish to access.
Then have your ASP.Net application run using that service account instead of the local IIS account.
In your web.config file you put the following line under
<system.web>
<identity impersonate="true"/>
</system.web>
Might it be related to the account that the Application Pool is running under?
You might also consider doing as suggested in this SO answer:
ASP.NET Windows Authentication Impersonate Problem
Wrap the code that is doing the writing to a remote location and everything else could be left alone. This will give you the best security for the web app since you are only impersonating an account with these writes for the code that needs it instead of all of it.
Related
I just joined a company to support a web app that no one knows anything about. Everyone who might have once known is gone.
The app is using a dll (I only have the binary) which is used to get a string list of Active Directory groups that the user belongs to. The code works in production and when I run interactively in the VS2005 IDE, but does not work when I run it locally in IIS.
The code is this. It blows up on line 127:
Line 127: userGroups = new FW.DirectoryHelper(username).getGroups();
Line 128: List<string> roles = new List<string>();
Line 129: List<string> groups = new List<string>();
With this error:
Error getting group information. The specified domain either does not exist or could not be contacted.
This looks like some sort of an issue with the ASPNET account not having access to Active Directory, but why is it working interactively but not under IIS? Is this because when I run interactvely I am running under my own credentials instead of the ASPNET account? Why would it run on other (eg, UAT) IIS servers including Production and not local?
Is there some local IIS configuration or fodler security configuration that I need to make to get it to work locally?
The binary is surely used elsewhere within my company; I think it is a shared IT utility that no one will support or trying to find someone who will will prove difficult.
My local IIS was configured with Windows Authentication turned on and Anonymous off. I also tried Windows Auth on and Anonymous...
Your issue is very similar to a question I answered recently, they too were using IIS 5.1.
Is it possible to retrieve data from Active Directory by impersonating a Windows authenticated user in ASP.NET?.
In my answer I provide a couple of possible solutions, what you will probably want to do is use ASP.Net impersonation.
The code is using the windows login credentials for ldap, whichever pc is running the program. Try setting iis to anonymous access and give it an account (a dummy one perhaps) that has ldap reading rights. And in your web.config file, you're going to want to set this anonymous account like so:
<system.web>
<identity userName="DOMAIN\username" password="myPW"/>
</system.web>
Is this IIS6 or 7?
If II6 make sure the application pools Identity is set to that of a domain account.
If IIS7 make sure under Basic Settings it is set to that of a domain account.
Hope this is helpul.
A quick fix is to set the identity of your local IIS to use your login credentials instead of the default system account.
I have an ASP.NET application that's trying to copy a file to a remote share that's on a server on another domain ("REMOTEDOMAIN"):
File.Copy(#"c:\Test.txt", #"\\REMOTEMACHINE\Share");
When we get to the File.Copy method, I'm getting "Login failure: Unknown user name or password" when trying to connect to the share through the local IIS install. This is despite the share itself having "Everyone" read/write permissions (temporarily, at least). The Security log on the remote server logs the same error, so I know the process is at least trying to get to the right place.
I sort of understand why, as the website's application pool is attempting to authenticate with an account on LOCALDOMAIN and not REMOTEDOMAIN.
However, the weird thing is, the entire process works fine when I test through the ASP.NET Development Server instead of IIS, despite the fact that both the Development Server and the IIS Application Pool are using the same credentials.
Any thoughts on how to further diagnose this? Unfortunately the test site has to remain on LOCALDOMAIN and the files still have to be copied to REMOTEDOMAIN; I can't move one site to the other or vice versa.
Everyone does not include Anonymous, so the user still needs to be in the domain of the REMOTEDOMAIN (http://support.microsoft.com/kb/278259). You could get this working by allowing "Guest", but it would be a security nightmare of course so it is not much of a help.
The solution would be to impersonate Asp.Net user: http://support.microsoft.com/kb/306158
One hack that you should know is that if the IIS is not in the remote domain, you can go around this problem, by setting up local (non-domain) users on both machines and setting the same password for both of them.
despite the fact that both the Development Server and the IIS Application Pool
are using the same credentials.
Are you absolutely sure about this? If you are talking about the Visual Studio dev server, it runs on your account. And typically Asp.Net runs as "Network Service"
I constantly trip on this when writing apps for our intranet.
Let's say we have a network share called "\\server1\myfolder", and I'm writing an app that needs to read a text file from there. Access to the share is very limited, which is fine. If someone doesn't have access to the folder, the app catches the error and tells the user they don't have access.
This works fine when I run it locally, but when I publish the app to the test server, it never has access to the folder, no matter who is running the app. Ideally the app would impersonate the user and use their credentials, but I never seem to be able to set it up correctly.
My web.config is set up like this:
<authentication mode="Windows"/>
<identity impersonate="true"/>
I've also tried impersonate="false", but it doesn't make a difference. Can someone explain what is going on here, to someone with a very limited knowledge of IIS (this is running on IIS 6 by the way)? Any idea how this should be set up, or is it impossible?
This previous post is similar and contains a valid answer:
Access files from network share in c# web app
as does this one
Asp.net Access To Network Share
Check your IIS directory security settings. You need to have anonymous authentication turned off and Windows authentication turned on.
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 !
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.