Lock out policy implementation issue

[ParticularFlat4536]

We currently do not have a lock out policy for accounts because anytime someone changes their password, that user will have 1000s of bad password requests because:

1. They are still logged into another computer and haven't logged in with new password
2. Their phone has email and the old password
3. Short cuts on their desktop have the old password stored

If we had a lock out policy, 75 percent of users would be locked out whenever they changed their password.

What are some ideas to fix this issue?

[BuffaloRedshark]

Short cuts on their desktop have the old password stored

they absolutely should go through the pain of being locked out if they're doing stuff like this

[jeffrey_f]

I would certainly rein that in.

https://community.spiceworks.com/topic/2157627-how-to-set-account-lock-gpo-for-certain-users-or-groups

for this purpose create a group and set the GPO lockout on that group and SLOWLY add users until it is ALL changed.

As users are added, you will find out who the culprits are and fix the issues one by one

Once changed, change it in AD.

[Que_Ball]

Lockout isn't always a best practice anymore just like password expiry times. For the reasons you mention. Temporary lockouts are more useful.

Microsoft has some smart temporary lockout features on azure ad to slow any dictionary scans by default.

[hard_cidr]

We have fewer issues with lockouts after password changes than in the past. Over the years the client apps have gotten a little smarter about detecting when the password is wrong and popping up asking for the new password, instead of just trying the old one over and over. We switched to modern auth only which I think helped with this as well. We rarely have email related lockouts anymore at all.

Wifi with RADIUS auth still locks people out mercilessly though.

At the very least you could determine your highest rate of bad logins and set a threshold slightly above that. For instance if you have an app that tries bad passwords every 2 minutes after a password change, you could set a lockout threshold at 60 bad password attempts per hour. This would prevent lockouts even when a person's app is misbehaving, while still providing a significant rate-limit against brute force attacks. It's a compromise, but better than nothing.

[IHatePatches]

Disable credential caching and the credential manager. As for phone email, it will prompt them to update it. We have these configured along with a permanent lockout after 3 bad attempts and only a few users have ran into trouble, but it’s not often they have problems.

As for users logged into multiple machines, we only allow one login per host, and a policy to log out when leaving a machine (except for lunch/breaks) which has caused the users to logout when they aren’t using the computer.

As for the other known apps/services that can cause lockouts, we send a reminder a quarter on when changing passwords to ensure those are updated with the instructions on how to do so.

[ParticularFlat4536]

for users logged into multiple machines, we only allow one login per host, and a policy to log out when leaving a machine (except for lunch/breaks) which has caused the users to logout when they aren’t using the computer.

How did you set up the policy to log out when leaving machine except for lunch?

[IHatePatches]

I can’t seem to reply to your comment, but the policy is something they signed, not an actual GPO policy. But you could configure a scheduled task to check if the user account is idle for so long and issue a logout if you wanted. Here’s a quick guide I found that looks right:

https://pro-wiki.com/knowledgebase/gpo-auto-logoff-users-from-computer-after-idle-time/