Care, Share and Grow! : Setup

Required permissions when calling a Web service using client certificate for authentication in an ASP.NET Web application

Saurabh Singh — Fri, 03 Jul 2009 04:08:04 GMT

A Web service requiring Client certificate authentication is a common scenario.

You may have a client application which needs to send the Client certificate as part of the web request for accessing the web service.

This client application may be a Windows/Console application or another Web application.

Often you will get into issues wherein you are able to send Client certificate as part of the web request from a windows/console app but not from another web app. The primary reason for this could often be around Web app not being able to send the client cert to the target Web service.

This can happen for multiple reasons, in particular account under which Web app is running doesn't have enough permissions to access the Client cert in its local certificate store.

Refer to this excellent kb for this for more details.

In this post I want to highlight ways in which you can grant access to the Web application account to access the Client certificate in its local machine store.

When we have to send client cert as part of the web service call from a web app we need to ensure that the client cert is installed in the Local Computer -> Personal Store on the local box (where Web app is running). By default you will see the client cert installed in the Local User Store for the user who requested and installed the cert on the machine. You need to ensure first that the client cert is installed on the Local Computer Store instead of the Local User Store and then follow any of the methods below to grant access to the private key for the account (under which your web app is running).

Method 1:

The above article kb gives an example of granting access using the Microsoft Windows HTTP Services Certificate Configuration Tool

> WinHttpCertCfg.exe -g -c LOCAL_MACHINE\MY -s " IssuedToName " -a " AccountName "

for e.g.

> WinHttpCertCfg.exe -g -c LOCAL_MACHINE\MY -s " IssuedToName " -a "Network Service"

There are other ways in which you can achieve the same result. This feature is in fact built in on Windows Server 2008 within the Certificate mmc console.

Method 2:

Using the WSE X509 Certificate tool (This tool has features that can be used to check certificate properties).

You need to download Web Services enhancements (WSE) 2.0+ SP3 for Microsoft.Net and in the install wizard ensure you select Tools as shown below:

Once installed go ahead and launch the tool. It has a clean UI. You have the option to check certificates in the Local Computer/Current user for the available stores like Personal/Trusted/Intermediate Root CA etc. If you click on View Private Key File Properties (shown below) you can directly modify the permission for private key associated with the certificate. Basically this is just a file under C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys on Win2k3 server and C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys on Win2k8 server.

You may want to go ahead and give the Service account under which the web app is running Full permission on this file (modify the permissions from the Security tab).

Method 3:

If you are running the web app on Windows Server 2008/Vista there is a far simpler way built in the Certificate mmc.

Right click on the certificate and go to All Tasks -> Manage Private Keys and then give Full permission for the associated account.

Till next time..

Cheers!

Getting fatal error LNK1181: cannot open input file 'kernel32.lib'

Saurabh Singh — Fri, 30 Jan 2009 10:09:38 GMT

I was a happy man until a few hours back when I was playing with some C, C++ programs built using Visual Studio 2008 on my work and home machines. I could write some program on my workstation, copy the solution to my personal laptop at home and thereby continue from where I left in office. Things were good until I installed the latest Windows SDK v6.1 on my Vista laptop while trying my hands on Windows PowerShell.

I realized a day or so later after installing SDK v6.1 that now I could not build my application written in C or C++. I could compile it but not link it during build process from within Visual Studio. Funny though I realized I could not even build a very basic Win32 console application.

I started getting the following error:

fatal error LNK1181: cannot open input file 'kernel32.lib'

I did something while troubleshooting it and now also started seeing:

Error spawning 'rc.exe'. Project myProject

I did check on the Internet and found all sorts of reasoning around this. One thing looked clear that installing the latest SDK v6.1 had caused me all these headaches. Some links suggested rebooting the server, some talked about low system memory, some said remove the latest SDK v6.1, and some also suggested to reinstall Visual Studio. But somehow I felt this can be fixed without reinstallation of VS2008 or un-installation of SDK v6.1 or etc etc and etc.

I opened the cool Process Monitor tool and found the following:

28836    11:51:31.5538847    devenv.exe    5528    QueryOpen    E:\Program Files\Microsoft Visual Studio 9.0\VC\lib\kernel32.lib    NAME NOT FOUND    28837    11:51:31.5539987    devenv.exe    5528    QueryOpen    E:\Program Files\Microsoft Visual Studio 9.0\VC\lib\kernel32.lib    NAME NOT FOUND    28839    11:51:31.5542065    devenv.exe    5528    QueryOpen    E:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\lib\kernel32.lib    NAME NOT FOUND    28841    11:51:31.5543630    devenv.exe    5528    QueryOpen    E:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\lib\kernel32.lib    NAME NOT FOUND    28842    11:51:31.5544705    devenv.exe    5528    QueryOpen    E:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\lib\i386\kernel32.lib    PATH NOT FOUND    28844    11:51:31.5545935    devenv.exe    5528    QueryOpen    E:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\lib\i386\kernel32.lib    PATH NOT FOUND    28846    11:51:31.5547253    devenv.exe    5528    QueryOpen    D:\Program Files\Microsoft SDKs\Windows\v6.1\lib\kernel32.lib    PATH NOT FOUND    28847    11:51:31.5548633    devenv.exe    5528    QueryOpen    D:\Program Files\Microsoft SDKs\Windows\v6.1\lib\kernel32.lib    PATH NOT FOUND    28848    11:51:31.5550927    devenv.exe    5528    QueryOpen    D:\Program Files\Microsoft SDKs\Windows\v6.1\lib\kernel32.lib    PATH NOT FOUND    28849    11:51:31.5552863    devenv.exe    5528    QueryOpen    D:\Program Files\Microsoft SDKs\Windows\v6.1\lib\kernel32.lib    PATH NOT FOUND    28850    11:51:31.5556190    devenv.exe    5528    QueryOpen    E:\Program Files\Microsoft Visual Studio 9.0\kernel32.lib    NAME NOT FOUND    28851    11:51:31.5559045    devenv.exe    5528    QueryOpen    E:\Program Files\Microsoft Visual Studio 9.0\kernel32.lib    NAME NOT FOUND    28852    11:51:31.5561361    devenv.exe    5528    QueryOpen    E:\Program Files\Microsoft Visual Studio 9.0\lib\kernel32.lib    PATH NOT FOUND    28853    11:51:31.5563280    devenv.exe    5528    QueryOpen    E:\Program Files\Microsoft Visual Studio 9.0\lib\kernel32.lib    PATH NOT FOUND    

