Just a very quick post, to describe a problem recently experienced at a customer.

Extranet Lockout, available in AD FS 2012 R2 and beyond, is a great security function that helps shield the AD password from remote attack.  The normal Active Directory conventions for protecting an AD account include:

• Password complexity
• Account Lockout policies
• Password Length

In a remote access scenario we need to consider the impact of users incorrectly entering their credentials versus scenarios where:

• an attempt to maliciously lockout an account is attempted
• a brute force attack is attempted on said account

Enter Extranet Lockout. By implementing this as a policy on the AD FS server, we can stipulate that after x number of invalid logon attempts via the Web Application Proxy, not to forward further requests to Active Directory, thereby protecting that account from lockout.  For example, if our AD account lockout policy stipulates lockout at 10 logon attempts, we set our AD FS extranet policy at a lower value, say 5.

All good. There is a caveat though. Extranet Lockout capability does introduce a direct dependency between ADFS and the PDC Emulator Active Directory FSMO role. If you do plan on using this feature it’s worth considering this. Otherwise, extranet lockout may occur for very different reasons   Connectivity between the AD FS farm and the Domain Controller hosting this role is assumed. Should the situation arise where network connectivity between the two is broken, then users will be unable to logon at AD FS.  This applies even where local domain controllers are co-located next to AD FS. It turns out that the PDC Emulator must be contacted on each logon attempt. This sort of issue can arise in an enterprise (e.g. global) setup, where AD is distributed, living in different data centers; the AD FS services in one and FSMO roles in another.

Should the above scenario occur, the immediate solution is to disable Extranet lockout. Longer term remedies may come in different forms:

• Ensure a redundant path on the network exists between the two locations, to avoid single points of failure;
• Consider moving the FSMO roles into the data center where AD FS  lives to eliminate the WAN as a point of failure;
• Reconsider use of Extranet Lockout until one of the above two are implemented… Disclaimer (see below)

However, the PDC Emulator role, hosted on a single domain controller,  does introduce a single point of failure. FSMO roles can be seized or transferred, though this requires manual intervention. A good monitoring setup can also help reduce potential downtime by way of monitoring the PDC emulator or more specifically, the server running underneath it. Monitoring AD FS service health can also help identify problems if the tool used is capable of checking logon with a synthetic transaction (e.g. testing login with a SOAP message against a WS-Trust endpoint).  Nonetheless, the fact remains that with the feature enabled, this represents a single point of failure into your AD FS setup.  You’ll need to evaluate organizational requirements (security v availability) and whether the individual protection offered by Extranet Lockout outweighs the possible service availability impact that arises through failure of the server hosting the PDC Emulator.