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.
Related
I have an IIS6 And II7 servers under my management.
all my application pools are running under a custom account which is a member of the IIS_IUSRS
Some of the websites on the webserver were hacked and malicious asp.net files was uploaded to the server.
Those files were used to act as a medium between the attacker and the OS to execute code
I have noticed that the user under which the application pool was running was able to list all the directories of my server and was actually a part of "Authenticated users" and hence "users" group which by default have permissions to execute files/create folders etc.
The hackers were able, using the application pool credentials, to be authenticated as an authenticated user and since authenticated user is part of the users group they were able to do what they want
you can easily recreate the issue by using process explorer to view a worker process security groups.
My Questions are:
How should I secure correctly my server if I want to run the application pool as custom user and not as the built in identitty pool identity ? ( the reason I need to is because I'm using websitepanel management software )
Is something wrong in my config or is it possible that on every MS server that uses custom user as the identity and has some security flaw in the website, a hacker can cause havoc to the entire server ?
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
I was wondering when using Windows Authentication mode in a connection string from a web application. Application itself is using Windows Authentication for authorization. Which account will be used to login to SQL Server.
Is't the web application pool account?
User account who logged in to web application using windows auth?
Any other account?
Application is running under Win Ser 2008 64 bit and IIS 7. Application pool account is Network Service.
It depends on how you configure it. From http://msdn.microsoft.com/en-us/library/ms998292.aspx and http://msdn.microsoft.com/en-us/library/bsz5788z.aspx ...
ASP.NET applications do not impersonate by default. As a result, when they use Windows authentication to connect to SQL Server, they use the Web application's process identity. With this approach, your front-end Web application authenticates and authorizes its users and then uses a trusted identity to access the database. The database trusts the application's identity and trusts the application to properly authenticate and authorize callers. This approach is referred to as the trusted subsystem model.
The alternative model referred to as the impersonation/delegation model uses the original caller's Windows identity to access the database. This approach requires that your ASP.NET application is configured to use impersonation. See the section "Impersonation / Delegation vs. Trusted Subsystem" in this document.
So depending on how you have configured it, it could use either the app pool account (not when not using impersonation) or the account of the logged-in user that is using the web application (when using impersonation).
See http://msdn.microsoft.com/en-us/library/134ec8tc.aspx for impersonation information.
It's the application pool user who connects to the database, if you specified Integrated Security in your connection string.
The problem that i was having was that my application pool account in SQL Server needed to be set to the db_owner role before it worked. I spent a long time trying to figure this out.
I was using Windows Authentication, Windows 7 home premium, and IIS all on the same computer. I'm posting this in case someone else run into a similar problem. The book i used did not say to use db_owner but the reader and writer accounts instead.
i've always read that the user you set in the IIS website/virtual directory is the user that runs the app (anonymous user identity)
But in the application pool, i can also set a user (process model, identity)
what is the difference between the two, and which one will need access if i do a file read?
EDIT:
the bounty is for this quesyion ' but if i use 'anonymous authentication', is the user i choose in the 'anonymous user identity' ever used? – ' posted as comment
Checkout this post. Quote:
The two accounts are different things.
Think of the website identity
representing the user of the site. If
you create a new website this account
is the anonymous IIS account. If you
disable "Anonymous Authentication",
your users will have to authenticate
against the website (in a
intranet/Windows domain site this
could be implicite using the network
credentials.)
The application pool identity is the
Windows account needed for running
your assemblies. Normally it is the
"Network Service" account which is a
least privileged account with limited
user rights and permissions. It does
have network credentials. This means
that you can use it to authenticate
against network resources in a domain.
You can also use it to access a SQL
Server database with integrated
security.
For example, if your ASP.NET
application has to write to a folder,
you have to grant the permission to
the application pool account, not to
the website account. For more
information on application pool
identities, read here.
Think of the website identity as a rule that defines who can access the site. If you specify an anonymous account to use, that account must have access to the site. If anonymous access is disabled, then the user's credentials must have access to the folder.
The app pool identity defines what the application can do. The app pool's worker process will run using the app pool identity; that account must be granted access to any resources (SQL Server, file shares, etc) that the app will need to access.
To answer your question: yes, the anonymous account is used. Think of the scenario where you're hosting a hundred web sites, and you don't want one customer's files to be able to access another's. You would assign separate anonymous access to each customer. Each site's anonymous account allows IIS to access only the files relevant to that particular site (provided you've configured that account's access correctly).
#Michel
if you have an Anon Access Account setup on your site (virtual dir)
AND you have
<system.web>
<identity impersonate="true" />
</system.web>
in your web.config, this will use that identity.
if you have a part of code where you can set the credentials
CredentialCache.DefaultCredentials
this will point to the Anon Account,if you want to test what user you are using try
Thread.CurrentPrincipal.Identity.Name.ToString()
have a look at this post for more information
http://blogs.iis.net/sakyad/archive/2008/11/19/process-and-thread-identity-in-asp-net-a-practical-approach.aspx
I have an asp.net application that runs on a custom app pool which runs under a service level account. I have anonymous access turned off in web.config. The web server is part of a domain. The application access a sql server which runs on the same machine.
Currently, for all users, I impersonate the service level account to access the Database. When lots of users are accessing the site, this slows the site down as the lsass process starts using the cpu.
I am not allowed to create a sql server account, I have to work with what I have.
I am also not allowed to add each individual user to the database and give them specific access.
My question is, how can I set my application and datbase reletionship up such that I dont have to do impersonation of the Service level account and thus avoid CPU thrashing when website usage is high.
You shouldn't have to impersonate the service account. The service account is the account that needs access to the database and I suppose it already has. Have you already tried running your application without impersonating the service account when you access the database? This should work.
To perform a simple test, check the identity returned by WindowsIdentity.GetCurrent() (inside Page_Load for example). This should return the application pool identity and this is the identity that will be used to access the database.
Of course, this only works if you do not have client impersonation configured in your Web.config file. But since this is not a general practice except for some corner cases I suppose you don't use this. Client impersonation is not necessary for determining who the current user is, you should only use it when you want to access third-party systems (databases, fileshares, queues, ...) using the identity of the currently logged-on user (which is not a very scalable approach).