It was crystal clear that while trying to link Visual Studio was encountering a file not found kind of error and hence could be the resulting failure.

------ Build started: Project: aa, Configuration: Debug Win32 ------
Linking...
LINK : fatal error LNK1104: cannot open file 'kernel32.lib'
Build log was saved at "file://xxxxxxxxxxx\Visual Studio 2008\Projects\myProject\myProject\Debug\BuildLog.htm"
myProject - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Similarly rc.exe showed NOT FOUND.

It looked simple yet intriguing as to why the default path was changed for Visual Studio.

I realized that the path it was trying to look at for these files did not even exist, lest I could just have copied these files to the corresponding location.

Looked at the Environment variables from Visual Studio 2008 command prompt and found that WindowsSdkDir environment variable was pointing to D:\Program Files\Microsoft SDKs\Windows\v6.1\ which did not exist.

Tried changing this to the path where I did find the above files on my box which was pointing to C:\program files\microsoft sdks\windows\v6.0A\ (So yes it pretty much looked like after installing SDK v6.1 my environment variable WindowsSdkDir had changed). Tried logging off/rebooting, no luck.

Finally figured out that in order to get things back to normal I had to update the following registry key:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\MicrosoftSDKs\Windows\CurrentInstallFolder

I changed this value to point to the original location which was C:\Program Files\Microsoft SDKs\Windows\v6.0A\ in my case.

I wasted a lot of time on this, so thought of sharing with a wider audience.

bye!

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!

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

Some tips if your IIS 6.0 World Wide Web Service (WWW) ever goes down...

Saurabh Singh — Fri, 25 Jul 2008 18:09:55 GMT

Well, every time I try writing some thing different than IIS and for some reason I come back to it :-)

Here is a quick troubleshooting tip for a scenario where World Wide Web service on my test IIS 6.0 box went down for no apparent reason. Here is what I started seeing when we tried to start all IIS related services. IIS ADMIN service came up fine but I wasn't lucky enough with WWW

From the Services console I got this error message when tried to start WWW service:

Now this was weird, I remember everything was fine just few minutes ago. I wondered how we could resolve the issue.

Event log showed the following:

Event Type:    Error
Event Source:    Service Control Manager
Event Category:    None
Event ID:    7023
Date:        7/25/2008
Time:        6:59:50 AM
User:        N/A
Computer:    SAURABSI-SEC
Description:
The World Wide Web Publishing Service service terminated with the following error:
Access is denied.

Now, this started making some sense. It was quite apparent that there was a permission issue. But then I was a local admin on the box and I had not changed any file permission recently, at least not in the last few minutes for sure.

I tried running Process Monitor from www.sysinternals.com. It is a handy tool to troubleshoot permission issues. Unfortunately I couldn't see any ACCESS DENIED anywhere in the log collected via this tool. Now if there was no access denied anywhere what else could have led to such an error message!!!

I ran DebugView while reproducing the WWW startup issue.

It showed the following:

I noticed this in the above log:

Now it was clear that there were no issues as far as accessing this metabase file was concerned. Had there been a permission issue to access this file it should have been captured by the Process Monitor utility. Also since IISADMIN was up and running it was sure that metabase was fine and was accessible. I wondered if there was something within this file, maybe some key/property etc. which was giving the problem.

I went ahead with Metabase Explorer (also called as MBExplorer, part of IIS 6.0 Resource kit) and tried to read through the various hierarchy in the metabase. The moment I tried to launch MBExplorer it gave the following error:

This was getting interesting now :-). I clicked on Yes and launched the utility anyway.

While scanning through the various structures within MBExplorer I got another similar alert when I reached the following location:

I knew now that this subkey was having the permission issue for sure. However I could not even import this setting from any other machine since I could not even rename the key !!

Looked like even administrator account had no permission on this key. It could not even be inherited from its parent level using MBExplorer.

So, after some thought this is what I did. Stopped IISADMIN service and opened metabase.xml file in a notepad.

Found the section which described the Filters subkey properties as shown below:

The only way to change the ACL on this key was to remove the AdminACL attribute such that it would inherit the same from its parent level, i.e. W3SVC level in the above MBExplorer window. I deleted the above AdminACL attribute completely, saved the file and gave a restart with my fingers crossed ;-). I had a backup.

Hurray!!! this is what I got finally.

