We are having some problems configuring a web service and would greatly appreciate some guidance.
We have developed a web service using VS2008. The web service accesses a SQL Server database and returns a result set. The connection string is encrypted and stored in a machine-level store for the calling assembly isolated storage file in XML format. The web service is deployed to computers running IIS 7 and above using the Visual Studio 2008 Web Setup Project template.
When deployed to Windows Server 2008 and Vista (IIS 7.0) using the “Classic .Net AppPool” application pool the web service functions as expected. When deployed to Windows 7 (IIS 7.5) using the same application pool the web service fails with the error “Access to path ‘*’ is denied” when an attempt is made to access the isolated storage file containing the encrypted connection string.
The problem seems to revolve around the application pool identity. Using IIS 7.0 the default for the “Classic .Net AppPool” is “NetworkService”. Using IIS 7.5 the default is “ApplicationPoolIdentity”. If we change the Identity to “NetworkService” for the “Classic .Net AppPool” within IIS 7.5 running on Windows 7, the web service succeeds. However, this configuration appears to be in direct contravention to the articles identified immediately below. Incidentally, if we change the “Classic .Net AppPool” Identity to “ApplicationPoolIdentity” within IIS 7.0 running on Vista, the web service also succeeds (unlike Windows 7).
The article found here http://learn.iis.net/page.aspx/624/application-pool-identities indicates the introduction of a new IIS security feature as part of Windows Server 2008 SP2 and Windows Vista SP2 and that "If you are running Windows Server 2008 (and presumably Windows Vista), you have to change the IdentityType property of the Application Pools you create to "AppPoolIdentity”.
This article here http://learn.iis.net/page.aspx/764/ensure-security-isolation-for-web-sites recommends “Separating applications into multiple application pools not only can improve performance but also improves server and site reliability”
My questions are...
1. On Windows 7 (64 bit) should the built-in account represented by the ApplicationPoolIdentity (for the Classic .Net appPool) have the same permissions as the NETWORKSERVICE account to access the isolated storage file containing the encrypted connection string?
2. Are the DefaultAppPool and Classic .Net AppPool application pools now redundant / illegal to use? Should our web services have their own application pool in both IIS 7.0 and IIS 7.5?
3. Are there any guidance notes / articles about how to configure a Visual Studio Web Setup Project to meet these security provisions? It is my belief that the msi generated by a Visual Studio 2008 Web Setup Project template using the default values do not meet the security provisions for Application Pool Identities or creating an application pool for the application being installed (of course I could be wrong!).
I'm guessing that we will need custom actions, .NET installer classes and/or VC++ setup dlls. However, for a simple web service of less than 20 lines of code I’m hoping that the code for the setup program would be just as simple, and that I can avoid the inner workings of IIS 7.0/7.5. Perhaps a vain hope!
Tuesday, February 21, 2012 9:20 PM
- Edited by stephengraham Tuesday, February 21, 2012 9:35 PM
This problem has been resolved by uninstalling IIS and re-installing using only the default settings. To anyone else experiencing the same problem, regret I cannot explain why, but the ApplicationPoolIdentity now appears to be working as expected and calls to the deployed web service are now returning result sets from SQL Server.
Monday, March 05, 2012 10:45 AM
- Marked as answer by stephengraham Monday, March 05, 2012 10:45 AM