Simple IIS Kerberos Q&A

Posting a hopefully-useful tidbit.

Hi Tristan,

Do you have by any chance a guide on how to set up IIS for kerberos auth? I’m helping my customer and I’m a beginner with IIS.

It is a farm of 6 IIS servers, they will be using a service acct.

DNS is configured to do the following resolution:

Websvr -> CNAME -> IP

So for instance the web site is webapp.example.net and points to a CName. The CName obviously is an fqdn (app-prod-vip.example.net) that points to an IP.

The IP points to the VIP of a load balancer that ultimately connects to the IIS server farm.

When setting the SPN do we use the websvr or the CName?

Also, does it matter the browser I’m using on the client for kerberos auth (such as chrome)

Anything special on the web server, besides configuring Windows authentication?

Thank you!

 

Here’s what I replied with:

 

Hola!

Couple of moving parts there – it (a different name, i.e. the load balancer name) won’t work with the default configuration.

You’ll need to ensure that the SPN for the CNAME is only assigned to the service account running the App Pool. If it’s on more than one account, it’s broken.

A DA needs to run:

SetSPN -S http/cname-of-app.fqdn.com DOMAIN\AppPoolAccountName

Where DOMAIN\AppPoolAccountName is the service account you set up for the application.

And that should get kerb where it needs to be from an SPN perspective. If other SPNs have been tried already, they need to be removed (and SetSPN -S should tell you that).

(Once you’ve established an SPN for the account, the Delegation tab should appear for it in ADUC. This allows you to configure constraints or delegation, which you might not be doing, so we’ll cover that last.)

Next, you need to ensure the App Pool Account is set to DOMAIN\AppPoolAccountName (i.e. the same “custom” domain account) on all the boxes. (ApplicationPoolIdentity or NetworkService or LocalSystem or anything other than a Domain account won’t work for load-balanced Kerberos authentication.)

Then, you need to either

  • disable Kernel-mode authentication, or
  • set useAppPoolCredentials=true

on them all.

There’s a tickbox for K-mode auth under Windows Authentication in IIS; or useAppPoolCredentials goes (I think) in web.config so might be preferable. What either of these does is to move from using the box identity (machine account) to validate tickets, to using the App Pool Account to validate tickets. This is required for a farm scenario, but for a single-box scenario, it’s not necessary (only SPN registration).

Once that’s done, Kerb should work to the websites, which can be validated with a network trace, or by looking at logs. (let’s throw in a reboot after k-mode auth is toggled off for good measure) (Picking Kerb in logs – short version: single 401 www-auth:negotiate/request with long ticket/200 is Kerb, 401/401/200 is NTLM).

I’d always test with IE, I *think* if IE works then Chrome has a good chance. If it doesn’t, no chance Smile

Always test from a remote box (avoids reflection protection), and use klist purge (and a closed browser) to reset between tests.

If Kerb works to the site, you can then configure the App Pool Account in ADUC for constrained delegation to the next hop in the same way. Hit Add, browse for the process identity it’s connecting to (i.e. often the service account if the process is running as a domain identity, not the box name, but if not, the box name) and then pick the right SPN from the list.

HTH!

IIS 7: But why do I get a 500.19 – Cannot add duplicate collection entry- with 0x800700b7 !?

(Because I’m sure that was your exact exclamation when you hit it!)

Also applies to IIS 7.5 (Windows Server 2008 R2), IIS 8.0 (Windows Server 2012), IIS 8.5 (Windows Server 2012 R2) and IIS 10 (Windows Server 2016).

The Background

This week, I was out at a customer site performing an IIS Health Check, and got pulled into a side meeting to look at an app problem on a different box.

The customer was migrating a bunch of apps from older servers onto some shiny new IIS 7.5 servers, and had hit a snag while testing one of these with their new Windows 7 build.

To work around that, they were going to use IE in compatibility mode (via X-UA-Compatible), but adding HTTP response headers caused the app to fail completely and instantly with a 500.19 configuration error.

We tested with a different header (“X-UA-Preposterous”) and it had the same problem, so we know it’s not the header itself.

“Now that’s interesting!”

At first I thought it was app failure, but as it turns out…

The Site Layout

This becomes important – remember I noted that the app was being migrated from an old box to a new one?

Well, on the old box, it was probably one app of many. But the new model is one app per site, so a site was being created for each app.

The old location for the app was (say) http://oldserver/myapp/, but the contents were copied to the root of http://newsite/ on the new server.

To allow the app to run without modification to all its paths, a virtual directory was created for /myapp/ (to mimic the old path) which also pointed to the root of newsite.

image

So myApp above points to c:\inetpub\wwwroot , and so does Default Web Site.

Setting up the problem

So, using the GUI, I set the X-UA-Compatible header to IE=EmulateIE7. The GUI wrote this to the web.config file, as you can see in the status bar at the bottom:

image

Browsing to a file in the root of the website works absolutely fine. No problem at all.

Browsing to anything in the /myApp/ vdir, though, is instantly fatal:

image

If you try to open HTTP Response Headers in the /myApp/ virtual directory, you also get a configuration error:

image

What does that tell us? It tells us that the configuration isn’t valid… interesting… because it’s trying to add a unique key for X-UA-Compatible twice.

Why twice? Where’s it set? We’re at the site level, so we checked the Server level HTTP Response Headers… blank.

But… it’s set in a web.config file, as we can see above. And the web.config file is in the same location as the path.

Lightbulb moment

Ah. So we’re probably processing the same web.config twice, once for each segment of the url!

So, when the user requests something in the root of the site, like http://website/something.asp:

