Partager via

Demystify extranet lockout feature in AD FS 3.0

  • Article

In AD FS 3.0 (Windows Server 2012 R2), we introduced a security feature called Extranet Lockout. With this feature, AD FS will "stop" authenticating the "malicious" user account from outside for a period of time. Please note that this feature only applies to username and password authentication.

There are several advantages of enabling Extranet Lockout feature in AD FS. First of all, it protects your user accounts from brute force attacks where an attacker tries to guess a user's password by continuously sending authentication requests. In this case, AD FS will lock out the malicious user account for extranet access. Second of all, it protects your user accounts from malicious account lockout where an attacker wants to lock out a user account by sending authentication requests with wrong passwords. In this case, although the user account will be locked out by AD FS for extranet access, the actual user account in AD is not locked out and the user can still access corporate resources within the organization. We call it soft-lockout as compared to actual AD account lockout.

As the name of this feature suggests, this feature only works for extranet scenario where the authentication requests come through the Web Application Proxy. This feature works independently from AD Lockout policy but you do need to consider a few things when it comes to configuring extranet lockout setting to make sure this feature work as intended which I will explain later.

HOW DOES IT WORK

There are 3 settings in AD FS that you need to configure to enable this feature:

  • EnableExtranetLockout: set this Boolean value to be True if you want to enable Extranet Lockout.
  • ExtranetObservationWindow: this determines for how long the user account will be soft-locked out. AD FS will start to perform username and password authentication again when the window is passed. AD FS uses the AD attribute badPasswordTime as the reference for determining whether the extranet observation window has passed or not. The window has passed if current time > badPasswordTime + ExtranetObservationWindow. 
  • ExtranetLockoutThreshold: this defines the maximum number of bad password attempts. Once the threshold is reached, AD FS will immediately rejects the requests from extranet without attempting to contact the domain controller for authentication, no matter whether password is good or bad, until the extranet observation window is passed. This means the value of badPwdCount attribute of an AD account will not increase while the account is soft-locked out.

An example of enabling Extranet Lockout feature with maximum of 15 number of bad password attempts and 30 mins soft-lockout duration is as follows:

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow (new-timespan -Minutes 30)

These settings apply to all domains that the AD FS service can authenticate. The way that it works is that when AD FS receives an authentication request, it will access Primary Domain Controller (PDC) through LDAP call and perform a lookup for the badPwdCount attribute for the user on the PDC. If AD FS finds the value of badPwdCount >= ExtranetLockoutThreshold setting and the time defined in the Extranet Observation Window has not passed yet, AD FS will reject the request immediately, which means no matter whether user enters good or bad password from extranet, the logon will fail because AD FS does not send credentials to AD. AD FS does not maintain any state with regard to badPwdCount or locked out user account. AD FS uses AD for all state tracking.

WORK TOGETHER WITH AD LOCKOUT POLICY

One of the areas that people get most confused about is how this feature works together with AD lockout policy. As I mentioned earlier, Extranet Lockout feature in AD FS works independently from AD lockout policy. However, you do need to make sure the settings for Extranet Lockout is properly configured such that it can serve its security purpose with AD lockout policy.

Let's take a look at AD lockout policy first. There are three settings regarding lockout policy in AD:

  • Account Lockout Threshold: this setting is similar to ExtranetLockoutThreshold setting in AD FS. It determines the number of failed logon attempts that will cause a user account to be locked out. In order to protect your user accounts from malicious account lockout attack, you want to set the value of ExtranetLockoutThreshold in AD FS < Account Lockout Threshold value in AD
  • Account Lockout Duration: this setting determines for how long a user account is locked out. This setting does not matter much in this conversation as Extranet Lockout should always happen before AD lockout happens if configured properly
  • Reset Account Lockout Counter After: this setting determines how much time must elapse from user's last logon failure before badPwdCount is reset to 0. In order for Extranet Lockout feature in AD FS to work well with AD lockout policy, you want to make sure the value of ExtranetObservationWindow in AD FS> Reset Account Lockout Counter After value in AD. We will use examples below to explain why.  

SEE IT WORK IN ACTION