Later on, found that while playing with permissions for compression filter, accidentally the ACL permissions for Administrators and IIS_WPG was removed, and I was a member of both these two groups :-(

Finally all that ends well is well, I am a happy man now .

Hope this helps someone stuck in a similar situation...

Cheers

Enabling Active Directory Isolation mode for FTP to work for trusted domain users

Saurabh Singh — Thu, 13 Mar 2008 04:34:21 GMT

Let's consider a scenario wherein we have an FTP site hosted on an IIS Server and we are trying to setup the site to work in Active Directory (AD) Isolation mode. Now things should work just fine if we have the setup done properly. I have talked about general setup and common issues with FTP sites here.

This should ideally work fine for the domain users which are in same domain as IIS (Let's say Domain 1). We should know AD isolation mode is supported for domain users only and not local users. Now consider a scenario wherein you want to have FTP working for users from a different domain (Let's say Domain 2).This is not as simple as just running the iisftp.vbs script on the IIS server to set FTP Root and FTP directory properties for domain2 users.

When you try to set this up you will see something like this:

C:\WINDOWS\system32>cscript iisftp.vbs /setadprop test1 ftproot "C:\inetpub"
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
User test1 was not found in Active Directory.

[Here assuming test1 to be a domain 2 account and we are running this script on the IIS server which is in Domain 1]

This is expected since test1 is not a domain 1 account, and hence iisftp.vbs won't be able to find it in the Active Directory. By default, iisftp.vbs will look into the domain where it is running and since we are running this on IIS's domain (i.e. domain 1) it will fail. this is its limitation.

To ensure we can set the FTP root and FTP directories for different domain users (to which IIS doesn't belong), ensure this domain has a trust relationship with IIS's domain first.

Also to set the above properties we need to manually run iisftp.vbs on a machine which belongs to domain 2. You may see this error when you run the script:

Could not create an instance of the IIsScriptHelper object.
Please register the Microsoft.IIsScriptHelper component.

We need to ensure we have these two files IIsScHlp.wsc and IIsFtp.vbs copied locally from a working machine (where iisftp.vbs works for e.g. the IIS server). So if IIS is not installed on a machine in domain 2 you can just copy these two files from the IIS server to the domain 2 machine and register the script IISScHlp.

C:\FTP>regsvr32 iisschlp.wsc

You will get an alert like this:

Once done you can run the iisftp script in there.

Now once we have the iisftp.vbs running fine on a domain 2 machine, using admin privilege you can set the FTP root and FTP directory for the domain 2 users. iisftp.vbs does the changes to the account in AD and has nothing to do with IIS metabase settings.

So after this you can follow the /setadprop and /getadprop to set/get the FTP root/directory settings for domain 2 users.

Remember that in this case the FTP root should be a network share like \\server1\... etc.

Reason being that FTP service which is running on IIS server in domain 1 should be able to access this location (or share). If we give a local path on a machine in domain 2, IIS FTP service has no way to access it since it is running on IIS server in domain 1.

Once done if you access the FTP site from any of the machine, let's say from anywhere on domain1 or domain 2 you should be able to access the site with your own domain credentials (could be a domain1 or domain2 account) provided there is an FTP root and FTP directory for your account set in either domain 1 or domain 2 as mentioned above.

Happy FTP' ing ;-)

HTTP to HTTPS (SSL) Web Request Redirection

Saurabh Singh — Fri, 04 Jan 2008 00:47:42 GMT

We often get requests from our customers asking how they can seamlessly redirect web requests from HTTP to HTTPS, i.e. how they can redirect a non-SSL request to an SSL based request. Recently a colleague of mine got a similar issue and we decided to use some existing scripts that we had in our database. Unfortunately none could meet the requirement.

Basically the existing scripts redirected an HTTP request to another URL and that URL was not the original request user had asked for. It took us to let's say the homepage of the site and from there one again has to click on specific links to reach the desired page. So this will be a problem for users who have book-marked their desired web page.

Here are the steps you can try for your website such that all HTTP requests get translated to HTTPS requests and have the original URL intact.

Here are two sample codes which one can try. Both of them should *hopefully* work. First one uses VBScript in an ASP page and second one uses Javascript in an HTML page.

a).

redirectSSL.asp

<%@ Language=VBScript %>

<%

strQueryString = Request.QueryString

sslPort = null

PlainURL = Right(strQueryString, len(strQueryString) - 4)

FindLastCOlon = InStrRev(PlainURL, ":")

FirstPart = Mid(PlainURL, 1, FindLastColon - 1)

LastPart = Mid(PlainURL, FindLastColon)

LastPart = (Mid(LastPart, InStr(LastPart, "/")))

'If the SSL Port is not the default 443, you need to uncomment the line below, by default SSL port is 443.

'sslPort = ":449"

if (sslPort = null) then

    url= FirstPart & LastPart

else

    url = FirstPart & sslPort & LastPart

end if

strSecure = Replace(url, "http:", "https:", 1, 1)

Response.Redirect strSecure

%>

Steps:

-- Copy the above code and put in a file redirectSSL.asp under your Website root directory for which you want redirection to work.

-- Force SSL on the web site. To do that follow the steps mentioned below:
- Go to --> <Your_Web_Site> -> Properties -> Directory Security -> Edit (Secure Communications)
- Select Require secure channel (SSL).

-- Uncheck "Require secure channel (SSL)" option for the redirectSSL.asp page. To achieve that:
- Go to --> <Your_Web_Site> -> redirectSSL.asp -> Properties -> File Security -> Edit (Secure Communications)
- Uncheck Require secure channel (SSL).

So now we are forcing SSL to be used for all of the website contents except the redirectSSL.asp page which can be accessed over non-SSL (HTTP).

-- In the IIS manager -> <Your_Web_Site> -> Properties -> Custom Errors, modify the entry for 403;4 to look like this:

Now if you try to browse to some URL, let's say http://www.abc.com/asp/test/ssl/iistsart.htm, you will be redirected to https://www.abc.com/asp/test/ssl/iistsart.htm, without you requiring to modify HTTP to HTTPS.

If your SSL port is not the default port 443 then you need to un-comment a line in the code as mentioned in there and it will redirect the request to the appropriate URL with corrected SSL port embedded in it.

b).

