Skip to content

Ulysses Neves

Microsoft Entra ID, authentication, and hybrid identity troubleshooting.

Menu
  • Início
  • Microsoft Azure
  • Microsoft AD FS
  • Microsoft 365
  • Contact
Menu

AD FS – Configuring Extranet Lockout Threshold Familiar Location in AD FS

Posted on 27 de December de 2020

Hi mates. Today I will share with you a parameter introduced in AD FS version 2019 that can help users with wrong passwords when trying to sign in from the extranet. It’s called Extranet Lockout Threshold Familiar Location.

The ExtranetLockoutThresholdFamiliarLocation parameter is an independent lockout threshold for locations that are considered familiar comparing to unfamiliar locations so that users in known good locations can have more room for error comparing to unknown locations.

To use this option, your AD FS server must be on version 2019 and you must have the Extranet Smart Lockout enabled in the AD FS farm. In case you need help configuring this feature, please check this article called AD FS – Protecting users with the AD FS Extranet Smart Lockout

Enabling the Extranet Lockout Threshold Familiar Location

After enabling Extranet Smart Lockout, to configure this parameter, use the command below in the AD FS server:

Set-AdfsProperties -ExtranetLockoutThresholdFamiliarLocation 5

With the command above, we have configured the Extranet Lockout threshold when the user is signing in from a familiar location to 5 as the Extranet threshold is set to 3.

In this scenario, if the user comes from an Unfamiliar location and provides 3 bad passwords, the access will be blocked. If the user comes from a public IP considered Familiar, the lock will happen if the user provides 5 bad passwords. This give the user 2 more attempts when coming from a familiar public IP.

Testing the Extranet Lockout

After configuring the parameter, I’ll have the user jack@ulyssesneves.com to test if the policy is working as expected. To reproduce correctly this feature, I have previously signed in with this user to let AD FS server register my public IP as Familiar for this user.

After providing 4 bad passwords, we see that parameter FamiliarLockout is still False, that means the user is not locked for Extranet Lockout and can still sign in if a good password is provided.

After typing once more the bad password, we reach the Extranet Lockout Threshold Familiar Location’s policy, and now we can see the user is locked. At this stage, the user won’t be able to sign in even if a good password is provided until the observation window configured in AD FS is reached or if the administrator resets his account lock status using the command Reset-ADFSAccountLockout.

Summary

In this article, we covered the parameter Extranet Lockout threshold for familiar location and how to configure it in AD FS. With this parameter correctly configured, users have more room for bad passwords when they come from public IPs that are considered familiar locations in AD FS.

I hope you have enjoyed reading this article and it helps you when administering your AD FS environment.

Enjoyed the article? Like and share. 🙂

In case you have any suggestion or feedback, please leave a comment.

[ ]’s

Ulysses Neves

2 thoughts on “AD FS – Configuring Extranet Lockout Threshold Familiar Location in AD FS”

  1. krish says:
    20 de September de 2021 at 11:34

    Is this still valid? I dont see a switch called Externallockoutfamiliarlocation anymore.

    Reply
    1. Uneves says:
      20 de September de 2021 at 11:37

      Hello Krish. Thank you for your query. Extranet Lockout familiar location was introduced on AD FS version 2019. More information on this feature, you can get on this link: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-smart-lockout-protection#additional-features-in-ad-fs-2019

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

  • Microsoft Authenticator Will Block Jailbroken Devices in 2026 — What You Need to Know 17 de March de 2026
  • Enhancing Azure role activation security with FIDO2/Passkeys 23 de September de 2024
  • Microsoft Entra ID CAP | Enforcing WHfB using Authentication Strength 21 de April de 2024
  • Troubleshooting Error Code ‘0x000005e’ in WHfB: PIN Authentication Woes 11 de February de 2024
  • WHfB: Fixing Windows Hello for Business error ‘LogoncertTemplateReady: NO (StateNoTemplate)’ 29 de December de 2023

Archives

  • March 2026
  • September 2024
  • April 2024
  • February 2024
  • December 2023
  • September 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019

Tags

#aaddownleveldevice #aadhybridjoin #adfs #adfsonsql #azuread #azureauth #azureCA #azuredevice #azurehybridjoin #azuremfa #azuresecurity #capolicy #cloudkerberostrust #conditionalaccess #conditionalaccesspolicy #deviceregistration #gmsaaccount #gopasswordless #hybridaadjoin #mfaserver #msadfs #msazure #msidentity #namedlocation #sslcertificatevalidation #tshootadfs #tshoothybridjoin #tshootwaptrust #waptrust #WHFBcerttrust #whfbdeployment #WHfBhybridsetup #widdatabase adconnect authenticationcontext authenticationstrength az500 azuread azuremfa azurepim azuresecurity cloudsecurity microsoft365 msazure WHfB
©2026 Ulysses Neves | Design: Newspaperly WordPress Theme
Ulysses Neves
Gerenciar Consentimento de Cookies
Para fornecer as melhores experiências, usamos tecnologias como cookies para armazenar e/ou acessar informações do dispositivo. O consentimento para essas tecnologias nos permitirá processar dados como comportamento de navegação ou IDs exclusivos neste site. Não consentir ou retirar o consentimento pode afetar negativamente certos recursos e funções.
Funcional Always active
O armazenamento ou acesso técnico é estritamente necessário para a finalidade legítima de permitir a utilização de um serviço específico explicitamente solicitado pelo assinante ou utilizador, ou com a finalidade exclusiva de efetuar a transmissão de uma comunicação através de uma rede de comunicações eletrónicas.
Preferências
O armazenamento ou acesso técnico é necessário para o propósito legítimo de armazenar preferências que não são solicitadas pelo assinante ou usuário.
Estatísticas
O armazenamento ou acesso técnico que é usado exclusivamente para fins estatísticos. O armazenamento técnico ou acesso que é usado exclusivamente para fins estatísticos anônimos. Sem uma intimação, conformidade voluntária por parte de seu provedor de serviços de Internet ou registros adicionais de terceiros, as informações armazenadas ou recuperadas apenas para esse fim geralmente não podem ser usadas para identificá-lo.
Marketing
O armazenamento ou acesso técnico é necessário para criar perfis de usuário para enviar publicidade ou para rastrear o usuário em um site ou em vários sites para fins de marketing semelhantes.
  • Manage options
  • Manage services
  • Manage {vendor_count} vendors
  • Read more about these purposes
Ver preferências
  • {title}
  • {title}
  • {title}