Working with Microsoft Entra Smart Lockout protection

-

If you follow @merill from Microsoft on X, then he recently shared a one pager on Microsoft Entra security capabilities.



It caught my attention and I wanted to verify which all security features I had already implemented so far. While going through the list, I realized that I had actually left out on testing and understanding the end user behavior of one of the security capabilities i.e. Microsoft Entra Smart Lockout, and decided  to give it a go. Let's first see what is this feature all about.

What is Smart lockout and how it works?

Smart lockout helps in protecting against bad actors that try to guess passwords of end user accounts or use brute-force methods to get in. The feature can recognize sign-ins that come from valid users and treat them differently than ones of attackers and other unknown sources.

By default, smart lockout locks an account from sign-in after 10 failed attempts in Azure Public and Microsoft Azure operated by 21Vianet tenants, while 3 failed attempts for Azure US Government tenants. The lockout period is one minute at first, and can become longer for all subsequent attempts. 

The lockout service attempts to ensure that bad actors can't gain access to a genuine user account and the following considerations apply:

1. Once an account is locked out, it's locked out everywhere across all Microsoft Entra data centers.
2. Smart Lockout uses familiar location vs unfamiliar location to differentiate between a bad actor and the genuine user. Both unfamiliar and familiar locations have separate lockout counters.
3. After an account lockout, the user can initiate self-service password reset (SSPR) to sign in again. 

Tip: To help users reset or change their password from a web browser, configure Microsoft Entra self-service password reset.

Configuring Smart Lockout in Entra

Smart Lockout is enabled by default. However, organizations can modify the default values which requires a Microsoft Entra ID P1 or higher licenses.

To modify, follow the steps below:

1. Navigate to Microsoft Entra admin center > Protection > Authentication methods > Password protection

2. Set the Lockout threshold, based on how many failed sign-ins are allowed on an account before its first lockout. (Default is 10 for Azure Public tenants and 3 for Azure US Government tenants)

3. Set the Lockout duration in seconds, to the length in seconds of each lockout. (Default is 60 seconds).

Testing the Smart Lockout Policy

I put in wrong password 5 times to emulate the behavior of a bad actor trying to guess the password or using brute force techniques to get in. As a result, the account was temporarily locked.


The account locks again after each subsequent failed sign-in attempt. The lockout period is one minute at first, and longer in subsequent attempts.

If a user is setup for Self service password reset, then they can initiate the process by clicking on 'Forgot my password'.




From an admin perspective, all SSPR events can be tracked using Audit logs located under Microsoft Entra admin center > Identity Governance




Conclusion

Through Smart Lockout the lockout service attempts to ensure that bad actors can't gain access to a genuine user account. However, there can be situations when a genuine user account does get locked, but chances of happening that is minimal and circumstantial. Another good thing is that this lockout service is not restricted to Entra ID only. It can be integrated with hybrid deployments that use password hash sync or pass-through authentication. 

In case you are looking to know more about other Entra protection capabilities then I recommend going through official docs or you can refer to my blog posts covering my experience implementing them -




Thank you for reading. Until next time..

Comments

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

-
Image
Every now and then it so happens that BitLocker recovery keys do not escrow in AAD. The usual culprits are incorrect BitLocker policies and\or the device hardware configuration failing to meet the minimum requirements. The other scenario and something I recently experienced is when everything is setup right and still the recovery key doesn’t escrow in AAD. As I understand, this can happen if the escrow process got interrupted the first time due to network or local devices related issues and the process could not resume. To circumvent this issue, one can simply push a PowerShell script to the devices to force the escrow of the recovery keys to AAD. Here is a script to do so. try{ $BitlockerVol = Get-BitLockerVolume -MountPoint $env:SystemDrive         $KPID=""         foreach($KP in $BitlockerVol.KeyProtector){             if($KP.KeyProtectorType -eq "RecoveryPassword"){                 $KPID=$KP.KeyProtectorId                 break;             }         }        $o
Read more

Intune: Configure Printers for Non-Administrative Users

-
Image
Configuring printers for end users or giving them the ability to do it themselves is a normal requirement for organizations. Now if your users are Administrators, then the configuration can be straight forward, but in case of Non-Administrators there are additional steps required as Non-Administrators will not be able to add a driver in the driver store despite being able to install a printer. In this blog, I will cover the steps that I took to address this requirement using Intune. The setup involves 2 steps -  1. Setup registries. 2. Install the driver and configure the printer Setting up registries – The registries that need to be configured are actually part of a GPO setting – Allow non-administrators to install drivers for these device setup classes It can be found under: Computer Configuration -> Policies -> Administrative Templates -> System -> Driver Installation I used a Powershell script to set the values and wrapped it in a Win32 application. $Path1
Read more

Intune: UAC Elevation Prompt Behavior for Standard Users

-
Image
Implementing and maintaining a good security posture is an integral part of overall IT security governance for most organizations now. While you want to harden the security of infrastructure and give least number of privileges to your end users, sometimes you may need to cut back on the restrictions to ensure a good user experience and an effective IT support process. Recently, I had a requirement where the customer wanted to ease the restriction on the end user devices to make the helpdesk support process more efficient. This involved easing the UAC level access for the Standard users and if you are managing your devices using Intune, then this blog may just help you. Let us see what all is involved and some of the ways that you can use to implement this easily. Policy CSP – LocalPoliciesSecurityOptions LocalPoliciesSecurityOptions has many CSP settings and if you are managing these settings at an individual level, then the CSP that we need to concern ourselves with here is U
Read more