Care, Share and Grow! : IIS 7.0

Considering hosting Web based services on IIS 7.0?

Saurabh Singh — Tue, 10 Mar 2009 19:35:54 GMT

If you are contemplating to move over (upgrade) to IIS 7.0 from your existing Web hosting on either IIS 5.0 or 6.0 this is a very useful Technical White Paper link. It talks about various aspects of improvements in IIS 7.0 dealing with Management, Performance, Extensibility, Security and Deployment.

Migrating a Large, High-Volume Web Site to Internet Information Services 7.0

Cheers!

Service Principal Name (SPN) checklist for Kerberos authentication with IIS 7.0

Saurabh Singh — Thu, 25 Dec 2008 04:01:15 GMT

In continuation to one of my earlier posts which focused on IIS 6.0 this post is more about the confusion that may arise around SPNs for setting up Kerberos authentication in IIS 7.0. IIS 7.0 has a new Kernel-mode authentication feature using which the ticket for the requested service is decrypted using Machine account (Local system) of the IIS server. It no longer depends upon the application pool Identity for this purpose by default and in turn improves the performance.

Here is how it looks like.

So what does this mean?

You no longer need to worry about the correlation between HTTP SPNs and the Application pool Identity that was required in the earlier version i.e. IIS 6.0. But that's not blindly true. There has been some confusion whether we don't have to care at all about SPNs or may have to depending upon the settings. Here is a checklist to give more clarity for different scenarios that you may fall under:

SCENARIO 1a

IIS 7.0 Web Site/Application
Authentication	Integrated Windows authentication
Application Pool Identity	NETWORK SERVICE
Kernel-Mode authentication	Enabled (<attribute name="useKernelMode" type="bool" defaultValue="true" /> in the ApplicationHost.config file)
Site URL	Accessed with the NetBIOS name, like http://<myIISserver-NetBIOS-name>/Default.aspx

SPNs will be required ONLY for the IIS machine account:

HOST/<myIISserver-NetBIOS-name>

HOST/<myIISserver-NetBIOS-name.fully-qualified-domainname> for e.g. HOST/myIISserver.mydomain.com

***Note: By default HOST/<myIISserver-NetBIOS-name> and HOST/<myIISserver-NetBIOS-name.fully-qualified-name> is already added for the machine account when a machine is added to a domain and HTTP forms a part of HOST. So you may not have to do anything special here for SPNs. Everything should be set by default.

You can check the set of existing SPNs for the machine account by running the following command:

> Setspn.exe -L <myIISserver-NetBIOS-name> or directly using a Snap-in like Adsiedit.msc.

SCENARIO 1b

IIS 7.0 Web Site/Application
Authentication	Integrated Windows authentication
Application Pool Identity	Custom account for e.g. Domain1\Username1
Kernel-Mode authentication	Enabled (<attribute name="useKernelMode" type="bool" defaultValue="true" /> in the ApplicationHost.config file)
Site URL	Accessed with the NetBIOS name, like http://<myIISserver-NetBIOS-name>/Default.aspx

The SPN requirements remain the same as above. You don't have to add SPNs like http/<myIISserver-NetBIOS-name> for the Domain1\Username1 unlike in IIS 6.0 (where we had to add an SPN of the form http/<myIISserver-NetBIOS-name> for the Application Pool identity).

SPNs will be required ONLY for the IIS machine account:

HOST/<myIISserver-NetBIOS-name>

HOST/<myIISserver-NetBIOS-name.fully-qualified-domainname> for e.g. HOST/myIISserver.mydomain.com

You can check the set of existing SPNs for the machine account by running the following command:

> Setspn.exe -L <myIISserver-NetBIOS-name> or directly using Snap-in like Adsiedit.msc.

SCENARIO 2a

IIS 7.0 Web Site/Application
Authentication	Integrated Windows authentication
Application Pool Identity	NETWORK SERVICE
Kernel-Mode authentication	Enabled (<attribute name="useKernelMode" type="bool" defaultValue="true" /> in the ApplicationHost.config file)
Site URL	Accessed with a Custom Host name, like http://www.mysite.com

SPNs will be required ONLY for the IIS machine account in the following format:

HTTP/<site-custom-name> for e.g. HTTP/www.mysite.com

You can add an SPN using Setspn.exe like

> Setspn -a http/<site-custom-name> <myIISserver-NetBIOS-name>