Let's take a look at two examples and see how badPwdCount changes over time based on different settings and states. Let's assume in both examples Account Lockout Threshold = 4 and ExtranetLockoutThreshold = 2. The red arrow represents bad password attempt, the green arrow represents good password attempt. In example #1, ExtranetObservationWindow > Reset Account Lockout Counter After. In example #2, ExtranetObservationWindow < Reset Account Lockout Counter After. 

Example #1

Example #2

As you can see from the above, there are two conditions when badPwdCount will be reset to 0. One is when there is a successful logon. The other is when it is time to reset this counter as defined in Reset Account Lockout Counter After setting. When Reset Account Lockout Counter After < ExtranetObservationWindow, an account does not have any risk of being locked out by AD. However, if Reset Account Lockout Counter After > Extranet Observation Window, there is a chance that an account may be locked out by AD but in a "delayed fashion". It may take a while to get an account locked out by AD depending on your configuration as AD FS will only allow one bad password attempt during its observation window until badPwdCount reaches Account Lockout Threshold.

Audits

When Extranet Lockout feature is in effect, there are three audits will be written. Those audits include information such as user account, client IP address, bad password count and last bad password attempt.

Meesage ID 512: ExtranetLockoutAccountThrottledAudit

This audit is written when AD FS allows a login attempt after extranet observation window has passed. 

Message ID 515: ExtranetLockoutUserThrottleTransitionAudit

This audit is written when there is a successful login after extranet observation windows has passed.

Message ID516: ExtranetLockoutAccountRestrictedAudit

This audit is written when AD FS receives a login attempt and the user account has been locked out. This will happen for the first time when the account is locked out or after the account is locked out and extranet observation window has not passed.

KNOWN ISSUE

There is a known issue where the AD user account cannot authentication with AD FS because the badPwdCount attribute is not replicated to the domain controller that ADFS is querying. See 2971171 for more details. You can find all AD FS QFEs that have been released so far at https://technet.microsoft.com/en-us/library/mt126278.aspx.

TAKEAWAYS

  • Extranet Lockout feature only works for extranet scenario where the authentication requests come through the Web Application Proxy
  • Extranet Lockout feature only applies to username & password authentication
  • AD FS does not keep any track of badPwdCount or users that are soft-locked out. AD FS uses AD for all state tracking
  • AD FS performs a lookup for the badPwdCount attribute through LDAP call for the user on the PDC for every authentication attempt 
  • AD FS will fail if it cannot access the PDC. We are looking into making an improvement for the next version of AD FS that will allow AD FS to fall back to local DC in case of failure
  • AD FS will allow authentication requests from extranet if badPwdCount < ExtranetLockoutThreshold 
  • If badPwdCount >= ExtranetLockoutThreshold AND badPasswordTime + ExtranetObservationWindow < Current time, AD FS will reject authentication requests from extranet
  • To avoid malicious account lockout, you should make sure ExtranetLockoutThreshold < Account Lockout Threshold AND ExtranetObservationWindow > Reset Account Lockout Counter

Hope you found this blog post useful. Feel free to post comments on this blog post to ask questions or leave feedback.

 --Lu

Comments

  • Anonymous
    June 29, 2015
    Lu, thank you for this article. I have a question in regards to this statement "AD FS will fail if it cannot access the PDC. " Are you implying that if we enable extranet lockout, we have a strict dependency upon the PDC-e, effectively introducing a single point of failure? I hope I misunderstood...

  • Anonymous
    July 02, 2015
    To JJ: yes, unfortunately. As I mentioned in this post, we are looking into making an improvement for the next version of AD FS which will allow AD FS to fall back to local DC in case of failure.

  • Anonymous
    August 20, 2015
    Thank you for this article. We indeed ran into this today and it got me mystified! All clear now :-)

  • Anonymous
    September 18, 2015
    The comment has been removed

  • Anonymous
    January 22, 2016
    To Lu:  Has an improvement been made yet on AD FS to allow AD FS to fall back to local DC in case of failure to communicate with PDC?

  • Anonymous
    January 28, 2016
    Hi Lu, Can you help with this issue social.technet.microsoft.com/.../ad-fs-extranet-lockout-not-working