Account Lockout issues

We have a very strange case. Here is the description.

An employee has been having lockout issues every 15-30 minutes whenever she tries to access her email through web outlook.

I have installed Account Lockout tools and i have monitored and seen that a bad password is coming every 5 minutes.
Ran a log trace on all the domain controllers and found that the lockout is originating from the email server.
Installed trial version of Netwrix and same thing it says, lockouts are coming from the mail server.
Ran examine option and all it says is there are no persistent mappings for this user or for that matter. Only it says is invalid logons every 5 minutes.
Checked her laptop and found that there are no stored credentials/mapped drives etc.
I am at a loss here as what could be causing the lockouts for this user only to be coming from the mail server.

Any inputs will be greatly appreciated.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

1. check on mail server for the machine making connection for this user....
2. may be someone trying to access account from web based mail.. you will require to check your gateway mail server or firewall ...
alexram200Author Commented:

1. Already done that. All the user does is just open internet explorer and goes to the web out look website and login with her domain credentials and see the emails.
2. The affected person is using only web-based email i.e. web outlook. that is all. No issue in mail server or firewall.

Appreciate your further insights
It sounds like you figured out that this unfortunate occurrence is happening on a 5 minute interval?  There truly are several reasons that could be causing this, but perhaps you can try to find a workaround until you find the source of the problem?

We had a similar problem at work where there were thousands of account login attempts to SQL server in a brute force fashion documented by SQL Management Logs.  Luckily, we resolved the issue before it became a serious problem.

The possibility remains that some type of threat exists, whether it's a running script already nesting on your network due to downloaded malicious data via email or by some other means.  Could also be a relatively light brute-force network attack (From an outside/public source) as well where literally hundreds of thousands of attempts will be necessary before the right password is discovered.

Try this:

1) Depending on your network needs, ensure all ports on your router are closed.  Only allow ports to be utilized by using IPSec or by defining a specific allowed network ip address, range, scope, or host.  If you have open ports that aren't properly secured, outside threats are virtually inevitable.  

Ensure that you don't have redundant firewall rules opening a range of ports that allow outside threats into your network.

Check your router/firewall settings for open ports or ports being forwarded to a specific server/client.  Ensure all ports are closed unless needed for a specific service, and only to be opened if the request comes from a designated IP address or field.

Open up your CMD prompt and check to see which ports are currently listening to see what kind of potential vulnerabilities exist:  <netstat -a> or <netstat -an |find /i "listening"> Commands within the brackets will display listening ports. 

The link above is a good source to test whether your ports are properly being closed.  For example, if it is an outside threat, this all can be resolved by closing and securing your ports.

General rule:

Incoming ports that must be closed: 21, 23, 80, 3389 (Port will redirect to 4125 if needed for RDC).  

You can run a quick test by closing all open ports on the router side, but only allow incoming port 443 (SSL) for Web Outlook.  If the occurrence stops, you'll know it's an outside threat and vice versa.

2)  Try changing your account lockout rules.  For example... if there is some kind of script or brute force attack sending bad password requests every 5 minutes, try increasing the amount of password requests to a number like 50 and see if the problem persists.  If your PW is fairly strong, this will not significantly weaken your security being that brute force attacks on passwords require hundreds of thousands of attempts before its successful.  Perhaps you can find a right number, 25-55 PW attempts before lockout so the bad pw requests become moot.

This may give you more time to function and to find the real source of the problem.

IT Pros Agree: AI and Machine Learning Key

We’d all like to think our company’s data is well protected, but when you ask IT professionals they admit the data probably is not as safe as it could be.

Neil RussellTechnical Development LeadCommented:
Does the user have a mobile phone that accesses email with activesync maybe? that would be where I start looking.
alexram200Author Commented:
TasticVNT: Thanks for your help. I will investigate that and get back to you on this.

Neilsr: I too thought of that, but the user does not have a smartphone and does not have the corporate email enabled on that. So that drops this idea.
Neil RussellTechnical Development LeadCommented:
Maybe the user does not have a corporate smart phone but have they tried to set up their own personal phone?

If you examine the login failure/account lockout events ON THE MAIL SERVER then it should give you an IP address of the source of the login attempt that failed. Can you identify that device?
alexram200Author Commented:
Nelsr: Yes i already did that. The end user earlier had tried to configure on her smartphone but was not able to configure. Also i have seen the smartphone and there is no configuration related to corporate email. The login failure in the logs indicates the ip address of the mail server which is the strangest issue. I know that if it is an issue with the smartphone, the ip address would be something else. But it is not the case here.