where <myIISserver-NetBIOS-name> is the IIS machine account and <site-custom-name> is the custom host/host header name for the Web Site URL.

e.g. > Setspn -a http/www.mysite.com <myIISserver-NetBIOS-name>
*The command is NOT case sensitive

You can check the existing set of SPNs for the machine account by running the following command:

> Setspn.exe -L <myIISserver-NetBIOS-name>

SCENARIO 2b

IIS 7.0 Web Site/Application
Authentication	Integrated Windows authentication
Application Pool Identity	Custom account for e.g. Domain1\Username1
Kernel-Mode authentication	Enabled (<attribute name="useKernelMode" type="bool" defaultValue="true" /> in the ApplicationHost.config file)
Site URL	Accessed with a Custom host/Host header name, like http://www.mysite.com

SPNs will be required ONLY for the IIS machine account and NOT for Domain1\Username1 account unlike in IIS 6.0.

HTTP/<site-custom-name> for e.g. HTTP/www.mysite.com

You can add an SPN using Setspn.exe like

> Setspn -a http/<site-custom-name> <myIISserver-NetBIOS-name> where <myIISserver-NetBIOS-name> is the IIS machine account and <site-custom-name> is the custom host/host header name for the Web Site URL.

e.g. > Setspn -a http/www.mysite.com <myIISserver-NetBIOS-name>
*The command is NOT case sensitive

You can check the existing set of SPNs for the machine account by running the following command:

> Setspn.exe -L <myIISserver-NetBIOS-name>

Special case of running IIS 7.0 in a WEB FARM

If you are running IIS 7.0 server in a Web farm the KDC will not know in advance which individual server the request may go to and hence ticket decryption may fail. Hence in such a scenario instead of registering SPNs under a specific machine account use a domain account. I am not a SharePoint guy but based on what I have read on the Web this scenario is also applicable to a single SharePoint server configuration.

There are two ways to go:

Either

Disable Kernel mode authentication and follow the general steps for Kerberos as in the previous IIS 6.0 version. Refer this.

Or,

[Recommended for Performance reasons]

Let Kernel mode authentication be enabled and the Application pool's identity be used for Kerberos ticket decryption. The only thing you need to do here is:

1. Run the Application pool under a common custom domain account.

2. Add this attribute "useAppPoolCredentials" in the ApplicationHost.config file.

<system.webServer>
   <security>
      <authentication>
         <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />
      </authentication>
   </security>
</system.webServer>

Remember there is no GUI setting for this. You need to modify the ApplicationHost.config file from

<%SystemDrive%>/Windows/System32/inetsrv/config folder on the IIS 7.0 machine.

3. Add the SPNs in the form:

http/<virtualhost-name> and

http/<virtualhost-name.fully-qualified-name> for the Application Pool Identity.

Ensure that we don't have such an entry for SPNs for any other account including IIS server machine account.

***If we have the same SPN mapped to multiple accounts (be it a machine or an user account) it leads to Duplicate SPNs and will break Kerberos.

Hope this helps!

FTP changes not taking effect in IIS 7.0?

Saurabh Singh — Fri, 21 Nov 2008 23:47:53 GMT

I was working on an FTP issue the other day on IIS 7.0 and I missed something very basic which could have resolved my issue way back had I noticed the nuances of this new model. Normally people tend to go ahead with restarting IIS services for some changes done in the configuration to make sure everything is fresh. Like running IISRESET from the cmd prompt or Restarting IIS services from the IIS manager itself. But in IIS 7.0 if you want to restart FTP services ensure you don't go by the above. This will restart IISADMIN, WAS and W3SVC services but not FTPSVC. IIS 7.0 OOB Secure FTP module runs under a separate process Svchost.exe. So doing an IISRESET won't help for FTP changes to take effect.

Ensure you run these two commands instead:

Start -> Run -> cmd

At the cmd prompt:

>net stop ftpsvc
The Microsoft FTP Service service is stopping.
The Microsoft FTP Service service was stopped successfully.

>net start ftpsvc
The Microsoft FTP Service service is starting.
The Microsoft FTP Service service was started successfully.

Hope this helps one who may have unnoticed this change.

Troubleshooting TS Gateway connectivity on Windows 2008, IIS 7.0

Saurabh Singh — Sat, 30 Aug 2008 07:27:00 GMT

