2

This usually happens within the same hour of re-enabling a user's account. The user will contact us because they have been disabled due to inactivity, we re-enable the account and then they will contact us within that hour and say they're still experiencing issues. When we go to check the account for a password lockout, we find that account has been disabled again.

We don't have any disabling feature that should re-disable the account within that time frame. It's been pretty frustrating since it's difficult to replicate. I was wondering if anyone has seen this and if they have, if anyone knows what could be causing it or how to address it?

5
  • So the account(s) become disabled, not locked, correct? Is it only happening with that single user account? How many Domain Controllers are on the network? If more than one, has their AD communications/syncing been checked? Commented Jan 26, 2017 at 16:59
  • Also, I'm pretty sure Windows logs to the Event Log when an account is disabled (Event ID 4725) any signs of those on the DC? Commented Jan 26, 2017 at 17:04
  • You're right, they become disabled, not locked. I think we do have multiple DCs. I'll check their syncing. I'll also check that event ID. Would that be under the Security page of Windows Logs, or...? Commented Jan 26, 2017 at 19:26
  • I'll be in the Security log. You may want to run DCDiag on each DC to ensure proper communications. Is it more than one user account that's experiencing this? Commented Jan 26, 2017 at 20:58
  • Is there a Group Policy setting affecting the user's account that is configured to disable it? I'm specifically thinking of the settings at Computer/Policies/Windows Settings/Security Settings/Account Policies/Account Lockout Policy. You can you Group Policy Results (or Modeling) in the Group Policy snap-in to check for this. Commented Feb 21, 2017 at 21:06

2 Answers 2

0

My go-to tool for tracking down the causes of quick/mysterious lockouts has been, for a long time, Microsoft's LockOutStatus utility. This utility polls the available DCs for the username you provide and displays whether that account is locked out, the number of bad passwords since it was last logged into successfully, and the date/time of the lockout. This helps pinpoint whether it was bad passwords that locked the account out, and can also help indicate the source of these bad passwords based on which DC the lockout occurred against.

https://www.microsoft.com/en-us/download/details.aspx?id=15201

In my experience fast lockouts after unlocking, when you know the user is not spamming wrong passwords, can be caused by several different things. The most common causes I've seen are:

  • Mobile devices trying to authenticate too aggressively (iOS devices were notorious for this a few years ago, I believe prior to iOS14)
  • 3rd party utilities/apps that use the user's AD account to authenticate and have similarly unaware and aggressive authentication habits

Your own reasons could differ, but using a utility like LockOutStatus could help give you the information necessary to figure out the source of the lockouts.

-1

I know I am 7 years late, but I was having this same issue. I checked everything that was above and nothing was working. I found out it was our HR software. It is tied to our Active directory. This person was "terminated" then rehired under our fuels division which, when this happened, gave him a new employee ID. The ID wasn't changed in AD under attributes and was causing an account disable issue very 30-60 minutes.

I hope this helps anyone who is having the same issue.

1
  • 1
    While this is helpful information, the reason for the accounts you're seeing disabled are pretty unique to your setup. Others MAY have the same cause, but OPs context does not indicate it is the same thing. This is probably better as a comment, but you will need to spend a bit of time earning the rep to be able to comment on questions you have not posted. In order to earn that rep, I recommend that you put some effort into posting good answers that ARE authoritative rather than limited to a narrower context. Commented Mar 19 at 14:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .