Freigeben über

Security considerations of UseSharedWPDesktop on IIS6

  • Artikel

Question:

In the section "Number of Application Pools That Can Be Configured" of the document: https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/appisoa.mspx

The following statement suggests that we should use a common desktop when the number of application pools configured on a server is greater than 60.
"This may be configured by setting the registry key HKLM\System\CurrentControlSet\Services\W3SVC\Parameters\UseSharedWPDesktop to 1. When this setting is enabled, application pools share a common desktop, thereby increasing scalability."

What are the security considerations associated with making this change? Is there any sensitive data that will be shared by applications across application pools once all pools are using a common desktop? If so, is this worse than keeping the WPDesktop value at 0 and having all application pools launch as "Network Service", instead of each giving them their own identity?

Thanks,

Answer:

Good question... let me try to clarify what the URL is trying to say, and hopefully it makes sense. :-)

To be clear, the URL does NOT suggest that "we should use a common desktop when the number of application pools configured on a server is greater than 60".

Quote:

Microsoft tests show that when configuring more than 60 application pools with unique identities, a shared desktop should be used

My interpretation of the statement is that "we should use a common desktop when the number of application pools with unique identities configured on a server is greater than 60". In other words, IIS does not have a problem running >60 application pools which uses <60 unique identities. The limitation in question is the number of user desktops associated with each unique application pool identity that Windows simultaneously supports.

The following are the interesting combinations and consequences:

  1. If UseSharedWPDesktop=0 and all application pools launch as Network Service, then there is exactly one Desktop (of Network Service) shared by all the application pools. You have no isolation of desktop nor process identity between application pools.
  2. If UseSharedWPDesktop=0 and all application pools launch as unique user identity, then there is a unique Desktop for each user identity, which is obviously not shared. This is limited to a number around 60 due to Desktop heap limit in Windows Server 2003. This means that you can only have ~60 application pools perfectly isolated by desktop and process identity simultaneously running.
  3. If UseSharedWPDesktop=1 and all application pools launch as unique user identity, then there is one Desktop that is shared by all the user identities. This removes the limit of 60 at the cost of not perfectly isolated application pools. You have no desktop isolation but retain process identity isolation between application pools.
  4. UseSharedWPDesktop=1 and all application pools launch as Network Service is pretty much a degenerate case that is not interesting. :-)

Obviously, the security considerations are for you to consider... that is why there is a choice. :-) IIS itself has no sensitive data to share in the desktop, but security-paranoid administrators tend to not want processes of different application pool to share anything to prevent the potential of having desktop shatter attacks and the like.

As you can see, the difference between #1 and #3 is that application pool identities are different, thus offering process identity isolation. If sharing the desktop is ok for you, then #3 is a reasonable compromise to obtain process identity isolation without the limitation of ~60 unique identities imposed by Windows.

Finally, on Windows Vista, the Desktop heap limit disappears due to the introduction of a new Dynamic Memory Architecture, so achieving the true isolation of #2 is a non-issue for IIS7. You can simultaneously run as many application pools with unique user identities as your physical memory allows, all perfectly isolated.

//David

Comments

  • Anonymous
    November 26, 2008
    The comment has been removed

  • Anonymous
    November 27, 2008
    jaskis - IIS does not spawn inetinfo.exe as 32bit on 64bit Windows, so your question does not have relation. However, 64bit Windows has the same memory manager as Vista, so it behaves likewise as explained in the blog entry. //David

  • Anonymous
    December 09, 2008
    We've set Enable32BitAppOnWin64=true in IIS 6 metabase , so that w3wp run under 32bitness. We have 250+ w3wp each spawned on unique identity. In this scenario: Will DesktopHeap will be effected same way as in case of x86 OS? Thanks Jas

  • Anonymous
    May 07, 2009
    This setting and related information is also referenced in Microsoft Knowledge Base article 831135 and applies to 32-bit and 64-bit versions of IIS 6 and IIS 7: Clients receive a "service unavailable" error message in their Web browsers when you run many application pools under separate identities in IIS http://support.microsoft.com/kb/831135 Josh

  • Anonymous
    August 25, 2009
    You can also increase the amount of memory 2003 allocates for desktop heap. HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management Add: Name: SessionViewSize Data Type: REG_DWORD Value data: 120 (decimal) Add: Name: SessionPoolSize Data Type: REG_DWORD Value data: 60 (decimal) HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerSubsytems

  1.  Find value "Windows" and Set "SharedSelection" section to  "1024,3072,8192" without the quotes.  (the 3rd number is non-shared heap and defaults to 512).