Here is something which is not my domain but had to learn the hard way. I recently encountered an issue while enabling Terminal Services Gateway (TSG) on Windows 2008 server. TSG is coupled with IIS 7.0 hosted on Windows 2k8 server and that's how I came into picture. TSG in simple terms is a feature using which one can connect remotely to an internal network over secure HTTPS port 443 from the Internet. Earlier Remote Desktop Protocol (RDP) connections used TCP port 3389. In many corporate environment this port may be blocked by the firewall. However now with TSG connecting on port 443 (common SSL port for http traffic) user should not get into the common issues of port being blocked. In my case we had the TSG installed as one of the roles on the server. The setup was fine.
The only concern was that we already were using the Default Web site for some application. It can also happen otherwise, you have the TSG setup on an IIS 7 web site and if you go ahead and install let's say Exchange on top of it under the same site it may break the TSG functionality.

When you install TSG, it creates two virtual directories called Rpc and RpcWithCert under the web site as shown below.

Under the hood it appears a call is made for

http://<server-name>:443/rpc/rpcproxy.dll?localhost:3388 when you try to connect through TSG. So yes IIS is very much involved here.

Now what can you do to fix this, perhaps you can install your web application (say Exchange) on some other web site and a different SSL port like 444 and have TSG site listening on port 443. Or else just the opposite.

In my case we went with the 2nd option since we didn't want Exchange to be reinstalled again.
But even if you use either of the above options it may not go that smoothly as it looks to be.

You may see the error as shown below when you try to use terminal service through TSG.

Click on OK...

If you are seeing something like this, as a workaround create a new web site and copy the settings for the Virtual directories /Rpc and /RpcwithCert from the previous site to the the new web site. You can do this easily by copying the configuration in the applicationHost.config file.

Here are the steps:

1. Copy the following configuration (in the ApplicationHost.config file from C:\<Windows>\System32\inetsrv\config) from the previous site to the new site to add the virtual directories for your new web site.

<site name="<new-web-site>" id=...>
...
<application path="/Rpc" applicationPool="SomeAppPool">
       <virtualDirectory path="/" physicalPath="C:\Windows\System32\RpcProxy" />
</application>
<application path="/RpcWithCert" applicationPool="SomeAppPool">
        <virtualDirectory path="/" physicalPath="C:\Windows\System32\RpcProxy" />
</application> 
...
</site>

So this will create two virtual directories in your new web site called Rpc and RpcWithCert.

Add an SSL binding for the new Web site on port 443 as well. Ensure no other site is listening on port 443.

2. Copy the following for the previous web site in the ApplicationHost.config file to the new web site.

This is the section contained in the Location tag for the Virtual directories /Rpc and /RpcWithCert. You need to copy this section from the location tag for the <previous-web-site> and add it to the location tag for the <new-web-site>.

<location path="<previous-web-site>/Rpc">
        <system.webServer>
            <directoryBrowse enabled="false" showFlags="Date, Time, Size, Extension" />
            <handlers accessPolicy="Execute">
                <add name="RPCPROXY" path="*" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\system32\RpcProxy\RpcProxy.dll" requireAccess="Execute" />
            </handlers>
            <serverRuntime uploadReadAheadSize="0" />
            <defaultDocument enabled="true" />
            <modules>
                <add name="PasswordExpiryModule" />
            </modules>
            <security>
                <requestFiltering>
                    <requestLimits maxAllowedContentLength="2147483648" />
                </requestFiltering>
                <authentication>
                    <anonymousAuthentication enabled="false" />
                    <basicAuthentication enabled="false" />
                    <windowsAuthentication enabled="true" useKernelMode="false" />
                </authentication>
                <access sslFlags="Ssl, Ssl128" />
            </security>
            <httpErrors>
                <remove statusCode="401" />
                <error statusCode="401" path="C:\Windows\system32\RpcProxy\Error401.txt" responseMode="File" />
            </httpErrors>
        </system.webServer>
    </location>

