I've created an IIS administration tool designed to create new applications, assign them to a new AppPool, and add required folder ACLs for the identity associated with that AppPool. According to this article, Whenever a new Application Pool is created, the IIS management process creates a security identifier (SID) that represents the name of the Application Pool itself.
But that doesn't appear to be the case on my Windows 8 Pro machine (IIS8). The SID is only being created once an application associated with the AppPool starts. This is making the task of setting folder ACLs quite difficult, the application needs to start before the AppPool identity is created, but the application won't work unless the ACLs are set... chicken and the egg.
What's going on here? Is there a bug on my Win8 machine? Is this Win8 / IIS8 behaviour in general? I'm having no issues on Server 2008 R2 (IIS 7.5), where it does create the AppPool identity SID as soon as the AppPool is created in IIS.
I'm aware there is an indeterminate delay between the time the AppPool is created and the SID is created. This is generally less than a second. In this instance, the delay appears indefinite (several minutes later, the SID still does not exist).
It would seem that the SID is only created once the process is running. I have a related problem where the registry hive under HKEY_USERS completely disappears after a reboot. Tests indicate that the registry hive returns fully intact as soon as my web service starts (i.e. on first request) with the same SID and contents fully restored, so I guess that once you have obtained the SID for the first time you can use it for the same purposes even if it doesn't yet exist after a restart. Getting the security system to believe you havn't made a mistake with naming may still be an issue though.
Related
I've moved my codebase to a new directory and need to grant the IIS account read/write privileges on a few folders to allow access by the ASP.Net runtime. I believe NETWORKSERVICE is no longer used for this purpose (as mentioned in this earlier question:
ASP.Net which user account running Web Service on IIS 7?) but, try as I might I can't seem to be able to add the IISAppPool/IIS Worker Process the article links to.
I've found a MyDomain/IIS_WPG account but this isn't the one that is listed in Task Manager for the w3wp process. Can someone help?
UPDATE:
Even odder - the Application Pool for the website in question uses the LocalSystem identity which I thought would be able to access pretty much the entire machine. Is there something incorrect about my basic machine/Windows setup?
I've a feeling it's something to do with the permissions of the AppPool but as this app is hosted in Azure it's not possible to change that.
My code works in a console app and when the AppPool is set to run as a user (myself). It fails to run when the AppPool is set to run as ApplicationIdentity and when the service is hosted in Azure (I'll post the code if requested, but I don't think that's where the problem lies).
It doesn't matter whether I load the certificate from a store, from a file, or from a byte array. The results are the same.
I don't know what information will be helpful in diagnosing this but it appears that the chain/path doesn't load under the reduced privileges. Calling .Verify() returns true in the console app (and IIS running as my user) and false under ApplicationIdentity.
The certificate appears to load normally and contains a private key in both circumstances.
It turns out my problem was the same listed in this question. I needed to set my certificates up so that some of them were in the CA and Trust section so that the chain was built correctly.
I had all of the certificates installed but it would appear that the location of the certificate is important as well, and it was nothing to do with security or which user was logged on at all!
You can change almost anything in Azure. It is full IIS (if you are not upgrading from SDK 1.3 or earlier) by default. There are couple of options to try:
(This one is wrong! Noted by Steve Marx)Try jus trunning the application (in this case IIS AppPool) in Elevated mode. That will make AppPool running under "SYSTEM" account, instead of AppPoolIdentity. You can do that by adding a <runtime executionContext="elevated" /> element in your role definition in .CSDEF file.
You can enable remote desktop to all your roles. That will effectively create an account in your role instance and add it to the Administrators group. Then you can use a startup task and powershell script to change AppPool identity to use that account instead: A blog post by Wade Wegner on how to programatically change AppPool Identity.
Well, these all are ways to make your application pool runs in Elevated mode, but also show that you can do pretty much everything with IIS on your Windows Azure Instance. I suggest to use site runing in elevated mode only for testing purposes. First make your code run in restricted account on local IIS. Then see what you changed to make it wokrk locally and apply these changes on the Azure Web Role.
EDIT
Another thing to pay attention is that in order .Verify() to work, you must have the Root Certificate of the CA that issued the checked certificate, installed on the web role. This can be done via adding the Root CA Certificate as a "Service Certificate" from the management portal. Also, the CA that issued the checked certificated must be trusted.
I'm running Windows 7 SP 1 and have just turned on IIS 7. Just trying to access the default page it creates I get a 503 error, and the application pool stops. I look in the event log and I find the error:
Windows cannot copy file \?\C:\Users\Default\AppData\Local\Microsoft\Windows\Temporary Internet Files\SQM\iesqmdata_setup0.sqm to location \?\C:\Users\TEMP.IIS APPPOOL.000\AppData\Local\Microsoft\Windows\Temporary Internet Files\SQM\iesqmdata_setup0.sqm. This error may be caused by network problems or insufficient security rights.
DETAIL - Access is denied.
I tried making the TEMP.IIS APPPOOOL.000 folder available to everyone. I tried making Users available to everyone. No luck, it still dies with the same error.
What is happening here, and how can it be fixed?
It sounds like you're having the same problem as details in this IIS.NET forums thread. You didn't mention if you have x64 Windows 7 or not. Suspect that your development machine is misconfigured somehow; sounds like the uninstallation and reinstallation of IIS7 would help/fix.
Suggested courses of action:
Open IIS and its Application Pools. Open "DefaultAppPool" and any other Application Pools in use.
Click Advanced Settings for each of these. Ensure the "Load User Profile" is set to 'False'
Also ensure that the "Set Application Pool Defaults" has the Load User Profile set to False."
I encountered the same problem in my development environment (Windows 8.1). Instead of disabling the load user profile as suggested by P.Campbell, I went ahead and changed the permission of the sqm file to allow modify accesses for IUSR, IIS_IUSRS and Network Service. In my case, the sqm file was not able to show me the file owner in which I taken over with my user account.
Basically, my problem was solved by giving the correct permission for both source and destination files/folders.
Found the answer here - http://forums.iis.net/p/1180636/1992024.aspx
Open IIS Manager
Find the App Pool that is causing the problem
Open Advanced Properties
Change 'Load User Profile' to false
Fixed!
After struggling with all these Application Pool issues in IIs, I found the problem and the solution. This may help you.
Each application pool on each website in Microsoft's Internet Information Server creates its own user account and folder under the "c:\Users" directory when the pool is created and first run. Its actually a virtual user account and should be named for the Application Pool assigned to your web application in IIs. In most development environments, its the default website or "DefaultAppPool". It uses this temporary user account to run the pool. Each website should have a named user pool account. This User folder is used by the pool and ASP.NET for caching and writing of file resources and other things used by IIs, ASP.NET, and this virtual account.
In some setups people are not seeing this folder but a "TEMP" folder (like you have) when the IIs web site is accessed and using the pool.
If you instead see a "TEMP" folder in the Users folder you have a broken application pool account in IIs and in the Registry. The pool is creating the TEMP folder as a backup for this virtual account, which might not have the right security setup. I had this exact scenario.
To fix it go to the registry under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
See if you have a SID user account with the ".bak" extension for a DefaultAppPool user account. If so delete it and restart your PC. Test your website again, making sure its actually setup to use DefaulAppPool. It should now recreate the "DefaultAppPool" folder in Users, recreate the registry entry for DefaulAppPool user, and your error should go away.
You can delete the TEMP user folder at that point under the Users folder. (Keep in mind if your web app has been storing cached information critical to users of the website, some of that might have to be inserted into the new DefaultAppPool user folder. But for most of us, just delete it.)
I also found I had to add this kooky virtual application pool account to my local database so the worker process and app pool accnt could have the rights to grab data from SQL Server: Just go into SQL Server and under logins add "IIs AppPool\DefaultAppPool" and then assign it as a user to your databases.
(btw whomever dreamed up this virtual application pool account system is nuts....its way too complicated and convoluted to sort out)
After I did this, all my stack overflow errors went away in Visual Studio for my web application, all data connections fired perfectly, all write permission to the default User profile stored properly, and all the restarting and crashing of the Application Pool in IIs ended completely. :)
Is it necessary to restart IIS in order to ensure that changes to azman.xml are picked up, or will IIS figure out that the permissions in azman.xml have been changed?
You don't say how you're using AzMan. Are you using it as a Role Management Provider?
At any rate, you (almost) never have to fully restart IIS; just recycle the app pool.
But to answer your question (assuming you did mean Authorization Store Role Provider), IIS (actually, the provider) should check for changes according to your setting for the CacheRefreshInterval property. The default is 60 minutes.
I'm creating a website in IIS 7.5 (with Windows 7) that needs to be able to create further websites. I've written code that uses Microsoft.Web.Administration to create the website programmatically, and this works fine when I run it as administrator.
Now I'm trying to use the same code in the context of my web application. It fails with the error
Error: Cannot read configuration file due to insufficient permissions
for the file redirection.config (which I understand is located in %WinDir%/System32/inetsrv/config).
I've tried creating a new apppool for this specific website, running under the IIS AppPool[AppPoolName] identity. I've then tried to grant that identity permission to edit the IIS config using
ManagementAuthorization.Grant(#"IIS AppPool\MyAppPool", "Default Web Site", false);
but I still get the same error.
What else should I try?
This probably isn't the wisest approach from a security viewpoint. If this site is hijacked then your attackers will be able to interfere with those files (to no good purpose) or even just delete them.
The way we approached this was to separate website creation tasks into a windows service running with the correct rights to perform these activities. In this service is a remoting end point (although these days you'd probably want to use WCF).
We then created a proxy assembly that is signed and registered in the GAC (it would also need to be marked with the APTCA attribute if you're running at less than Full Trust). This assembly passes on the relevant calls to the remoting endpoint in the windows service from the admin web app/service.
This allows us to run the admin site at least privilege and in partial trust mode. The scope of what can be done by way of site admin tasks is narrowed somewhat by whatever functionality is exposed in the windows service application.
This is a technique known as sandboxing.
I've found a way to do it, but I would very much like to hear expert opinion on whether this is a wise thing to do.
I granted Modify and Write permissions for the IIS AppPool\MyAppPool account to %WinDir%/System32/inetsrv/config and the three .config files inside it.