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.

I am sharing here some of the general + elusive + ignored + must-have info that you may want to recheck when you are troubleshooting a kerberos cum delegation failure scenario and feel like reaching nowhere near the end of the tunnel (resolution!). These are my personal checklists based on experiences of troubleshooting kerberos related gotchas. I had also posted my first article on troubleshooting kerberos issues way back in January 2007. This article is a kind of continuation to it since I still see a lot of people missing some finer points here and there. Please check this post for the general kerberos checklist.

So here I go...

• Kerberos was designed and is supported in Intranet scenarios. If you are trying to make it work over an Internet environment you may want to recheck other options (unless you are going ahead with Protocol transition for e.g. from Basic/NTLM to kerberos). Remember that for kerberos to work, the client (e.g. client browser) should be able to connect to the Domain Controller(KDC) to acquire the tickets. If your clients are coming over the Internet they may not be having access to the Domain Controller. Most security conscious organizations keep their DC away from Internet facing network in order to reduce the likelihood of it getting compromised. You may have to check with the firewall/proxy settings etc. and more...to make this work which I personally feel is not a good idea.

• Kerberos will work for resources (client-IIS-Backend DB etc.) in the same domain or in trusted domains within the same forest. Either have mutual trust (preferable) between the domains in the forest or at least have the IIS domain trust the client's domain. If your clients are coming from a domain across the forest with an external trust we need to do extra work. Refer to this article. I am not an AD guy .

       Here is an excerpt from the same article:

The Windows Server 2003 family supports domain trusts and forest trusts. We know what domain trusts are: they allow a user to authenticate to resources in another domain. Like always, all domain trust relationships have only two domains in the relationship: the trusting domain and the trusted domain. There are one-way trusts (unidirectional) and two-way trusts (bi-directional) and a Windows Server 2003 domain can establish a trust among other Windows 2000/2003 domains in the same or different forest, Windows NT 4.0 domains and Kerberos V5 realms. In Windows 2000, if users in one forest needed access to resources in a second forest, an administrator could create an external trust relationship between the two domains, which is one-way and non-transitive. This meant that in order to extend your trust to other domains in the forests you had to explicitly configure each and every one of them.

Windows Server 2003 offers a forest trust: two-way Kerberos-based transitive trust between Windows Server 2003 forests, enabling a transitive trust between all the domains in the two forests. Forest trusts are established between the root domain of both forests and can be either one way or two way. A Few things to remember are to make sure all domain controllers in both forests are running Windows Server 2003, with a correctly configured DNS infrastructure and forest functionality level set to Windows Server 2003 mode in both forests.

 

• Many a times you will see something as shown below when connecting to a web site over Windows integrated authentication. You may have checked all the basic settings for kerberos and things look okay, yet somehow mysteriously this is failing to work with kerberos. After three attempts it will fail with 401.

      You typed in http://www.test.com in the browser and it seems to be connecting to some other machine   name  as  shown below in the picture.

Look at the IE prompt which shows that we are trying to connect to testkrb.saurabh1.com although web site URL in the browser's address box shows we are trying to reach the site www.test.com. Ideally we should have seen "Connecting to www.test.com" and not "connecting to testkrb.saurabh1.com". Equivalently try a ping to www.test.com and see what it resolves to.

If you see such a scenario it's time to check whether the web site URL is an Alias(CNAME) or a DNS Host (A) Record. There is a known issue with using Alias for a site which may not allow kerberos to work. There are some details which I don't want to get into at this point, probably some other day. In short, it tries to look into the KDC based on the SPN http/testkrb.saurabh1.com and not an SPN of the form http/www.test.com.

Solution:

Server side: Either go ahead and change the DNS entry to add www.test.com as a DNS Host (A) Record and not CNAME.

or,

Client side: Apply this hotfix to IE browser on the client(s) (I don't see this as a good option).

• I would recommended to use a host name instead of an IP address to access a web site meant for a kerberos based authentication. You may see it working just fine even with IP address in some scenarios but then it may pose problems when we have client and servers in different domains etc. 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.

• If your web site is configured to use a non-default HTTP port like 81 instead of 80, users will access the site as http://www.test.com:81 and not http://www.test.com (browsers append ':80' as the default port if none specified). Here lies the confusion when you add SPNs for the web site. Don't have an SPN with the port number appended even if you are running your site on a non-default port.

If the site is accessed as http://www.test.com:8080 SPN will still be of the form http/www.test.com  and  not http/www.test.com:8080.

      Refer to this article. It confuses me further but I would suggest go ahead with the default as above.

• Consider a scenario wherein two applications http://servername/app1 and http://servername/app2 are running under a NETWORK SERVICE & a domain user Application Pool identities respectively .
  The SPNs requested will be http/servername in both the cases, and since we can’t have duplicate SPNs; kerberos may not work for either of the applications. We need to then either use the same Application Pool identity or separate host headers for the web sites and set SPNs accordingly. NOTE: This issue is taken care of in IIS 7.0 with Kernal mode authentication.

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

  We would then need an hotfix for the client machines, Refer to this.

   

• When do we have Duplicate SPNs leading to kerberos not working?

Duplicate SPN arises from the fact that the same SPN is mapped to multiple accounts, it may be a machine or an user account. Doesn't matter. Mapping to multiple accounts will lead to duplicate SPNs!

*Remember: You can have multiple different SPNs registered under the same account but not vice-versa, i.e. you should *not* have the same SPN registered under multiple accounts.

 

• IIS uses NTLM credentials when accessing a resource for a local request coming to it (i.e. client say IE, and IIS are on the same box). It may use Kerberos or NTLM from a separate client machine depending on the setup.The best way to check if delegation is working is from a client machine which is not same as the IIS server. NTLM doesn't support delegation. Kerberos does!

• At times making sure all the settings on the client, IIS, AD, back-end (if any) to make kerberos work properly doesn't help, and in such cases make sure that we purge all the kerberos tickets using Klist or Kerbtray on the client. 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.

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

Till next time...