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).
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 ?
Im not using this, but is a interesting question.
If i set a Web Application on IIS to use Windows Authentication and Impersonate the Authenticated User and my ConnectionString to a SQLServer database use Integrated Security=true;, my application when try to connect to the database will use the User authenticated by the application?
If yes, this is a good thing?
( The database has LDAP/AD "Domain Users" permissions. Considering an Database that will be auditable where each user will have your actions logged.)
I believe E.K.'s answer is true only under a situation in which kerberos authentication is used. What you are describing is known as the 'double-hop'. Essentially, if the user authenticates to 'Server-A', the code that is running on 'Server-A' cannot turn around and use those credentials to access other network resources, such as a SQL Server on 'Server-B'. This is detailed quite a bit but here is a direct link: Blog Article
If you are running on a kerberos architected network, then you can mark a server as being a trusted delegation server. But for most people, this is not the case. If you'd like to learn more about how to do this, see this link.
Yes, the connections to the SQL Server will be under those users.
In general, it isn't good. But it depends on the situation. The following are main factors to consider :
Each user will require its own connection. Connections from different users can't be reused even if connection pooling is used. Creating of connection is relatively expensive operation. And each connection requires a little bit of memory
Each user needs to have its log in (or at least Windows group that the user is member of needs to have the log in). This can be additional maintenance to create log ins, etc. On the other hand, each such log in can be secured in a different way. Important to say is that securing objects for different users can be achieved also if a single account is used to connect to the SQL Server
Yes, it would use authenticated user and impersonate the "authenticated user" rights to access the database.
For more information do look on this link How To: Use Impersonation and Delegation in ASP.NET 2.0
The other approach is to use a service account a non-interactive windows domain account that has complete access to the database.
This allows connection pooling
Eliminates complex permission models to allow selected users to perform a delete on a set of data for example.
This does mean however that audit logic has to be added to the data layer of the application and to stored procedures that access the database to insure that the calling user is logged as part of the database access otherwise the service account would be the only account in the audit table.
The following webpage talks about using impersonation in code (ASP.NET): http://support.microsoft.com/kb/306158. I am thinking about creating a class for the code, then the application can call impersonateValidUser and undoimpersonation.
I am concerned about putting usernames and passwords in my code as surely anyone will be able to see them using a tool like ILDASM. What is the best way to hide these passwords?
The article has a section titled: Impersonate the IIS Authenticated Account or User. I thought about creating an impersonated user in the Web.Config, but this would mean that the entire application is run as the inpersonated user. I only want a very small part of the application to run as the impersonated user - when it is necesary to access and update active directory.
I really like your intention to have have only the part of the application that does the AD updates running under a highly privileged account. I also share your concerns about storing the password in the web.config or in the code.
I can think of two options for you.
Store the account details in the web.config and encrypt that part of the web.config. That will ensure that only an administrator of the web server can get hold of the password. Someone else getting hold of the web.config won't understand a thing of the password.
Create a small, separate WCF service with the AD update code. Then run that WCF service in a separate application pool, with the app pool set to the identity of the user that has access to the active directory. Setup a restricted, localhost-only endpoint for the WCF. The WCF service should have access control to only allow access from a dedicated account. That account should be set as the identity of the app pool of the main web site.
Option 1 is easier to implement and protects the password rather well. Option 2 offers better protection for the passwords as they are not stored in the web.config at all - they are part of the IIS configuration. Option 2 also adds complete isolation between the privileged code and the rest of the system as it runs the AD update code in a separate process. With that isolation, it is much easier to make a code review for the AD code to check for security issues.
What I want to do is:
Allow anonymous users to access my ASP .NET site.
Use Windows Authentication for the site to access Sql Server. It will log in to Sql Server with a domain account set aside especially for the site (and preferably do everything under the same account).
Every article on the Web tells you to do this:
<authentication mode="Windows"/>
<identity impersonate="true"/>
in Web.config. However, I gather that this is only if you want users to log in with Windows Authentication. It has nothing to do with the server logging in to SQL Server (except that the combination of the above 2 implies that users' authentication will also be used to connect to the database). Is this correct? Given that my Windows account has access to files on the server and the database which the site is connecting to, this seems hard to test....
It seems that if I:
set the App Pool Identity to the domain account
enable Anonymous Access on the site using the domain account
use a connect string with Windows Authentication
then the site will connect to SQL Server via Windows Authentication. Also, it will use the domain account as long as impersonation is off. Is this correct?
in Web.config. However, I gather that
this is only if you want users to log
in with Windows Authentication. It has
nothing to do with the server logging
in to SQL Server
This is partially true. The impersonated account will be used to logon SQL server if delegation is setup properly. You didn't see this because in most of the environment, delegation needs to be explicitly setup. Delegation is a more powerful form of impersonation and makes it possible for the server process (in your case, IIS process) to access remote resources (in your case, SQL server) while acting as the client. For more information, you can google ASP.NET Delegation. I said it's partially true because in some simple environment, you don't even need any special configuration. The delegation is just working. For example, if you have SQL server running on the same machine as the IIS server. Another case is that you have your IIS server running on an Active Directory domain controller (very rare). In these two cases or on a machine with delegation configured properly, your above statements will be wrong.
It seems that if I:
set the App Pool Identity to the
domain account
enable Anonymous
Access on the site using the domain
account
use a connect string with
Windows Authentication
then the site
will connect to SQL Server via Windows
Authentication. Also, it will use the
domain account as long as
impersonation is off. Is this correct?
Yes, this is correct.
Given that my Windows account has
access to files on the server and the
database which the site is connecting
to, this seems hard to test....
It's easy to test if you have two domain accounts (or one domain account and one local account). Set the App Pool identity to use your DomainAccount1. Grant only DomainAccount1 to have permission to access your database. Access your web app on another machine using another accound (either domain account or local account). Test if the web app can properly access your database.
If I'm following you correctly, you are right; You do not want to use impersonation/authentication to do what you want to do. Set the App Pool identity appropriately, and assure that user account has appropriate access to SQL Server.
Instead of using a Windows Account you can create a separate Sql Login i.e. a username/pwd and use that in the connection string instead.
By default ASP.NET uses the network service account, is this the account I should be using with ASP.NET in production? What are the best practices related to the account used by ASP.NET?
Regards
Edit: If this makes any difference, I'll be using ASP.NET on a Windows 2008 server
For production, you should create a service account that has only the bare minimum permissions in order to run the web application.
The Microsoft Patterns and Practices team provides the following guidance on this:
How To: Create a Service Account for an ASP.NET 2.0 Application
You're gonna get lots of "it depends" answers but here's my 2 cents anyway.
Consider password change management, potential damage through compromise, as well as application needs e.g. trusted connectivity.
In most scenarios Network Service comes out best in these dimensions.
it doesn't have a password, and never expires - no change management required
it cannot be used as interactive login on other machines
it can be used in trusted connections and ACL'd access to other hosts via the credential <domain>\<machinename>$
Of course your app may have different needs - but typically we use Network Service wherever possible - we run 10,000's of machines.
Unless you have some other need -- like a requirement to use integrated authentication to SQL Server for a database connection -- I would stick with the default account. It has fewer privileges than many other accounts, yet is enabled with the necessary privileges to run web applications. Caveat here: we typically don't make any privilege changes for the network service account and usually fire up a VM per production application (or set of related applications) rather than configuring multiple applications per server. If you are running multiple applications per server or make changes to the network service account's privileges for other reasons, you may want to consider using a separate service account for each application. If you do, make sure that this service account has the fewest privileges necessary to run ASP.NET applications and perform any additional tasks required.
You should use a lesser privileged account possible
1) Create a specific user account for each application
2) Create an Application Pool that runs under this account
3) The Website should be configured to run under this Application Pool.
4) In SQL Server, use Windows Authentication and give DB permissions to this User.
5) Use this User in a connection string (ie no passwords in connection string)
6) Use this User to assign permissions to other resources as required.