redirectSSL.html

<html>

<head>

<script language="javascript">

var currentURL=location.href.substring(0,5)

if(currentURL.toLowerCase()!="https")

currentURL = location.href.substring(4,location.href.lastIndexOf(''))

var portStartPos = currentURL.lastIndexOf(':')

var sslPort = null

if(portStartPos!=0)

var relativeURL = currentURL.substring(portStartPos)

var postPortURL = relativeURL.substring(relativeURL.indexOf('/'))

var URL = currentURL.substring(0,portStartPos)

// If you are running your SSL site on a non default port other than 443 then uncomment the next line and add the right Port number.

//sslPort = ":447"

if(sslPort == null)

    currentURL = URL + postPortURL

else

    currentURL = URL + sslPort + postPortURL

var targetURL = "https" + currentURL

window.location = targetURL

</script>

</head>

</html>

Steps:

-- Copy the above code and put in a file redirectSSL.html under your Website root directory for which you want redirection to work.

So now we are forcing SSL to be used for all of the Website contents.

-- In the IIS manager -> <Your_Website> -> Properties -> custom Errors, modify the entry for 403;4 to look like this:

You need not follow the step below since we are using File Type for custom error page and not a URL as shown above in the picture. If you select URL as Type above then you will need to follow the step below.

"-- Uncheck "Require secure channel (SSL)" option for the redirectSSL.html page. To achieve that:
- Go to --> <Your_Web_Site> -> redirectSSL.asp -> Properties -> File Security -> Edit (Secure Communications)
- Uncheck Require secure channel (SSL)."

This is all you need and you should see your URL changing automagically from HTTP to HTTPS (SSL).

Hope this helps...

Wildcard SSL certificate in IIS 6.0, Windows 2003 Sp1 and above

Saurabh Singh — Sat, 17 Nov 2007 07:12:02 GMT

Here I will be talking about configuring SSL wildcard certificates in IIS 6.0 on Win2k3 SP1 and above. You may have a scenario wherein you want to have the same certificate installed for multiple Websites. Now in a normal scenarios this is not possible....(read more)

How to setup IIS and AD for Client certificate authentication

Saurabh Singh — Sat, 14 Apr 2007 14:01:00 GMT

Hi All,

This post talks about how Client certificates are configured on websites. I have seen a lot of incidents where people get into issues with client certificate in particular, although server (website) certificates can give a scare at times.

Here I will be walking you through the steps of configuring client certificates in your Windows 2003 environment (although there is not much of a difference in Windows 2000).

Environment

Windows 2003 (Web server) IIS6.0

Windows 2000/XP/2003 (Client)

Windows 2003 (Microsoft Certificate server)

Walkthrough

1. To enable SSL transaction between the server and the client, you need to have a server certificate installed on IIS website. Websites can get the server certificate from a trusted root Certificate Authority (CA). We will be focusing on the steps for acquiring client certificates and setting them in IIS for user authentication.

2. Here I will show the screenshot of the steps that one needs to follow with brief explanation of the steps.

Client Workstation: WIN2kIIS-VPC

CA server: WIN2K3DC

IIA Web Server: WIN2K3OWA

DC: WIN2K3DC

Domain: Anjenya.local

Requesting a client certificate from a Trusted root Certificate Authority (CA):

Access the CA Website from your client machine as http://Win2k3dc/certsrv

There are two ways of obtaining client certificate.

Click on the link: Request a Certificate.

Click on “Select a certificate type: User certificate”.

You can also obtain the certificate by clicking on “advanced certificate request” to add more specific details about the client certificate.

Click on More Options >>

Go ahead and hit Submit >

Click on “Yes”

Go ahead and click on the link to install the certificate. You might get the certificate directly as above or through email etc when in case of a 3^rd party after verification.

Click on “Yes”

Now the User certificate is successfully installed on your client machine.

You can check the certificate in two ways:

1. Goto IE->Tools->Internet Options->Content->Certificates.

You should see the certificate there under Personal store, which was installed on your client machine.

1. Or else you can open the Certificate snap-in through Start->Run->Mmc->Console->Add/Remove Snap-in->Add… -> Certificates.

Go ahead and add the certificates snap-in.

Double click on the certificate and you should see the details about it:

Enhanced Key usage will show you the purpose of this certificate.

The above picture shows that this certificate is meant for Client Authentication.

So here we finish the process of acquiring the client certificate.

Now the next step is to map the client certificate in IIS manager, depending upon one’s requirements. It can be one of the following:

Option to accept the client certificate from the user by the IIS website (with no mapping enabled).
Option to have 1-to-1 mapping for client certificate.
Option to have Many-to-one mapping for client certificate.
Option to have Active Directory Mapping for client certificate.

1-to-1 and Many-to-1 mapping are simple to setup.

Here I will walk you through the process of setting up the above configuration for 1-to-1 mapping and Active directory mapping.

Let’s say that you have a website in IIS for which you want to enable client certificate.

You need to go to IIS Manager->Default Website-> right click and go to Properties->Directory Security->Under Secure Communications section, click on Edit.

Here in the picture above, you have three options for Client Certificates:

Ignore client certificates: IIS will ignore client certificate when a request reaches IIS website, even though web request has the certificate in it.
Accept Client certificates: IIS website will accept any client certificate from the user, if it is along with the web request.
Require Client certificates: IIS website will check for client certificate along with web request. If no client certificate is in the web request, users shall see 403.7 – Client certificate required, as the error message in the web page response.