<location path="<previous-web-site>/RpcWithCert">
        <system.webServer>
            <directoryBrowse enabled="false" showFlags="Date, Time, Size, Extension" />
            <handlers accessPolicy="Execute">
                <add name="RPCPROXY" path="*" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\system32\RpcProxy\RpcProxy.dll" requireAccess="Execute" />
            </handlers>
            <defaultDocument enabled="true" />
            <security>
                <authentication>
                    <anonymousAuthentication enabled="false" />
                    <basicAuthentication enabled="false" />
                    <clientCertificateMappingAuthentication enabled="true" />
                    <digestAuthentication enabled="false" />
                    <windowsAuthentication enabled="false" useKernelMode="false" />
                    <iisClientCertificateMappingAuthentication enabled="true" />
                </authentication>
                <access sslFlags="Ssl, SslNegotiateCert, SslRequireCert, Ssl128" />
                <requestFiltering>
                    <requestLimits maxAllowedContentLength="2147483648" />
                </requestFiltering>
            </security>
            <serverRuntime uploadReadAheadSize="0" />
            <modules>
                <add name="PasswordExpiryModule" />
            </modules>
            <httpErrors>
                <remove statusCode="401" />
                <error statusCode="401" path="C:\Windows\system32\RpcProxy\Error401.txt" responseMode="File" />
            </httpErrors>
        </system.webServer>
    </location>

3. Ensure that we replace <previous-web-site> with the <new-web-site> in the following tags above:

<location path="<previous-web-site>/RpcWithCert"> -----> <location path="<new-web-site>/RpcWithCert">

4. Run iisreset from the cmd prompt. Or it may also work with just restarting W3SVC service (net stop w3svc, net start w3svc).

Go ahead and test RDP over TSG from the client. If it still doesn't work you may have to try the 5th step as below.

5. Add the following registry entry. Run this from the cmd prompt:
> reg add HKLM\Software\Microsoft\RPC\RpcProxy /v Website /t REG_SZ /d <new-web-site>

One last thing, ensure that the certificate issued to the TS server gateway is trusted on the client from where we are doing a terminal login.

Happy troubleshooting!

Cheers

My IIS 7.0 Administration UI Extension Page

Saurabh Singh — Wed, 28 Nov 2007 20:24:00 GMT

The UI extension option in IIS 7.0 is an exciting feature for any .Net developer. You can write your own custom UI pages and can add various features to it to manage IIS on Windows Vista and Windows Server 2008. I have written an UI extension and is attached with this post.

I have added the IIsReset feature provided by my good friend Rakki as part of this UI module. He had blogged about it here. Besides IISRESET, I have also added an integrated browser, AppCmd.exe UI and a generic Request monitoring tab.

To add this module in your IIS 7 manager follow the steps below:

Download the ExtensibilityDemo.dll.
Drag and Drop the ExtensibilityDemo.dll into the Global Assembly Cache (C:\Windows\assembly) or use GacUtil -i ExtensibilityDemo.dll to install it to the GAC.
From the Windows Explorer, browse to the file

%WinDir%\System32\InetSrv\config\Administration.config.

4. Search for the <moduleProviders> section and add the following

<add name="ExtensibilityDemo" type="ExtensibilityDemo.DemoModuleProvider, ExtensibilityDemo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=204f1a1ad20ba534" />

You need to crosscheck that PublickKeyToken matches what is present in the GAC.

This should be same as the following in the Assembly folder:

5. Search for the <modules> section and add the following

<location path=".">
<modules>
<add name="ExtensibilityDemo" />

6. Open Inetmgr (Start Menu->Run->Inetmgr) and You will see the module listed in your IIS 7 Manager if everything went fine during the installation.

You can see the Module listed in Connections Pane as well as middle pane in its own category. If you want you can remove from the Connections Pane by right click and "remove".

Here are some screen shots for this extension:

In the central IIS manager pane (window) you should see the following:

I will be adding some new functionalities as time progresses to have more UI interface for various features. I will recommend if you are interested start developing your modules today to customize/extend IIS 7.0 features.

Good luck....

Accessing iis 7.0 features programmatically from configuration file(S) (C#)

Saurabh Singh — Sun, 25 Nov 2007 02:37:00 GMT

IIS 7.0 has great features for developers now. It is integrated with .Net. UI has completely changed from the previous versions. It has entirely a new look and feel. I feel there would be a steep learning curve for IIS users, but nothing to worry, unlike...(read more)

my first post on IIS 7.0......lot to explore yet :)

Saurabh Singh — Sat, 24 Nov 2007 01:15:00 GMT

Recently I have started exploring IIS 7.0 and one word that can express my feeling is "WOW!". IIS 7.0 is way ahead of all the previous versions of IIS. I have worked extensively with IIS 5.0/5.1/6.0 and I can say for sure, IIS 7.0 is completely in a different...(read more)