Scott Forsyth's Blog

August 2008 - Posts

  • IIS, Windows Authentication and the Double Hop issue

    In IIS, you run into an interesting situation when you need to access another resource off of the IIS server and certain fairly common situations occur.  When using Integrated Security, anonymous access is disabled, and impersonation is turned on, a security measure kicks in and doesn't allow your site to access resources on any network servers.  This includes access to a UNC path directly from IIS or SQL Server using Windows authentication.

    The reason is because of a 'double hop' that authentication is doing.  When you authenticate to the IIS server using Integrated Authentication, that uses up your first 'hop'.  When IIS tries to access a network device, that would be the double or second hop which is not allowed.  IIS cannot in turn pass on those credentials to the next network device, otherwise the developer or administrator could abuse your credentials and use them in ways that the site visitor didn't anticipate.

    This doesn't occur with anonymous access or with impersonation off because in that case IIS takes care of authenticating you and then it uses a different user for local or network access.  This means that the app pool identity or anonymous user can make a network call as the first hop.

    Anyway, I didn't mean to even write that much since the following blog post answers this well already, and includes the three most common solutions.  I wanted to blog this as a reference point for anyone running into this authentication issue, and so that I have a reference to it myself.  I'll let Numos complete the story:

    http://blogs.msdn.com/nunos/archive/2004/03/12/88468.aspx

     

  • Application Pool Recycles from IIS 7 Setting Changes

    I've written a couple times about what configuration changes cause AppDomain recycles.  Most recently how the ASP.NET tab causes a server-wide AppDomain recycle, and previously about changes in ASP.NET 2.0.

    Here I'm going to cover things that, when done in IIS 7, will cause a full application pool recycle.  I obtained the following list from the Microsoft.com folk at Microsoft.  They worked with the IIS team during IIS 7 development to get a complete list of all settings which cause full app pool recycles.  What this means is that if you make changes to applicationHost.config that touches anything in the following list, the applicable application pool will be recycled.  If you change other settings to applicationHost.config, the app pools on the server will remain unaffected.

    Note: It's important to realize that an application pool in IIS is different than an AppDomain in ASP.NET.  The previous blog posts were about AppDomain recycles, but this one is about application pool recycles. 

    Windows Activation Process Service (WAS) recycles an application pool if you change the configuration of any of the following:

    • Restart parameters (for example, restart time, number of requests, and scheduled memory)
    • Idle timeout
    • Ping interval
    • Startup and shutdown time limit
    • Orphan action
    • CLR version
    • Pipeline mode
    • A 32 to 64 bit worker process
    • Job objects (for example, CPU limit)
    • CPU affinity
    • Worker process identity

    Essentially this means that virtually any change to the application pool settings will cause it to immediately recycle, so be careful when making a change to an app pool.  This applies when using IIS Manager, any of the programming APIs or if you edit applicationHost.config directly.  You may need to schedule to setting change off hours if you don't want a recycle to occur at an inopportune time.  Changes to global settings will not cause the application pools on the server to recycle.

     

  • ASP.NET tab in IIS, more dangerous than it first appears!

    This blog post was a long time coming and fortunately doesn't apply to IIS7, but I thought I would finally take a few minutes and cover this shortcoming with the ASPNET tab that ASP.NET 2.0 introduced into IIS 6 and IIS 5.

    As I've covered in a previous post, only 1 version of ASP.NET can run at a time in each IIS Application Pool.  When you want to target a newer or older version of the ASP.NET framework for a particular site or application, you must update that website or application.

    When ASP.NET 1.1 was released

    When ASP.NET 1.1 was released, the common way to do this was to use aspnet_regiis.exe from the command line.  There was a serious shortcoming with that method though, as I detailed back in December of '03.  (That article and attached script is long overdue for a revision which I'll cover later in this blog post.)  The essence of what I said, and gave a sample script for, is that if you use aspnet_regiis.exe, it will cause an AppDomain recycle on ALL AppDomains on the server, even if you target a single site.  This means that on a production server, it is not safe to use aspnet_regiis outside of a scheduled maintenance window unless you don't mind the impact of an AppDomain recycle.  (for more information on what an AppDomain recycle is and what the impact is, check out this blog post)  The alternate is to change all of the script mappings manually, which properly changes the framework version but has zero impact on other sites on the same server.

    When ASP.NET 2.0 was released

    When ASP.NET 2.0 was released, Microsoft provided a new tab in IIS called "ASP.NET" as seen in the following screenshot:

    ASP.NET tab

    At first this appears to be a welcome addition, and for development computers, it really is.  The issue is this:

    The ASP.NET tab in IIS 5 and IIS 6 uses the aspnet_regiis.exe command in the background and, if used, will cause a full AppDomain recycle on the *entire server*.

    It's not what most people would expect, and there is no warning provided, so be very careful about this.  In fact, you may survive an AppDomain recycle without having anyone complain.  Therefore, I'm sure oodles of people use this tab on production servers without realizing that they are blowing away InProc session state, causing slow first loads on the pages, and, for sites that take a long time to start up after an AppDomain recycle, possibly causing downtime.

    At ORCS Web, when v2.0 came out, I cleaned up the script to handle more than 2 versions of the framework and to I made some other enhancements, but I never got around to blogging about it because there were some features that I wanted to add.  The two features that it's lacking the most are 1) you have to manually enter the site ID rather than getting to pick from a list, and 2) it doesn't support changing the framework version for subfolders.  I kept telling myself I would spend 1/2 a day and finish this, but never got around to it.  So, I'll include it here, and if it interests anyone, feel free to use it.  We've been running it in production for years and it works just great, but it could stand for some further improvements.  You can download it here: Change_Framework_version.zip.  (Note: at ORCS Web we use our own control panel to change the framework version now instead of this script, but it was based on this script)

    When ASP.NET 3.0 and 3.5 was released

    ASP.NET 3.0 and 3.5 followed a new trend.  They aren't full side-by-side versions of the framework like v1.1 and v2.0 were.  Instead they are add-on extensions to ASP.NET 2.0.  So, when you set your site to use v2.0 of the framework but have ASP.NET 3.5 installed on the server, you are actually able to use all of the v2.0 - v3.5 features. 

    IIS 7

    IIS 7 allows you to set the framework version at the application pool rather than the website.  This change does not cause the server-wide impact and it is safe to do on a production server as long as you realize that the one app pool will have an AppDomain recycle.

    In summary, the ASP.NET tab should not be run on a production server except during a maintenance window.  The impact is pretty minor or non-existent for some sites, but it can be pretty bad for other sites.  Just be aware that changing the framework version from the ASP.NET causes an AppDomain recycle on the entire server.  The alternative is to manually change the script mappings which can be done using the script provided above, or manually item by item at the site or application level in IIS.

     


Powered by Community Server 2.1