Did you get a chance to check for open ports (That aren't supposed to be open) and to increase the 'PW Attempts #?'

I believe you said you see a bad password coming from the mail server on 5 minute intervals correct?  You verified this because you logged the culprit's IP address which routed to the mail server, right?  I think a good starting 'PW Attempts #' should start @ 25 attempts before lockout.  That's 1 above the maximum amount of attempts to be made before lockout on 2/hrs at 5 minute intervals.

This begs the question that malicious software resides on the mail server itself which is why it inherited the IP address...  May be worth running an efficient virus scan to rid the network of any potential threats... I imagine you probably already tried this.


I found a good resource you may want to look into.  My intuition tells me that the password threshold is set below the default value of 10, and when this happens, programs installed potentially send bad password requests, hence the lockout.

I'll cut and paste some good troubleshooting ideas:

Programs: Many programs cache credentials or keep active threads that retain the credentials after a user changes their password.

Service accounts: Service account passwords are cached by the service control manager on member computers that use the account as well as domain controllers. If you reset the password for a service account and you do not reset the password in the service control manager, account lockouts for the service account occur. This is because the computers that use this account typically retry logon authentication by using the previous password. To determine whether this is occurring, look for a pattern in the Netlogon log files and in the event log files on member computers. You can then configure the service control manager to use the new password and avoid future account lockouts.

Bad Password Threshold is set too low: This is one of the most common misconfiguration issues. Many companies set the Bad Password Threshold registry value to a value lower than the default value of 10. If you set this value too low, false lockouts occur when programs automatically retry passwords that are not valid. Microsoft recommends that you leave this value at its default value of 10. For more information, see "Choosing Account Lockout Settings for Your Deployment" in this document.

User logging on to multiple computers:
A user may log onto multiple computers at one time. Programs that are running on those computers may access network resources with the user credentials of that user who is currently logged on. If the user changes their password on one of the computers, programs that are running on the other computers may continue to use the original password. Because those programs authenticate when they request access to network resources, the old password continues to be used and the users account becomes locked out. To ensure that this behavior does not occur, users should log off of all computers, change the password from a single location, and then log off and back on.

Stored user names and passwords retain redundant credentials:
If any of the saved credentials are the same as the logon credential, you should delete those credentials. The credentials are redundant because Windows tries the logon credentials when explicit credentials are not found. To delete logon credentials, use the Stored User Names and Passwords tool. For more information about Stored User Names and Passwords, see online help in Windows XP and the Windows Server 2003 family.

Scheduled tasks: Scheduled processes may be configured to using credentials that have expired.

Persistent drive mappings: Persistent drives may have been established with credentials that subsequently expired. If the user types explicit credentials when they try to connect to a share, the credential is not persistent unless it is explicitly saved by Stored User Names and Passwords. Every time that the user logs off the network, logs on to the network, or restarts the computer, the authentication attempt fails when Windows attempts to restore the connection because there are no stored credentials. To avoid this behavior, configure net use so that is does not make persistent connections. To do this, at a command prompt, type net use /persistent:no. Alternately, to ensure current credentials are used for persistent drives, disconnect and reconnect the persistent drive.

Active Directory replication: User properties must replicate between domain controllers to ensure that account lockout information is processed properly. You should verify that proper Active Directory replication is occurring.

Disconnected Terminal Server sessions: Disconnected Terminal Server sessions may be running a process that accesses network resources with outdated authentication information. A disconnected session can have the same effect as a user with multiple interactive logons and cause account lockout by using the outdated credentials. The only difference between a disconnected session and a user who is logged onto multiple computers is that the source of the lockout comes from a single computer that is running Terminal Services.

Service accounts: By default, most computer services are configured to start in the security context of the Local System account. However, you can manually configure a service to use a specific user account and password. If you configure a service to start with a specific user account and that accounts password is changed, the service logon property must be updated with the new password or that service may lock out the account.

Sorry for the mouth-full, hope this helps.  Check the link below as a resource.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
alexram200Author Commented:
I am pretty sure that it was a case of bad password. The reason is i asked the user to change the password to something different and i supplied the password. Since then, no lockouts are happening. So it is pretty sure to be a password thing.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows 7

From novice to tech pro — start learning today.