Now in the next section in the same picture above, if you want your website to be configured such that a client certificate is mapped to a user account, you can check on “Enable client certificate mapping”. What it means is that request will be executed in the context of an account.

Now, when you enable 1-to -1 Mapping, an individual client certificate will be mapped to a specific Windows account. So in case you don’t want any of the IIS authentication methods to be used, like Anonymous, Basic, Digest or Windows Integrated authentication, you can rely upon client certificate authentication based on 1-to -1 or Many-to-1 mappings.

We will first go ahead with 1-to-1 mapping:

Click on “Add…” in the Account Mappings window shown above.

Now before you map a client certificate with a windows account, you need to have the corresponding client certificate on the server.

Export the client certificate from the CA or the client machine (where you have the certificate installed) as follows:

1) From Client machine: Open Certificate snap-in as earlier and go to Certificates – Current User -> Personal -> Certificates.

Double click on the selected certificate and Click on Details and go to “Copy to File…”.

Follow the Export wizard.

You can either Export the private key or not export it. You should know the meaning of exporting the private key.

Go ahead and save the client certificate somewhere on your workstation (client).

2) From CA:

Go to the Certificate Authority Snap-in and check the following location:

Double click to display the certificate. Click on “Copy to File...” and follow the Certificate Export Wizard, and save the file to the server as shown below:

Now copy the saved certificate from any of the above location to the IIS server, where we need to map it a windows account.

Back to IIS manager console for certificate mapping:

Now map a specific windows account with this certificate as shown below:

Once the 1 to 1 mapping is set in place go ahead and try browsing the site.

Here I have used an ASP script to render the server variables pertaining to the web request.

This script will display the logged on user name and the authentication type used along with some other information.

Also when you want to use Client certificate authentication you can clear all other authentication options in the IIS manager Directory Security setting as show below:

Here you won’t get 401.2 server configuration error because we are using some sort of authentication mechanism (client certificate mapping) to authenticate the user. Had we been not using client certificate mapping we would have got 401.2 if we try to access the site with no authentication method selected in IIS manager.

Had there not been Client cert mapping and we had tried to browse to the web page with all the options cleared as shown above, you would have got error 401.2.

Here is the sample logoninfo.asp page which displays server variables. Try accessing this page.

response.write ("LOGON_USER: ")

response.write (request.servervariables("LOGON_USER"))

response.write (" ")

response.write ("AUTH_USER: ")

response.write (request.servervariables("AUTH_USER"))

response.write (" ")

response.write ("AUTH_TYPE: ")

response.write (request.servervariables("AUTH_TYPE"))

response.write (" ")

response.write ("CERT_COOKIE: ")

response.write (request.servervariables("CERT_COOKIE"))

response.write (" ")

response.write ("CERT_ISSUER: ")

response.write (request.servervariables("CERT_ISSUER"))

response.write (" ")

response.write ("CERT_KEYSIZE: ")

response.write (request.servervariables("CERT_KEYSIZE"))

response.write (" ")

response.write ("CERT_SERIALNUMBER: ")

response.write (request.servervariables("CERT_SERIALNUMBER"))

response.write (" ")

response.write ("CERT_SERVER_ISSUER: ")

response.write (request.servervariables("CERT_SERVER_ISSUER"))

response.write (" ")

response.write ("CERT_SERVER_SUBJECT: ")

response.write (request.servervariables("CERT_SERVER_SUBJECT"))

response.write (" ")

response.write ("CERT_SUBJECT: ")

response.write (request.servervariables("CERT_SUBJECT"))

Now in our example we try accessing the above script and we get the following response:

In the above step, if you disable Client cert and enable windows integrated authentication only, you should see something similar to the one shown below:

Check the Authentication type.

Similarly you can try Many-to-1 mapping, please read MSDN/KB articles that talk about how to set it up…it’s very similar to 1 to 1 mapping.

I would like to discuss Active Directory Mapping in particular here:

We need to have Client certificate enabled, we can remove 1-to-1 and many-to-1 mapping from IIS Manager since we need to enable AD mapping.

In AD mapping we need to follow the following steps:

Go to the IIS Manager, right click on root level WEBSITES->Properties->Directory Security.

Select “Enable the windows directory service mapper”.

Now go to Active directory, open Active directory users and computers, go to Users, and then select the user for which you want to map the certificate.

Right click on the user name, go to Name Mappings. Add the client certificate. Now we have a mapping for that certificate to a user account in the AD.

Go to the client machine and logon with the user credentials , and then try accessing the site now, and now you should be able to access the page and you should see the Logon name in the webpage, here the logon name will correspond to the same user with which we have associated the client certificate in the AD.

Now you should see something like this:

Remember this:

Here is an excerpt from a TechNet article:

In Active Directory mapping, when the IIS server receives a certificate from the user, it passes it on to Active Directory, which maps it to a Windows 2000/2003 user account. The IIS server then logs this account on.

Active directory mapping is most useful when the account mappings are the same on all IIS servers. Administration is simplified because the mapping is done in only one place.

Mapping in Active Directory can happen in one of two ways. The administrator can explicitly map a certificate to a user's account. This certificate can come from any source--as long as the root CA for that certificate is trusted for client authentication.

UPN mapping can also be used. A UPN is automatically put into a certificate issued by an enterprise CA. If a certificate is passed to Active Directory for mapping, it is first examined for UPN mapping. If UPN mapping is not possible, the mapping set by the administrator is used.

UPNs are in the form of userid@domain. If the certificate contains a UPN, the domain is within the hierarchy of the directory, and the CA that issued the certificate is trusted to put UPNs in the certificate, then the user's account is retrieved from the directory and logged on. All these conditions must be true before the user's account is retrieved. If any of these conditions is false, the directory is searched for a mapping set by the administrator.

