Change in Supportability for WID-based ADFS farms

In case you didn’t notice, Microsoft changed the Supportability statement around ADFS farms that run on a Windows Internal Database (WID) backend.

Previously, WID-based ADFS farms were limited in support for the amount of ADFS servers you could run and the maximum number of Relying Parties you could register.

  • A maximum of 5 ADFS Servers, if you are running more than 10 Relying Parties.
  • A maxiumum of 5 Relying Parties, if you are running more than 5 ADFS servers (max 10).

pretty narrow – and limiting in the way you can build ADFS farms in WID. Microsoft were taking it on the safe side, to ensure you do the right thing and design your critical ADFS farm on SQL – which pretty much endlessly scales, should you need additional capacity.

There is also SQL Server support for additional features, that today cannot be used with WID-based farms:

  • Token Replay Detection
  • SAML Artifact resolution

Now – Microsoft reviewed their supportability statement and tested how far they could go with WID. Apparently, they found WID could be pushed a lot further than initially allowed, while keeping performance and WID replication intact. The new limits for WID-based ADFS farms are:

Read more »


One of the things that I keep discussing with customers is whether they should create their ADFS farm with a WID backend or based on SQL server. It appears that from Microsoft’s perspective, reading up on TechNet, SQL is “the proper” thing.

What you usually do is look at the requirements at hand and then see how either database backend can deliver on these requirements. Of course, you’re also looking at future growth and realistic plans of that ADFS farm for the next, say, 12-18 months, and take that into consideration for your decision. Read more »

Extranet Lockout

ADFS in Windows Server 2012 R2 (some call it “ADFS v3″) comes with a number of very cool features – one of them is “Extranet Lockout Protection”:,

The idea behind that is that, if you expose your ADFS to the internet, which makes sense in many scenarios, and you use Web Application Proxy to do so, you want to protect yourself from Denial of Service (DOS) attacks. Clever attackers could try to brute-force logon to your ADFS servers, by simply trying out and testing username and password combinations – or worse, they now how your usernames are constructed and try out a number of passwords for a given username. If you then have Windows Active Directory configured to lock a user account after too many faulty logon attempts, it can happen that the attacker locks an account in Windows AD.

Now that an undesired behavior that Extranet Lockout Protection is trying to prevent. Once enabled, you configure a threshold, much like in the Windows AD Account Lockout Policy in Windows AD, to let ADFS observe these kinds of logons and, before the accounts gets locked out, stop forwarding the logon attempts to Windows AD.

I’ve found that the process of how ADFS determines this is not very well document (yet), and I’ve found myself have a wrong understanding of how this all happens. So to shed some light into this – here’s a little write-up of information I got from the Product Group and testing with a customer of mine.

The threshold for Extranet Lockout Protection should be configured to be lower than the Lockout settings in Windows AD, so ADFS can stop trying to log on before it’s too late.

Read more »

« Previous PageNext Page »