I am trying to access an old fashioned asmx web service hosted in IIS and I am banging my head against a 401.3 error. I know there are lot of resources out there but most of them make use of impersonation and by adding permissions for the authorized user to the file system, which I want to avoid.
My scenario is basically an IIS webservice, running with an AppPool which runs as a specific service account (DOMAIN\username + password). This service account has full control on the folder and the Anonymous authentication is set to use the AppPool Identity.
This is all good and working but now I wanted to secure my webservice by adding Windows authentication. I did that and added a simple <deny users="?" /> to the authorization section. What happens now is that when I connect to the server I get asked for a username and pwd, I provide one and then I get a 401.3 error.
I have tried adding read&execute permissions for myself to the folder and everything works but this is clearly not a proper solution as I would have to keep managing folder permissions.
My question is: why does the authenticated user needs folder access? Isn't the folder accessed as the app pool identity? Impersonation is disabled so I would expect that to be the proper behaviour.
why does the authenticated user needs folder access?
The FileAuthorization module requires the authenticated user to have permissions to the file.
Isn't the folder accessed as the app pool identity
Yes, but the above module also checks the authenticated user. You mentioned that you have Anonymous set to use AppPoolIdentity, so I'd expect in your case, this to be true.
Impersonation is disabled so I would expect that to be the proper behaviour.
This is independent as the FileAuthorization module kicks in anyways.
By recommendation for how to troubleshoot would be grab a ProcMon trace and I suspect you'll see some AccessDenied. Go look and see what permissions are required by what process and see if its doing impersonation (for this check). This will tell you what permission is missing/failing.
Related
I want to create a directory on a network path from a WCF web service. This web service is hosted under a site that uses Windows authentication. However, when I try to create the folder with "Directory.Create", I get an access denied. When I check "HttpContext.Current.User.Identity.Name", I can see my own user account, but I guess it is not the one used to create the folder, as, when I do "System.Environment.UserName", I see another value.
I tried to put "<identity impersonate="true" />" in the main web.config of the web site but then, nothing works anymore.
So my question is, is it possible to create the directory using the permissions of the currently logged user ?
As a precision, I'm calling the webservice through AngularJS and I configured my "$httpProvider" to pass the credentials ("$hp.defaults.withCredentials = true;").
EDIT:
I added "<identity impersonate="true" />" to the web.config placed in the folder that contains my web service and now, "System.Environment.UserName" contains the correct credential but still, I guess the access denied. I tried the same command from a console application and it works. I really don't get it...
EDIT 2
If I changed the "identity" element to "<identity impersonate="true" username="USERNAME" password="PASSWORD" />", then it works, but I don't want to fill these fields...
Thanks
I'm assuming the network folder is on another server, you're either going to have to impersonate credentials that has access to it or whoever the apppool is running as will need permissions to write to that folder.
We typically have the app-pool running as a domain account in IIS. You can tailor the permissions as you see fit then (assuming both servers are on the same domain and, you don't have to store passwords this way, whoever manages your IIS would handle that). If the site just needs to write (but not read) you could give it write permissions but not read.
I am in asp.net, C#, .net FrameWork 4.0
I have a file in my downloads folder in my webhost that i can't delete it now! i can delete any other files, but just this one and one or two more files has such this problem.
I don't know the reason... but i think there is a problem in the file security.
When i attemp to delete the file with this way:
FileInfo fi = new FileInfo("file.dat");
if (fi.Exists) fi.Delete();
The file name and the path is correct and available in the path.
so fi.Exists returns true then fi.Delete executes...
but raises this error "Access to the path ... is denied!"
I thought that the permission for my app is limited and can not delete the file.
So i decided to set a FullControl permission to the file like this:
FileInfo fi = new FileInfo("file.dat");
FileSecurity sec = fi.GetAccessControl();
sec.AddAccessRule(new FileSystemAccessRule("Everyone", FileSystemRights.FullControl, AccessControlType.Allow));
fi.SetAccessControl(sec);
but now, raises this error: Attempted to perform an unauthorized operation
Where is the problem...???
How can i allow my app to delete all files without problem...???
Pleas help me sooner...
Thanx...
You will need to change the permissions to the file prior to running any code to make sure IIS Usr or all users have access. Remember your ASP.NET application is running under the context of the application pool. The only way to run under another context is to turn on impersonation. This could be a case that the file was created on a different server (load balancing) under a local account that runs IIS and now it can't remove it because the permissions are different. If you run under a specific context in your application pool (service account etc.) then you should not have these issues.
More information on impersonation is at this link (https://msdn.microsoft.com/en-us/library/xh507fc5(v=vs.100).aspx).
When using impersonation, ASP.NET applications can execute with the Windows identity (user account) of the user making the request. Impersonation is commonly used in applications that rely on Microsoft Internet Information Services (IIS) to authenticate the user.
ASP.NET impersonation is disabled by default. If impersonation is enabled for an ASP.NET application, that application runs in the context of the identity whose access token IIS passes to ASP.NET. That token can be either an authenticated user token, such as a token for a logged-in Windows user, or the token that IIS provides for anonymous users (typically, the IUSR_MACHINENAME identity).
When impersonation is enabled, only your application code runs under the context of the impersonated user. Applications are compiled and configuration information is loaded using the identity of the ASP.NET process. For more information, see Configuring ASP.NET Process Identity. The compiled application is put in the Temporary ASP.NET files directory. The application identity that is being impersonated needs to have read/write access to this directory. The impersonated application identity also requires at least read access to the files in your application directory and subdirectories. For more information, see ASP.NET Required Access Control Lists (ACLs).
<configuration>
<system.web>
<identity impersonate="true"/>
</system.web>
</configuration>
Even default ASPNET websites seem to require Windows Authentication enabled on my machine when Anonymous Authentication should do, what could be wrong with my IIS7/ASP.NET install?
I've ran aspnet_regiis /i but it still does not not fix it!
I get 401.3
Access is denied.
Description: An error occurred while accessing the resources required to serve this request. You might not have permission to view the requested resources.
Error message 401.3: You do not have permission to view this directory or page using the credentials you supplied (access denied due to Access Control Lists). Ask the Web server's administrator to give you access.
Ensure that the web user has access to the files. File/folder permissions will override the anonymous option you pick in IIS.
It looks like the issue is with Basic Authentication being disabled, by default.
Enabling this fixes the issue!
This application is using windows integrated authentication in IIS. No anonymous login.
It's also using an application pool defined to log on with a domain user.
If a try to browse any page, it pops up the username and password dialog box and even though I entered a valid user (including the domain administrator) it doesn't log on into the app. I keep getting the username/password dialog. If I logon locally (in the IIS box), it works OK.
Also, if I change the application pool to use Network Services, it works OK.
The domain user is already a member of the local IIS_WPG group in the IIS box.
Am I missing something here?
If you use a domain account for the Application Pool you have to run a series of scripts on the domain controller. So, apparently it's not recommended to use a domain account, rather a local server account. Microsoft has this issue documented on a case:
http://support.microsoft.com/default.aspx/kb/871179
I suspect the NTFS file persmissions on the .aspx files don't allow the users you are logging in as the needed access to read/execute them. What are the file permissions on the files you are trying to view? What do your authorization and authentication elements in web.config look like?
This sounds like it's related to the privilges assigned to the domain user. i.e. whether they, or indeed the server, are permitted to impersonate the user that is logging in. Or, something regarding "Trusted for delegation" in the server's settings in AD. Either way, you'll probably get a better response on serverfault =)
Try entering the same user of the appPool as the anonymous user (Web Site Security tab)
I had the same user/pwd Popup problem in Svr 2003.
I solved it by CHECKING ANONYMOUS ACCESS in directory security of DEFAULT WEB SITE.
It promps you if you want to also affect your sites you click OK.
That did it.
We're trying to run a set of administrative tasks on the server via a web administration console. The console runs with impersonation as the currently logged-in user, and only administrators on the local machine are allowed to log in. Right now it works for most cases but we're having trouble when running under UAC.
The first issue is a blocker: it seems like admins do not get the "BUILTIN\Administrators" role even if they are an admin on the local box. This can prevent them from even getting into the admin console, since we're using the web.config <allow roles="BUILTIN\Administrators"> notation to specify security. I suspect that the only solutions here are to either run the ASP.NET app as SYSTEM, or to allow more users and do a more granular permissions check in code. Any other ideas? Is there any way to inject an elevation request into the built-in ASP.NET permissions check?
The other problem is that we want to run some commands that require administrator access. The user visiting the site is an administrator, and is correctly impersonated, but when we spawn a process it fails due to lack of administrator privileges. The clear answer is to elevate for the duration of that command. There are solutions that will let me temporarily elevate by impersonating a specific username and password, but I'd prefer not to have to ask the already-validated user for his password. Are there any tricks for elevating the current user?
(I can understand why the ASP.NET team might try to make this hard, so that web pages can't take invisible advantage of an administrator visiting the web site... but surely there must be some way to pro grammatically declare that your code needs full Administrator rights, appropriately warning the IIS admin of its intentions?)
There are a series of answers for Windows Forms apps, such as:
How to elevate privileges only when required?
and File.Exists returning false from a network share
but I'm hoping to find one that will work with ASP.NET...
Thanks
Steve
We were able to achieve a "higher" impersonation level from the user currently accessing the website by enabling the server for delegation in Active Directory. Per Microsoft, You can think of delegation as a more powerful form of impersonation, as it enables impersonation across a network. You may not need to go across the network, but it may resolve your security issues.
Here are a few resources on setting up delegation, hopefully this will help you.
Impersonation and Delegation
Impersonation and Delegation in ASP.NET
http://support.microsoft.com/kb/810572
http://msdn.microsoft.com/en-us/library/aa291350(v=vs.71).aspx (older article)
http://msdn.microsoft.com/en-us/library/ms998351#paght000023_delegation