1. IIS (well, the W3WP configuration reader) opens the site’s web.config file, and creates a customheaders collection with a key of X-UA-Compatible

2. IIS Serves the file

And it works. But when the user requests something from the virtual directory as well – like http://website/myApp/something.asp

1. IIS opens the site web.config file, and creates a customheaders collection with a key of X-UA-Compatible

2. IIS opens the virtual directory web.config file (which is the same web.config file) and tries to create the key again, but can’t, because it’s not unique

3. IIS can’t logically resolve the configuration, so responds with an error

Options for Fixing It

1. Don’t use a virtual directory

(or rather, don’t point the virtual directory to the root of the website)

This problem exclusively affects a “looped” configuration file, so if you move the site contents into a physical directory in that path, it’ll just work.

There will be one configuration file per level, the GUI won’t get confused, and nor will the configuration system.

Then you just use a redirecting default.asp or redirect rules to bounce requests from the root to /myApp/ .

2. Clear the collection

You can add a <clear /> element to the web.config file, and that’ll fix it for any individual collection, as shown here:

<customHeaders>
      <clear />
<add name=”X-UA-Compatible” value=”IE=EmulateIE7″ />
</customHeaders>

The clear element tells IIS to forget what it thinks it knows already, and just go with it. (When you break inheritance of a collection in the GUI, this is what it does under the covers).

The problem with this approach is that you need to do it manually, and you need to do it for every collection.

In our case, we had Failed Request Tracing rules as well which failed with the same type of error, promptly after fixing the above problem, confirming the diagnosis.

3. Move the configuration

And this splits into two possible approaches:

3a. Editing Applicationhost.config by hand

You can remove the web.config and use a <location path=”New Site/myApp”> tag in applicationhost.config to store configuration, and that’ll work until someone uses web.config again.

3b. Using Feature Delegation

If you do want to prevent web.config being used, you can use the Feature Delegation option to make all properties you don’t want people to set in web.config files Read-Only. (aka “lock” those sections). “Not Delegated” would also work.

image

This can be done per-Site using Custom Site Delegation, or globally.

And! This has the added happy side-benefit of making the GUI target applicationhost.config, rather than creating or modifying web.config files for that site.

 

Hope that helps you if you hit it…

Custom Password Filters

Back from holiday now, and almost over the jetlag. Almost.

A question came up today about Password Filter DLLs, and the documentation always seems to be hard to find, so I’ve popped up a quick summary of everything I know here.

Back In The Day of NT4, there was an optional component that Microsoft provided called PASSFILT.DLL that could be installed to perform password complexity checks. These days, equivalent functionality is built in to the base OS (since Windows 2000)(I.e. Windows 2000, 2003, 2008, 2012, 2016, etc etc).

Anyway, the problem is that the Platform SDK article Installing and Registering a Password Filter DLL makes the assumption that you want more security than Windows’ default password complexity check, and so lists the final step as being:

4. Ensure that the Passwords must meet complexity requirements policy setting is enabled.

If you’d written a filter that, say, only checked that the user wasn’t using their own name as a part of the password, and you wanted this check to be an additional check over the Microsoft built-in password complexity filter, this would be a Good Thing, because a password is only considered valid if it satisfies all installed password filters. It’s an AND relationship:

  • Filter1 must return true AND
  • Filter2 must return true AND
  • Filter3 must return true

So, all the filters run for every password change, and if they all say “yep, that’s fine with me”, then the password change is successful.

If you wrote a filter that checked for the word “Micro$oft” (or a 1337 derivative of your own company name) in a password, and rejected it if it was present, and followed the instructions at the above link, you’d have a system that would accept:

  • strong passwords (as defined by your Windows complexity policy)
  • that didn’t contain that particular word (as defined by your filter)

To extend the model, if your company had compiled a massive database of personal information on its employees,  you could similarly check that they weren’t using their wife’s name, blood type, social security number (Hello Americans!), dog’s name, daughter’s boyfriend’s name or brand of hair gel as a part of their password, and be assured that the password met Windows’ password complexity requirements… though slightly more seriously it’s a good idea to keep these things somewhat lightweight.

The Windows Password Complexity setting simply enables or disables the default “complex” Windows checks, so you don’t have to muck around with DLL installation and removal to get the regular “complex” stuff, it just sets a registry key (via policy). The Windows password filter is always installed and always runs to some extent, it just doesn’t always take action (depending on those registry settings).

Over the years I’ve worked with password filters, it’s (disappointingly) been reasonably common that some customers actually want reduced security in the password complexity space (often because it’s more difficult to upgrade legacy systems that can’t handle > 5 character passwords and lower case, or other similarly horrific constraints). As the alternative is “no password complexity” at the Windows filter level, we’re not really that flexible, and any security measure is potentially better than none.

If you’re coding a password complexity filter that is meant to replace rather than complement the Windows complexity checks, you need to disable the “Passwords must meet complexity requirements” setting to make yours the One True Password Filter (assuming no other custom filters are installed that make it impossible to produce a valid password… be careful with that too).

It’s worth calling out one other item around password filters – the error message received by clients isn’t configurable – the client always assumes the Windows password filter is in use, and is hard-coded to report the Windows complexity requirements (at least in part because there’s no mechanism that is used to explain to the client what the problem is.)

(Update 2017-04: There was a feedback link here, but… the behaviour didn’t change for 20 years, so odds are we’ve moved on from passwords. And if you can modernize your environment, perhaps you can too? Hello!) (in all non-glibness, consider an unlock gesture tied to a device a more authentic validation than a shared character string which many folks will surrender for a bar of chocolate…) (OK so that was a cheap 2004 reference, but you have a security awareness program in place, right?)