Accounts getting disbled in active directory.

Here is my situation. Today dozens of accounts were locked by Active Directory disabling all the users PKI common access cards as a by product.

Here what I know:

Dozens of user accounts are listed as logging on to Retina Scanner appliance (a vulnerability scanner). The loggins are passed on to the server, verifed and disabled via the same local DC. This occurred over a period of four hours or so. We checked the logs for jobs on the Retina server and so far can't find anything wonky in the event logs figuring the local security logs would not be useful since they are AD logons and will be on the DC.
Being that all of these accounts attempted logons to a particular subnet which is not it's normal AOR (Area of Responsibility) is strange.
WE do have logs from DC showing the attempts and subsequent locking of the accounts that targeted the particular serve but no idea why they would all to do in hat looks to be an automated fashion

Again, but any help would be appreciated.
We cannot match up any running scan jobs at the time of login attempts.
Besides why would a vulnerability scanner be the target (not the initiator) of dozens of unsuccessful logons from the same subnet?
Finally the logon attempts causng the lock outs where definitely automated as they where hapening less that a second appart.

I have no idea so far where else to look and I'm supposed to tell the boss what going on by the end of tommorow. I'm not asking someone to do my work for me but maybe suggest other things to consider.
The more paranoid of us immediately suggested some grand AD aware piece of malware but I would rather start at something more mundane.
My only hunch is that somehow the Retina server will be culprit,not the target as the logs show because it's job is to rapidly scan swath of IP's, but again no apparent jobs where running at the time....

Sorry fore the long description but wanted you to know I'm not looking for free hand outs :-)

It sounds like the client is autonomously attempting to login (through Retina) to AD and eventually caused user account lockout. Note that user account is normally to deter any Denial Of service based attack especially in automated fashion (by innocent "bots" - client having infected by worm and trojan).
This possibility is high ...

Having said that, do note that other ways accounts can get locked out include:
* Applications using cached credentials that are stale.
* Stale service account passwords cached by the Service Control Manager (SCM).
* Stale logon credentials cached by Stored User Names and Passwords in Control Panel.
* Scheduled tasks and persistent drive mappings that have stale credentials.
* Disconnected Terminal Service sessions that use stale credentials.
* Failure of Active Directory replication between domain controllers.
* Users logging into two or more computers at once and changing their password on one of them.

In order to glean as much intelligence from this lockout scenario, I will suggest checking out the Microsoft document using of their Account Lockout and Management Tools (installed typically in DC). Mainly is to sieve out more info from log (in more details with timestamp, last reset, last change, etc) that is not be default available from the standard installation of DC.

But I would like to highlight the below tool that may help to isolate and mitigate the issue::

a) The Network Monitor can be used to capture unfiltered network communication. The program or process (from Client) causing this lockout most likely (if it is malicious client) will continue to send incorrect credentials while trying to gain access to resources that are on the network.

b) Capturing all traffic to and from the client may help you determine which network resource the process is trying to gain access to. After you determine the network resource, you can determine which program or process is running on that client computer.

c) After you identify a program or service as the cause of the lockout, view the software manufacturers Web site for known resolutions. This behavior typically occurs because the program is running with the currently logged on user's credentials.

d) If a service is causing the lockout, consider creating accounts that are specifically for running services so user account password changes do not affect the services.

Adding on, do check out all the client health as well - latest patches for OS and security software like AV.....

Thank you every one for your help. Breadtan you were very close to the what we determined to be the solution. We always suspected that the Retina server was causing the lockouts. The rub was that when we looked at the AD DC logs and the Retina scanner Job times. They didn't match up. So it messed me up for a bit.

Essentially, I was an idiot. My organization does not adhere to UTC (or any NTP) specifically. One log was in UTC and the other was in the Retina scanners time zone. So I concluded that it might not be the scans after all and started looking elsewhere.

Once, someone pointed out that "duh" I had a time zone issue and that the scans WERE running when the lock out began, I looked at the scan configurations and sure enough the password strength checks were on!

They had always been erroneously set as on but did not come to light until a GPO change changed account lock out time to permanent which triggered a ton of complaints.

Mapping Drives using Group policy preferences
Are you still using old scripts to map your network drives if so this article will show you how to get away for old scripts and move toward Group Policy Preference for mapping them.
First things f…

This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlle…

This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller.
Log onto the new domain controller with a user account t…