In Active Directory mapping, when the IIS server receives a certificate from the user, it passes it on to Active Directory, which maps it to a Windows 2000 or Windows Server 2003 user account. The IIS server then logs on the account.

You can create an Active Directory mapping in one of two ways. You can rely on UPN mapping, or, if UPN mapping is not possible, you can manually map a certificate to the account of a user.

Use Active Directory mapping when the account mappings are identical on all IIS servers. Active Directory mapping is easier to maintain than IIS mapping because you only have to create the mapping in one location.

NOTE: Let’s assume that the user account with which we are trying to access the site doesn’t have a UPN name in the AD (this might happen in the case where the logged on user is a local user and not a Domain user) then in that case the logon credentials for the request will be the mapped user account for the certificate in the AD. Else, if the client certificate’s “Issued to” is a domain user account, then logon credentials will use that Account and not the mapped account associated with certificate. Also it will not respect user’s logged on credentials or server authentication method in IIS manager.

Kerberos troubleshooting from IIS perspective

Saurabh Singh — Mon, 29 Jan 2007 09:47:00 GMT

Hi All,

This is my first posting in the blog.

I really had to take enough courage to start blogging, but with some help from one of my mentors in MS, I am finally here.

I hope people really get benefitted from the articles that I post in here.

Today, I am going to talk about how to implement Kerberos authentication for IIS. I have chosen this topic after a lot of consideration. This topic has always evoked a state of anxiety and fear among Web administrators and MS PSS support engineers alike. Also this has been a pain for us since a lot of calls that we receive are related to Kerberos authentication failure and causes a lot of labor and revenue loss to MS and customers.

So here it goes...

So what exactly is this Kerberos, first time when I heard of it I thought it must be some mystical word related to enchantment and what not. I went and looked into the dictionary and found something similar. It meant a fierce three-headed dog figure from Greek mythology that guarded the gates of the underworld. Kerberos protocol, similar to the dog figure has three main sections: client, server and an intermediary called Key distribution centre (KDC).

So how exactly is this Kerberos protocol work:

There are numerous articles that you can find which will give you an insight as to how Kerberos protocol works, so instead of explaining some redundant stuffs here which might confuse you a bit more (like the way it did to meJ), I will be very lucid and straight in my explanation, and concentrate more on troubleshooting than getting into various jargons associated with it. Let me know if you need articles on the topic and I can post it here.

Simply speaking, a client requests a ticket (or token) from an Intermediary called Key Distribution centre (KDC) for accessing any service registered with it. In our case to access a web service, it looks for an authenticated token to access the web services, and once getting a unique short-term session key from the KDC, directly contacts the IIS server hosting the web service. IIS in turn receives the token its own session key and since it is authenticated by the KDC with which the IIS service has been registered authenticates the client to access the application running on it. Remember authentication and authorization are two different terms. A client might be authenticated still might not be able to access the resource because of lack of authorization to access it.

To understand the details of how a Kerberos protocol works, I recommend reading MS knowledge base or Technet.

Before you configure Kerberos authentication for your site, I recommend having these tools handy:

SETSPN (For adding, listing, deleting SPN entries for a domain)

KERBTRAY (For checking the Kerberos ticket used by the client to access a web server. It gives you information as to which ticket is being used by the client to access the IIS server, and whether the ticket is capable of delegation).

I will take up a scenario where you want to implement Kerberos delegation to work in this architecture. It is also called double-hop since client's credentials are hopped twice from the client to the IIS web server to the backend SQL server to access a resource. I suggest there are very good articles present elsewhere on Microsoft site where you can get in depth information on how Kerberos authentication works. I have concentrated more on troubleshooting, so you can skip to the next section J.

We assume client, IIS server and the backend SQL server in the same domain. The same scenario will also work if you have the components in different domains but they are mutually trusted both ways.

As a troubleshooting process, start with only Basic authentication enabled on IIS server and then test from a client machine to see if that works successfully. If it works, we are good to proceed further with Windows integrated authentication as the only enabled authentication on IIS (make sure that we do not have Anonymous authentication selected in the IIS mmc console).

The following checklist gives you an insight of the basic configuration required for Kerberos to work in double hop scenario from IIS perspective.

Non-NLB Scenario

IE : IIS : SQL Server
===============================
IE-IIS-Share
{All using default accounts, for eg. In IIS 6.0, app pool running under Network service or Local system.}
--------------------------------------------------------
IE:
- Add the URL to "Local Intranet Zone"
- Enable Windows Integrated Authentication
- Automatic logon with current username and password or, Automatic logon only in Intranet Zone
--------------------------------------------------------
IIS:
- Only "Windows Integrated Authentication" is checked.
Type in > cscript adsutil.vbs get w3svc/ntauthenticationproviders (You need to run this from <system drive>/inetpub/adminscripts)
- Make sure that this command shows > Negotiate, NTLM; or there is no value set.
Else type in > cscript adsutil.vbs set w3svc/ntauthenticationproviders Negotiate, NTLM
- Make sure to cross check the same at individual website/virtual directory level by using the command > cscript adsutil.vbs find ntauthenticationproviders.
SPN:
- http/<computer-name>~~:<port>~~ <iis-computer-name>
 http/<FQDN> <iis computer-name>
