Solved

Account Lockout issues

Posted on 2012-04-10
10
1,390 Views
Last Modified: 2012-04-14
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.
0
Comment
Question by:alexram200
  • 4
  • 3
  • 2
  • +1
10 Comments
 
LVL 17

Expert Comment

by:Anuroopsundd
ID: 37831093
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 ...
0
 

Author Comment

by:alexram200
ID: 37831096
Anuroopsundd,

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
0
 
LVL 1

Expert Comment

by:TasticVNT
ID: 37831179
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.

http://www.yougetsignal.com/tools/open-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.

-T
0
 
LVL 37

Expert Comment

by:Neil Russell
ID: 37831188
Does the user have a mobile phone that accesses email with activesync maybe? that would be where I start looking.
0
 

Author Comment

by:alexram200
ID: 37831197
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.
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 37

Expert Comment

by:Neil Russell
ID: 37831471
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?
0
 

Author Comment

by:alexram200
ID: 37832390
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.
0
 
LVL 1

Expert Comment

by:TasticVNT
ID: 37833810
Alexram200,

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.

-T
0
 
LVL 1

Accepted Solution

by:
TasticVNT earned 500 total points
ID: 37834026
Alexram200,

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.

http://technet.microsoft.com/en-us/library/cc773155%28v=ws.10%29.aspx

-T
0
 

Author Closing Comment

by:alexram200
ID: 37846789
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.
0

Featured Post

Free Gift Card with Acronis Backup Purchase!

Backup any data in any location: local and remote systems, physical and virtual servers, private and public clouds, Macs and PCs, tablets and mobile devices, & more! For limited time only, buy any Acronis backup products and get a FREE Amazon/Best Buy gift card worth up to $200!

Join & Write a Comment

After playing around with my ASUS 1215n (http://www.asus.de/product.aspx?P_ID=HrglRhH8D60Rmlv3) Netbook, I finally managed to get smooth HD 1080p (http://en.wikipedia.org/wiki/1080p) playback of videos on it. Second Generation Intel Atom (http://en.…
New Windows 7 Installations take days for Windows-Updates to show up and install. This can easily be fixed. I have finally decided to write an article because this seems to get asked several times a day lately. This Article and the Links apply to…
In this Micro Tutorial viewers will learn how to use Boot Corrector from Paragon Rescue Kit Free to identify and fix the boot problems of Windows 7/8/2012R2 etc. As an example is used Windows 2012R2 which lost its active partition flag (often happen…
The viewer will learn how to successfully create a multiboot device using the SARDU utility on Windows 7. Start the SARDU utility: Change the image directory to wherever you store your ISOs, this will prevent you from having 2 copies of an ISO wit…

708 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now