HOWTO: Use IIsWebFile to fine grain control IIS behavior

  • Article

A relatively unknown and unadvertised behavior of IIS is that its features are often more granular than exposed via the IIS Manager UI. In other words, the UI constrains you to a pre-determined set of supported and often-used scenarios, both for your safety (remember, we actually want to allow non-admins to use IIS) and ours.

However, if you really understand IIS behavior and configuration, you can take on some "extra" responsibility and do some nifty and non-obvious things...

Question:

Is it possible to implement in SSL in specific web page. Can you give a details or example.. Is really require separate virtual directory for secured and unsecured pages.

Answer:

Yes, it is absolutely possible to mix secured and unsecured pages within the same virtual directory.

The IIS configuration concept which supports this is called IIsWebFile.

The concept is completely analogous to the NTFS filesystem: you can set ACLs and properties on folders and files which exist in the physical filesystem namespace. With the IIS metabase, you can set Access permissions, SSL requirements, Custom Errors, etc on redirected virtual folders (IIsWebVirtualDir), virtual folders (IIsWebDirectory), virtual files (IIsWebFile) which exist in the URL namespace.

In this case, the configuration is actually sitting right there in the UI, but you probably did not notice it because the concept is a bit advanced and not often advertised. I will show where this is in the UI, and also show how the concept works with the ADSUTIL.VBS commandline tool

IIsWebFile from the IIS Manager UI

IIsWebFile is exposed in the IIS Manager UI whenever you select a website/web app/virtual directory in the left pane and then right-click properties on a filename in the right pane. The resulting property sheet is for a given file resource, and that is an IIsWebFile.

In your case, you want a certain web page to require SSL but not any others. What you do is:

  1. Setup SSL for that website by assigning a Server Certificate and configuring an SSL IP:Port. You do not need to enforce SSL anywhere - just set it up for the website such that it CAN support SSL. SelfSSL is an easy way to accomplish this.
  2. Create a virtual directory that points to your web pages. It obviously does not require SSL.
  3. Select this virtual directory on the left pane, and right-click properties on the web page that is supposed to require SSL. This pops up a property sheet for the web page.
  4. Navigate to the "File Security" tab and you should see the Edit button of "Secure communications" enabled. Click on it.
  5. Select "Require secure channel (SSL) and optionally require 128bit encryption. OK out of everything.

You now should have a virtual directory which does not require SSL except for that one web page.

IIsWebFile with ADSUTIL

The configuration using ADSUTIL is simple. You still have to first setup SSL for that website as described earlier.

In my commandlines below, I am assuming that the website ID is "1", the virtual directory containing the web pages is "vdir", and the web page that requires SSL is "SecuredPage.asp".

 CSCRIPT %SYSTEMDRIVE%\Inetpub\AdminScripts\adsutil.vbs CREATE W3SVC/1/ROOT/vdir/SecuredPage.asp IIsWebFile
CSCRIPT %SYSTEMDRIVE%\Inetpub\AdminScripts\adsutil.vbs SET W3SVC/1/ROOT/vdir/SecuredPage.asp/AccessSSLFlags 264

According to documentation for AccessSSLFlags (a bit field flag), "8" means to enable SSL, and "256" means to require 128bit SSL, so 256+8="264" means to enable and require 128bit SSL.

In Closing...

The astute reader should realize that ADSUTIL opens up an interesting possibility... what happens if you create a IIsWebFile that does NOT have a physical file backing? The UI constrains you to only create IIsWebFile for existing physical files exposed in the virtual URL namespace, but if you directly modify IIS configuration with ADSUTIL, you can actually create IIsWebFile for non-existing files.

And what about IIsWebDirectory, and how does it differ from IIsWebVirtualDir?

Well, these topics will be for future discussions, as they can also allow you to do some pretty nifty things...

//David