~~CAUTION: Putting the <port> has been dicey. At times it works and at times it doesn't (only my own experienceJ).~~ I will recommend not using it when you set the SPN.
Domain Controller (DC):
- Under Active Directory Users and Computers -> <Domain> -> Computers, Select the IIS server, right click ->Properties->Delegation tab
 Make sure that "Trust this Computer for delegation to any service (Kerberos only) is selected, or else "Trust this computer for delegation to specified services only" is selected.
 (You will get this option if the Domain functional level is Windows Server 2003 only).
 The 1st option is more generic and is good while you are implementing it for testing the first time.
 When the 2nd option is checked, you can go ahead with any of the options: "Use Kerberos only" or "Use any authentication protocol". In such a case make sure that you are selecting the right service Type running on the backend service for which you need delegation. Let's say if you have SQL server running at the backend to which you want the IIS to delegate the credentials, we need to add service type as "MSSQLSVC" and default port as 1433.
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
IE-IIS-Share
{App Pool running under Domain account}
--------------------------------------------------------
Domain account configuration:
- Account is trusted for delegation
- Is a member of IIS_WPG group on the local IIS computer
- Has "Act as a part of Operating System"/"Impersonate a client after authentication" privileges.
IE:
- Add the URL to "Local Intranet Zone"
- Enable Windows Integrated Authentication
- Automatic logon with current username and password or, Automatic logon only in Intranet Zone.
IIS:
- Only "Windows Integrated Authentication" is checked.
Type in > cscript adsutil.vbs get w3svc/ntauthenticationproviders (You need to run this from <system drive>/inetpub/adminscripts)
- Make sure that this command shows > Negotiate, NTLM; or there is no value set.
Else type in > cscript adsutil.vbs set w3svc/ntauthenticationproviders Negotiate, NTLM
- Make sure to cross check the same at individual website/virtual directory level by using the command > cscript adsutil.vbs find ntauthenticationproviders.
SPN:
- Add the following:
 http/<computer-name>~~:<port>~~ <domain user account>
 http/<FQDN> <domain user account>
 Remove the following:
 http/<computer-name>~~:<port>~~ <iis-computer-name>
 http/<FQDN> <iis-computer-name>
~~CAUTION: Putting the <port> has been dicey. At times it works and at times it doesn't.~~ I will recommend not using it when you set the SPN.
Domain Controller (DC):
- Under Active Directory Users and Computers -> <Domain> -> Computers , Select the IIS server, right click ->Properties->Delegation tab
 Make sure that "Trust this Computer for delegation to any service (Kerberos only) is selected, or else "Trust this computer for delegation to specified services only" is selected.
 (You will get this option if the Domain functional level is Windows Server 2003 only).
 The 1st option is more generic and is good while you are implementing it for the first time.
 When the 2nd option is checked, you can go ahead with any of the options: "Use Kerberos only" or "Use any authentication protocol". In such a case make sure that you are selecting the right service Type running on the backend service for which you need delegation. Let's say if you have SQL server running at the backend to which you want the IIS to delegate the credentials, we need to add service type as "MSSQLSVC" and default port as 1433.
If you still encounter problems try checking for duplicate SPNs.
- To find duplicate SPNs
Use command prompt to execute this command on dc:
 ldifde -f <filename> -d "<dc=domain-netbiosname,dc=primary-domain>" -l serviceprincipalname -r "(serviceprincipalname=<serviceprincipalname-to-check-for-duplicates>)" -p subtree
e.g. if the domain name is test.abcd.com:
 ldifde –f C:\log.txt -d "dc=test, dc=abcd, dc=com"-l serviceprincipalname –r "(serviceprinicpalname=http/test.abcd.com)" -p subtree

NLB Scenario
--------------------------------------------------------
Now we will talk about a scenario where IIS server is a part of Network load balancer (NLB). First thing, make sure that Kerberos is supported by your NLB (hardware or software). The settings for Kerberos are a bit different when you configure it for IIS servers running as NLB nodes. Here you don't have to set SPNs for individual IIS nodes; rather you need to set an SPN entry for the Virtual IP or alias of the Load balancer. It can be hardware or software.

