I've run into an issue managing our dev IIS instance and an MVC 3 web application. The issue is that when I try to connect to the database from the IIS machine via one of our website I get the error: Login failed for user . Where is the name and domain of the server IIS is running on. The IIS server and SQL Server are on two different machines. I have read multiple questions on SO and other sites and it said to run under application pool identity, which we are doing. We have a user for the database that is tied to the application pool identity.
The site was operating as expected yesterday but after a server reboot it seems to have caused this issue. I have checked everywhere and there is not an area that would cause this to run under NETWORK SERVICE or LOCAL SERVICE. I've been banging my head on this problem all day and was hoping that there was some solution that I have missed.
I have a asp.net application where I am using running process.start. it runs on my pc but not the server.
I have read that I needed to give my iis worker permission to run interactivity with the desktop however this still is not working.on my server the asp.net app is under its own application pool. How do I give my application pool access to run the process.start?
Give permission for ASP.NET worker process account (\ASPNET) to interact with desktop or allow ASP.NET worker process to run in SYSTEM account.
To know how to allow worker process to run in SYSTEM account and to know the default permissions of ASPNET account, check this article
INFO: Process and Request Identity in ASP.NET (http://support.microsoft.com/default.aspx?scid=kb;en-us;317012)
2. Enable IIS Admin Service to interact with desktop
To configure this, follow this steps.
a. Open Control Panel and follow these steps:
For Windows NT: click Services.
For Windows 2000, Windows XP, and .NET Server: click Administrative Tools, and then click Services.
b. Double-click IIS Admin Service.
c. On the Log On tab, select the Allow Service to Interact with Desktop check box.
Note: This article assumes that the IIS Admin Service runs as a local system.
d. Stop and restart the IIS Admin Service.
Then you need to change you Application Pool Identity to Local Service. Start and Stop Application Pool and Website.
Then this will work
I am asking about the account of the user which run the ASP.NET/IIS (or Cassini or IIS Express) application. I am asking about the defaults. There is very much confusion out there. Googling shows me lot of types of users, for example,
my-computer-name\myname user,
IIS APPPOOL\ASP.NET v4 user,
IIS_WPG,
IIS_IUSRS user,
Network service user,
AspNet user,
IUSR_MachineName user,
IIS_IUSRS user,
IUSR user,
IIS_WPG user,
IWAM_computername user,
IIS APPPOOL\DefaultAppPool user.
These are quite confusing.
Cassini runs under account that started VS. So default would be currently logged windows user, runas will run under specific user account.
Application on IIS runs using application pool. Here is snipp from default site:
Every Application pool can be configured using Advanced settings:
I should also point out possible impersonation, where context runs under impersonated user. This user can be provided by IIS or using code. Here is sample how to configure IIS impersonation (Authentication tab for specific app):
Hope this helps!
Well, for one this is different based on the version of Windows that you are running. And second, you are asking about 3 different servers. So that is probably what is making it confusing.
Development servers
First, the easiest one: Cassini. This server runs under the same account and with the same privileges as the Visual Studio instance that it's started from. Usually, this is just your own Windows account.
IIS Express uses the exact same code-base as IIS, but it will run under your own Windows account as well, the same account that started Visual Studio (or Web Matrix for that matter).
IIS 6.0
Now for IIS proper. Here you may find many accounts. First of all, the 'old' IIS 6.0 that you will still find on Windows Server 2003 machines would use the following accounts:
Network Service (default and recommended worker processes identity for application pools in IIS 6.0 and above)
Local Service (pretty limited access)
Local System (used for the worker process when running in 'IIS 5.0 isolation mode', member of Administrators and has full access)
IIS_WPG (short for Worker Process Group, not an account, but a group, worker process identities should be member of this group, to get minimal required permissions)
IUSR_ComputerName (not used for a worker process, but rather to map anonymous visitors to a Windows account)
IWAM_{ComputerName} (for IIS 5.0 isolation mode, you'd typically use application pools for isolation nowadays)
ASPNET (also for IIS 5.0 isolation mode, it looks like the ASP.NET account, but in most cases it isn't)
(This list is based on the TechNet article IIS and Built-in Accounts (IIS 6.0).)
IIS 7 and above
For IIS 7, some of these listed above are no longer relevant, and some are replaced. Since these accounts are built-in to Windows, they have the same SSID everywhere, which may come in handy now and then.
If you upgraded a server from Windows 2003 to Windows 2008, of if you install IIS 6.0 compatibility features or older IIS components, you may have the old and the new accounts on one machine.
IUSR (*replaces IUSR_{ComputerName}, so used to map anonymous users by default*)
IIS_IUSRS (*replaces the IIS_WPG group, and so is not an account but rather a group*)
(This is based on the article Understanding Built-In User and Group Accounts in IIS 7.)
AppPool identities (since IIS 7.0)
This list is now almost complete, but we still need to understand a special type of account: the 'dynamic' AppPool identities. These are not actual accounts on the machine like the others, e.g. you can't find them listed as users in Windows. But they are virtual accounts created on the fly for the application pools, if you choose the ApplicationPoolIdentity option.
If you need to give such an account access privileges to a file or folder, you can still search for the account by typing: IIS AppPool{DefaultAppPool} (replace {DefaultAppPool} with the name of the application pool that you created).
(You can read more about this in Application Pool Identities on iis.net.)
When you install .NET 4.0, then IIS adds a new application pool to be able to run new .NET 4.0 web applications alongside the existing .NET 2.0 web applications. The installer gives this application pool the name ASP.NET v4.0, and uses the option ApplicationPoolIdentity. Hence a dynamic account is created for this new application pool, whether you use it or not.
I have an issue with our ASP.net application not being able to read files from a remote directory. Our users log into our application using Forms Authentication, so no AD accounts are used in logging them in.
I have added the machine accounts the machines to the share, as I have a local service on the machine that can write to it and a SQL server able to read/write to the share with a machine account.
However, our asp.net app, running on the same server as the service above, is is not able to do this. I have tried impersonation set to true, but this does not work unless I provide an AD account. Once provided, the share works fine.
I can't move the share to the IIS server due to size constraints.
Is there anyway to allow easy access or do I need to take the interop approach?
The account the application pool runs under needs access on the remote folder. Add that account to the security tab(not only share tab) of the remote folder.
Or, try running the apppool as the AD account you used for impersonation.
I'm a bit confused about how ASP.NET, what user it runs under? On iis 7.5 and on 6.0
A few of the user accounts that I'm not clear on are
Network Service
IUSR
AppPool
Any clarification on the different users would be appreciated and security considerations/etc.
In summary:
IIS 5.1 (Windows XP) - it's a local ASPNET account
IIS 6 - by default, application pools run under the Network Service account which is a member of IIS_WPG group
IIS 7.0 - still Network Service
IIS 7 SP2 / 7.5 - runs under an ephemeral thing called ApplicationPoolIdentity which maps to an account IIS APPPOOL\ApplicationPool (e.g. IIS APPPOOL\DefaultAppPool). This account is a member of IIS_IUSRS user group
ASP.NET Web Development Server (Cassini) - it's obviously your own account
And it's a good practice to create a custom low-privileged account to run your application especially on PROD environment or when you need to access the network from the application.
ASP.net by default runs underneath the IIS_IUSRS user group. So if you need to grant permission to allow your application to run, use that group.