You can’t win. But there are alternatives to fighting.
Windows Kerberos doesn’t work in an Internet scenario, it’s intranet-only.
- the client machine must be a member of the same Active Directory forest as the target site. You just can’t guarantee (or even reasonably require) this for random Internet clients.
- the client machine has to be able to contact a Domain Controller in that site to get a kerberos ticket. Most folk are understandably cautious about exposing their DCs directly to the Internet.
So Are You Just Telling Me I Can’t Do It? You’re A Bad Person.
Yes, I am, and no, I’m not telling you that – I’m saying it doesn’t work on its own.
It’s not a zero-setup-cost solution, but it is a block-level solution that lots of smaller companies don’t know about or consider – they just switch to Basic authentication, forego the benefits of pre-authentication, and plonk the server in the DMZ.
That “alternative to fighting” I mentioned earlier is ISA Server 2006. You plonk ISA Server into the domain, either as or behind your outer firewall (depending on number of NICs). Then, you use ISA to publish the website. (ISA’s publishing capabilities are laid out in gory detail here).
The website itself doesn’t get put anywhere near the Internet, it gets to stay inside the safer part of the network.
How does that help?
ISA has the capability of authenticating a client connection using Basic (Internet friendly!) or Forms authentication (also Internet friendly!) then performing Kerberos Constrained Delegation inside the firewall. It converts one form of authentication into another. There’s a big document on ISA 06 authentication options here.
Once ISA has converted the protocol to Kerberos, you’re free to do whatever you’d normally do in an Intranet scenario, but only with the nominated website – the website can then use your pre-existing Kerberos delegation setup to do Native Authentication to a SQL Server, or talk to Active Directory, or, well, whatever.
You also gain the not-insubstantial added benefit of ISA being able to pre-authenticate and authorize clients – so that by the time the client even touches your actual website, you know who they are (or at the very least, who they’ve successfully been able to impersonate), and can potentially even restrict the users allowed to hit it to certain groups (keep in mind that this is before they’ve even seen a “real” web page on your web server – you have had to write zero code for this).
ISA’s the same solution we recommend to help secure our premier applications – Exchange and Sharepoint – so why not use it for yours?