IE-IIS-Share
--------------------------------------------------------
{All using default accounts}
--------------------------------------------------------
IE:
- Add the URL (here the URL is the NLB's virtual URL or alias) to "Local Intranet Zone"
- Enable Windows Integrated Authentication (Internet Options->Advanced->Security)
- "Automatic logon with current username and password" or "Automatic Logon only in Intranet Zone"

IIS:
Type in > cscript adsutil.vbs get w3svc/ntauthenticationproviders (You need to run this from <system drive>/inetpub/adminscripts)
- Make sure that this command shows > Negotiate, NTLM; or there is no value set.
Else type in > cscript adsutil.vbs set w3svc/ntauthenticationproviders Negotiate, NTLM
- Make sure to cross check the same at individual website/virtual directory level by using the command > cscript adsutil.vbs find ntauthenticationproviders.
- Setup the IIS Servers for delegation as mentioned in the above steps.
- Only "Windows Integrated Authentication" is used in IIS.
- If it's an NLB environment, we need to run the IIS application under an App pool running with domain user account.
- The domain user account should be trusted for delegation in the Active Directory.
From Active Directory Users and Computers, go to the properties of the IIS User (Domain user account). On the Delegation Tab, select "Trust this user for delegation to any service (Kerberos only)"
- The domain user account should be a part of IIS node's IIS_WPG group.
- We need to set the above settings for all the IIS nodes in the NLB.
- Also add the same host header entry for the NLB URL in all the IIS nodes in the IIS manager console -><website>->Properties->Web Site-> Advanced tab.

SPN:
- For IIS:
 http/<Netbios name of the NLB> <Domain user account>
 http/<FQDN of the NLB> <Domain user account> (If we are running the site on port 80, otherwise http/<FQDN of the NLB>~~:<Port>~~ <Domain user account>
 ~~CAUTION: Putting the <port> has been dicey. At times it works and at times it doesn't.~~ I will recommend not using it when you set the SPN even when your site is running under a different port other than the default 80.

We need to make sure that we do NOT have SPN entries set for http/<FQDN> <iis computer-name> for any of the IIS nodes.

Command: >Setspn –A http/<FQDN of the NLB> <Domain user account>
When we are using Constrained delegation make sure that the backend service is listed in list of services, for e.g. in case we are connecting to SQL server at the backend add MSSQLSVC in the Machine/user properties->Delegation tab.
Note: When we are accessing the web application from a client machine, I suggest installing Kerbtray on the client machine and checking for the "OK as Delegate" option in the attributes section for the corresponding SPN. If it is selected it means the ticket can be used for delegating credentials from the IIS server to the backend server. If it is not then it means there are some issues with the settings in IIS or somewhere else. Using Netmon trace is always a good idea to figure out what tickets are being used or looked for by the Client when accessing the Web application.

In case you face any issues related to Kerberos authentication failure, do the following to understand more from the event logs
- Make sure that we have enabled Kerberos logging according to http://support.microsoft.com/default.aspx?scid=kb;EN-US;262177 on all the IIS nodes.
- Apart from that, you also need to make sure that on all the IIS servers, these two settings are enabled.

Start->Programs->Administrative tools->Local security Policy->Security settings->Local Policies->Audit Policy->Audit account logon events->"Success, Failure".

Start->Programs->Administrative tools->Local security Policy->Security settings->Local Policies->Audit Policy->Audit logon events->"Success, Failure".

NOTE:

At times making sure all the above changes are done properly doesn't help, and in such cases make sure that we purge all the kerberos tickets using Klist or Kerbtray. In fact if possible logoff and re-login to the client machine from where you are testing the web application for kerberos authentication so that the client is issued a fresh ticket.

Additional Info:
================

You might see this error in the event logs in DC:
Event Type: Error
Event Source: KDC
Event Category: None
Event ID: 11
Date: 4/1/2002
Time: 1:40:14 PM
User: N/A
Computer: ComputerName Description:
There are multiple accounts with name host/mycomputer.mydomain.com of type 10.

This might be because of Duplicate SPNs. There are two or more computer accounts that have the same service principal names (SPNs) registered. Please refer to KB 321044 for further info. Remember, you can use Ldifde to check for duplicate SPNs as mentioned above.
Few Links:
For configuring backend SQL server to accept Kerberos authentication go through this link: http://support.microsoft.com/kb/319723/en-us
Also a good article on IIS Kerberos authentication http://support.microsoft.com/kb/907272/en-us and http://support.microsoft.com/?id=929650
How to configure an Asp.Net application for a delegation scenario: http://support.microsoft.com/kb/810572/
PS: Remember to test whether delegation is working fine, you need to access the website URL from a workstation (client) browser and not from IIS server itself.

Reason: IIS uses NTLM credentials when accessing the backend when request reaches it from the local server if, Kerberos fails and there is only single hop involved. NTLM will work with single hop and hence if you access a site locally from the IIS web server it is a single hop and not a double hop scenario.

One simple mantra to be remembered always: You can have multiple different SPNs registered under an account but not the other way, i.e. you should not have the same SPN registered under multiple accounts because it leads to duplicate SPN issue.

***************************************************** Addition to the blog

Think about a scenario where http://server/app1 and http://server/app2 are running inside a network service & a domain user identity respectively .
The SPNs requested will be http/server in both the cases, and since we can’t have duplicated SPNs it won’t work. We need to then either use the same server process identity or dedicated host headers.

Again,if you are using two websites with same name but different ports like http://server:80 and http://server:81; by default IE will request a ticket for the same SPN HTTP/server.

We would then need an hotfix for the client machines, http://support.microsoft.com/kb/908209.

If you have two websites http://application1 and http://application2 that are both DNS aliases (CNAMEs) of say myserver DNS host, IE will request the ticket for SPN HTTP/myserver for both the above websites. By default IE does't use port for sending the ticket and just the SPN name like, http/mysite:99, It ignores the port part of it.
Then you would need client fix http://support.microsoft.com/kb/911149, or use a different DNS HOSTs rather than CNAMEs.You might well go ahead with using a host headers for the websites.

[Something to add here with regard to using IP Addresses to access a site...

There is another confusion that people have while dealing with Kerberos authentication. At times you may want to use IP addresses to access a website and still want Kerberos authentication to work. Now in a general scenario this will not work because Kerberos requires SPN's to recognize a service like HTTP etc. You can however make it work by adding SPN's in the form: http/10.0.1.25 (website's IP) etc. This may or may not work.

However we do not recommend the above way to make Kerberos work for your site using IP addresses. The reason being that SPN's should ideally be names like http/<somename> and not http/<some IP address>.

Let's consider a scenario wherein users belong to domain2 and the Web server is part of domain1. Also let's assume we have mutual trust between domain1 and domain 2. When using IP addresses, client will look for SPN HTTP/10.0.1.25 (assuming this is website's IP on domain1) in domain2 (client's local domain).

Now you may get into an issue wherein domain2 will not give any referral back to to the client to look into domain1 for the SPN. This can occur if IP address is being used to look for a service. In such a case even after adding SPN's for IP addresses, Kerberos won't work and will fall back to NTLM.

]

***Update: Regarding confusion around Port entry in SPNs, check this http://technet.microsoft.com/en-us/library/cc263449.aspx#section4

Happy troubleshooting…and in case you still face issues, Microsoft Product Support Services (PSS) is always there to help you!

Feel free to shoot me a question if you have any confusion or need some assistance.

*Check the following link for my other posts related to Kerberos.