This is a similar question to many that I have seen before but I have not found a clear answer yet so I will try to be very specific here to avoid duplication.
We are running IIS7.5 on 2008R2 with only windows authentication turned on (no anonymous) and no impersonation. There is a network account specified for the application pool user.
When I check the WindowsIdentity.GetCurrent() of the currently executing page I get the expected (App-pool) user based on our configuration.
http://www.mikeobrien.net/blog/identities-for-different-iis7/
This matches the expectations nicely. However, it appears that NTFS folder permissions on our application are being checked against the identity of the authenticated user.
This seems to contradict most of the documentation I have found. The above link as well as
http://msdn.microsoft.com/en-us/library/kwzs111e(v=vs.100).aspx
http://msdn.microsoft.com/en-us/library/3yfs7yc7(v=vs.100).aspx
http://msdn.microsoft.com/en-us/library/gg703322%28v=vs.98%29.aspx
How is IIS checking the authenticated user's identity in folder ACLs when .Net is clearly indicating that the WindowsIdentity in play is that of the App-Pool?
The only theory I have so far is that the file authorization module is utilized with integrated authentication automatically and it is explicitly checking this... but it still seems to go against the documented expectation.
http://msdn.microsoft.com/en-us/library/gg703322%28v=vs.98%29.aspx
This article, for example, seems to document both expectations.
When Windows authentication is enabled but impersonation is disabled, ASP.NET performs file access checks in the file authorization module using the credentials that are sent from the browser. Impersonation does not need to be enabled, because the FileAuthorizationModule module ensures that the requesting user is allowed read access or write access to the resource, depending on the request verb (for example, GET or POST) before executing the request.
Followed a few lines later by
Windows authentication without impersonation. This is the default setting. ASP.NET performs operations and accesses resources by using your application's process identity, which by default is the application pool identity on Windows 7 and Windows 2008 R2. For more information, see Application Pool Identities.
Windows authentication with impersonation. With this approach, the Web application impersonates the authenticated user and uses that identity to perform operations and access local resources. When you configure your application for impersonation, an impersonation token for the authenticated user is attached to the Web request thread. As a result, all local resource access is performed using the caller's identity.
My question:
What identity should be used when file system ACL checks are performed? (My understanding was App-Pool when impersonation = off) and what settings might affect which identity is used outside of impersonation?
This is very similar to this question:
Does an IIS 7.5 web app with windows authentication require end users to have file permissions?
The marked answer on this question does not address my concern. Authorizing 'authenticated users' group should not be required as the identity being used should not rely on the set of end-users being authorized. My question is much more specifically, which identity and how is this controlled?
"NEW IN IIS 7.5
IIS 7.5 added the authenticatedUserOverride attribute to the element, which configures whether the IIS 7 server runtime will provide the authenticated user's identity or the worker process identity in the IHttpUser::GetPrimaryToken and IHttpUser::GetImpersonationToken methods. This attribute can be set to UseAuthenticatedUser or UseWorkerProcessUser, and these values respectively specify whether the IIS 7 server runtime will provide the authenticated user's identity or the worker process identity for any module that is using impersonation."
Source
Related
There is a similar question pertaining to my topic here, but it doesn't fully satisfy the issue I'm having. Going off the question in the link, how would the apppool identity get used as the current user? My application actually gets the users out of a SQL db, but the apppool identity is not in the db, yet still gets logged as the current user. Thanks in advance!
Your appPool identity IS the current user, as far as IIS is concerned. IIS has no knowledge of any account that you are storing in your application's SQL database. When you enable Anonymous authentication, you can change the account that IIS uses to access your sites and applications. By default, IIS 7 uses "IUSR" as the user name for anonymous access, however you can change this to "Application pool identity" if you want to restrict access that way."IUSR" user name is created when you install IIS 7.Any clients connecting to the application will be connecting as either "IUSR" or "IIS AppPool/{AppPoolName}". I am guessing that your function to log the current user is reading from the SQL information and not from your HTTPcontext. More information about Application Pool Identity here: http://technet.microsoft.com/en-us/library/cc770966(v=ws.10).aspx
Normally a website process (w3wp.exe) impersonates the identity of the application pool identity (IIS APPPOOL\DefaultAppPool)
Unless you are using Integrated Authentication, in which the website process impersonates the identity of the authenticated user account accessing it (YOURDOMAIN\YourUsername).
What your site does beyond that is separate from IIS authentication and totally up to your application - that is, if you then go and set your users from your database, etc.
Short version:
For IIS 7.5 web applications with Windows Authentication does the end
user need to have Read file access?
Long version:
I have an intranet ASP.NET web app that uses windows authentication. It's installed at dozens of different companies and normally the authentication works fine: users navigate to the site e.g. http://appserver/MyApp, the app recognizes who they're logged in as and displays pages accordingly. I just installed it at a new client and encountered a problem:
When connecting e.g. to http://appserver/MyApp I'm prompted for windows credentials but after entering them I'm repeatedly prompted. After several re-entering credentials I'm shown a 401 error page saying "401 - Unauthorized: Access is denied due to invalid credentials.". So not only is it not passing through my identity but even when entering the username & password it's still denying access.
Giving Read & Execute permissions to the end users of the app solves this problem, but I don't think this should be necessary at all.
In the windows Application Event Log there's a message "File authorization failed for the request" along with Thread account name: NT AUTHORITY\NETWORK SERVICE and User: [the correct workstation users's domain account]. This suggests that the file access is being performed with the User's identity, not the AppPool identity of Network Service. Sure enough if I grant the end user Read & Execute permission (I didn't try Read only) to the application's directory then everything works correctly: when the user browses to the site they're authenticated automatically, not prompted, and the web site correctly recognizes their identity! Therefore my workaround solution is to give Read & Execute permission to Everybody on the application directory...but this is not an ideal solution.
This seems very strange. I've never needed to do this before in IIS 7.5, so far as I recall, and definitely never needed to in IIS 6 or IIS 7. Is this a new IIS7.5 thing? The documentation says that Impersonation is turned off by default. I added a element to the web.config to be sure, removed file permissions other than Network Service, but the problem remained.
Any thoughts? Is it normal for Windows Authenticated sites on IIS 7.5 for end users to need file permissions on the web server files?
Some relevant details:
Network Service
has Full Control file permissions to the app folder.
When connecting from the server itself I was prompted for credentials
but after entering them i'm authenticated and the application works
correctly including displaying my windows login and connecting and
retrieving data from the db. I later determined that it was prompting
for credentials because http://localhost was in the trusted sites
and therefore not recognised as the Intranet Zone and thus not
passing identity through. I also determined that it was working as
this user identity because it's an admin user who has file
permissions.
The web server is running Windows Server 2008 R2 / IIS
7.5. It didn't have IIS on it until I installed it. I installed the default features as well as Windows Authentication, ASP.NET, and
possibly a couple of other items. A separate WCF app I installed that
uses IIS, anonymous authentication & .net 2.0 is working fine on
that web server.
The app install process is a manual copy of files,
creation of IIS App Pools & web apps, updating connection strings,
etc.
I checked the IE security settings. It was recognizing the
server as in the Intranet zone and had the option 'Automatic logon
only in Intranet zone' selected. Also on Advanced Settings the
'Enable Integrated Windows Authentication' option was checked.
After
installing IIS I ran aspnet_regiis -i for .net 2.0 and
aspnet_regiis -iru for .net 4.0.
Anonymous authentication is
disabled for my app and Windows Authentication enabled.
The app is
running on ASP.NET v4 but there's another app I installed
experiencing the same issue running ASP.NET v2.
The app is running
with Identity = Network Service and in 32-bit mode.
Database
connection string includes Trusted Connection=True and database
permissions are granted to the web server account [domain]\[server]$
e.g. DGM\MyServer$.
In IIS > Authentication > Windows Authentication > Providers the list was Negotiate first then NTLM. I tried reordering so NTLM is first.
In the Windows Security Event Log there
were a series of Microsoft Windows security auditing events: Logon
and Logoff. They indicated that the Logon was successful and was
displaying the User Id of the workstation user. This are from when
I'm connecting from another workstation and receive a 401
Unauthorized after several attempts.
I see someone has had this problem reported here but with no solution. Originally I posted in the ASP and then the IIS forums with no answers so far.
Update:
This msdn article says
When Windows authentication is enabled but impersonation is disabled, ASP.NET performs file access checks in the file authorization module using the credentials that are sent from the browser (my emphasis). Impersonation does not need to be enabled, because the FileAuthorizationModule module ensures that the requesting user is allowed read access or write access to the resource, depending on the request verb (for example, GET or POST) before executing the request. This behavior applies to any requests that enter managed code. In earlier versions of ASP.NET, accessing files based on URIs such as "Default.aspx" triggered the access check. In ASP.NET MVC applications, where access to resources is typically performed using extensionless URLs, this check typically does not apply, because there is not a physical file to check. In that case, the FileAuthorizationModule class falls back to checking access-control lists (ACLs) for the folder.
This does suggest that the end user needs permissions to the files (in the case of .aspx) or the folder (for MVC) ... although still this seems slightly tucked away and non-definitive. This article about App Pools says they're used as the identity for securing resources, which contradicts the idea of needing to grant privileges to end users. Unless the rules are different for App Pools and NETWORK SERVICE, which could be the case but would be surprising.
Are authenticated users allowed to the app folder?
We were also fighting with this issue, and started setting up security groups so we could give our users file level permissions. Then one of our server admins stumbled across a couple of new properties that allow the app to authenticate to the file system under set credentials, and resolved the need for the users to have access. Here is what he came up with…
There are two IIS settings that control this:
Physical Path Credentials Physical Path Credentials Logon type
By default, Physical Path Credentials is set to Application User
(Pass-through authentication). This means that IIS doesn’t do any
impersonation when handling Windows Authentication requests. This can,
however, be set to a specific user (though not, unfortunately, the
application pool identity, which would be ideal). Physical Path
Credentials Logon Type is set by default to Clear-Text. For my testing
I set this to Interactive (though this may not be the correct value).
Possible values are Clear-Text, Batch, Interactive, and Network.
To set this up I did the following:
Created a local account (IIS-AccessUser)
Granted IIS-AccessUser read and execute access to the /home directory of the site.
Added IIS-AccessUser to IIS_IUSRS group (necessary for accessing .NET temporary files)
Set IIS-AccessUser as the Physical Path Credentials
Set Physical Path Credentials Logon Type to Interactive
Doing the above allowed me to log in to the application directly,
without having to allow Authenticated Users, or me having to be a
member of any of the groups in the /home folder. It also still
preserved .NET Authorization roles, so I still could not access parts
of the site that I was not allowed to.
The short answer is NO. You are not required to grant file access permissions when using Windows Authentication in IIS 7.0 and IIS 7.5.
We were only able to discover this because our server admin smelled the security and management issues that arise from taking the route of granting file level access to users and groups.
For anyone dealing with this issue or if you are setting up a new IIS7/IIS7.5 server and/or moving from IIS 6, here is an article that gives you all of the Windows Authentication options and configurations that need to be modified to avoid granting file level access to individuals or groups.
Please read the two comments in at the end of the POST for some valid critiques of the methods used in this article.
http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk
In addition to the information in the article, please be aware that IIS 7.5 is not using the web configuration tags for system.web (at least not in my MVC 4 application).
It is looking in the system.webserver tags for authorization configuration (where you will need to list the windows domain\groups a user needs to be in to access your application).
-- DSB
SQL Server Windows authentication uses application's process identity or thread identity to connect. So for an ASP.NET application, which identity will be used to connect
Current User Identity
Application Pool Identity
Process Identity
or another identity?!
It really depends of your IIS Website configuration.
By default it will use the application pool's identity if you disabled the anonymous access. But if you configure your application with Impersonation=true, then it will use your user's identity as described:
The configuration illustrated in the example enables the entire application to run using the contoso\Jane identity, regardless of the identity of the request. This type of impersonation can be delegated to another computer. That is, if you specify the user name and password for the impersonated user, you can connect to another computer on the network and request resources, such as files or access to SQL Server, using integrated security. If you enable impersonation and do not specify a domain account as the identity, you will not be able to connect to another computer on the network unless your IIS application is configured to use Basic authentication.
See all details in this MSDN article.
I am little bit confused about various different identities in ASP.NET and IIS. can any tell me exact difference between Application Pool Identity, Anonymious Identity, ProcessModel Identity, Impersonation Identity and Thread Identity? Please also tell me when asp.net uses which identity?
IIS is web server that can host active/passive content other than ASP.NET (for example, classic asp, php, static files etc). Application Pool Identity decides the user under which the request will be running from IIS perspective. So when static files (html/image) will be served, this user will be used to access files from disk. Many times, IIS will hand over actual execution of request to different handler (for example, php-cgi or ASP.NET runtime etc). That run-time may use different identity to run the request. In case of windows authentication, IIS will pass windows user token to the specific handler and handler may impersonate current request to run under that authenticated user's identity. Classic ASP was one such system. In these cases, when user is not authenticated (i.e. anonymous), anonymous user's identity will be used.
In case ASP.NET, the default configuration will run the request under Application Pool's identity. However, using configuration, you can instruct ASP.NET run-time to impersonate the current user's identity. You can also configure to impersonate request under specific identity by configuring as such - typical this is done where application code need to have specific access permissions such as access to file shares, network resources etc.
Process model identity is something IIS 5.* only. In IIS 6+, its equivalent is application pool identity.
When the worker process is created, process model/application pool identity is used as the process identity.
When anonymous access is allowed, anonymous identity is used as thread identity for all threads who handle incoming requests inside the worker process. Other threads' identities depend on how they are created, and are transparent to developers/end users.
When other authentication method is used such as Windows authentication, the worker thread identities use authenticated user identities (each incoming request may be from an authenticated user, then this user's identity is used for the thread that handles the request).
Impersonation is much more complex, as documented in
http://msdn.microsoft.com/en-us/library/aa376391(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/ff647404.aspx
It changes the security context, which is not an easy-to-understand Windows concept, which you may either learn from great books or from experiments.
Please explain impersonation for non-technical users.Then please explain it in the context of ASP.NET. Is Impersonation good or evil? Do we use it in the case of Forms-based Authentication?
You should check out Keith Brown's description of impersonation. It is really a Windows concept.
When you have an application using forms authentication (FA) the IIS process is running under the credentials of a specific user setup in IIS.
Example: If you have a user called Bob logged on using FA and IIS setup to run as Network Service. Bob accesses a page which makes a web service call to another computer, the other computer will see the IIS user and not Bob. You can use impersonation to allow Bob to access the web service as a real Windows user and not Network Service.
Impersonation is not evil but it can be misused. You really need to understand the impact on your overall security model. It is also something that creates a lot of work for a developer to debug. This is especially the case if you do not have admin rights to the resource (eg. web service) you are trying to access.
Web applications run through a web server. That web server runs as a user with different permissions than yourself. Impersonation allows the application to run as you (or any other user with different priveledges on the cmoputer), as if you were logged in to the computer running it itself.
It actually makes things quite good. It allows you another way to grant/restrict access to protected files on the computer.
And yes, you can apply it using Forms Authentication (but you don't have to).
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).