Issue with users connection with Active Directory

I have an issue with Active Directory and user logon:

This is my scenario:

SERVER LEVEL: I've a forest with one domain and three controllers. if I check on the CMD console:

With the repadmin /replsummary command, all of them says that there are no replication errors in each one.
If I do a repadmin /queue and also, there are no pending transfers.
A repadmin /showrepl does not show any errors at the tree servers.
A dcdiag /test:dns reports that there is no DNS errors at server level.
A dcdiag /diagnostic:replication at each server print out that there are no errors at replication level.

CLIENT LEVEL:

a user logs into his worksation. Do its job.
He uses our internal application that validates user credentials against the domain.
If the user tries to access outside his working hourse and, it gets blocked.
When we check, Helpdesk unlocks the account and set a temporary password to the user. The user works.

I've been diagnosing an issue were the user suddenly gets blocked in working hours, and the event viewer records "bad password". I have this behaviour in only 5 users that represents 2% of my total users.

My boss is saying is an issue with Active Directory, My bet is on user issues (forgotten passwords, corrupted profiles, antivirus issues, etc..) What else should I look or what I'm overlooking?

Solution

Analyse Event 4625 on your domain controllers for TargetUserName, LogonType, FailureReason, and WorkstationName or IpAddress. This should give you enough information to find the source of the failed logon attempts. If you've identified the type and source of the failing logon attempts. (As logon attempts with bad passwords are always forwarded to the domain controller with the PDC role for verification, it should be enough to just check that one for failed attempts, even if the original authentication attempts was sent to a different domain controller.)

If the logon attempts are interactive, that is an indication that the user is manually locking his account by typing the password wrong too many times. Any other LogonType indicates a script or scheduled task doing so.

Examine the Security event logs on the source computer for failed logon attempts, as they record the process which caused the failed attempt. This should lead you straight to the issue.