If you start getting large number of failed login attempts then it could be an indication of a security thread. Here we will see the steps to troubleshoot this issue.

Step 1: First you have to run gpmc.msc to Configure Group Policy Audit Settings

Step 2: Then you have to edit domain’s Default Domain Policy which is in the Group Policy Management Editor.

Step 3: Now you have to expand computer configuration->Windows Settings->Security Settings -> Local Policies -> Audit Policy and then double-click ‘Audit logon events’.

Step 4: After that in the Audit logon event properties, you have to select the Security Policy Setting tab and select Success.

Step 5: Now open command prompt and then run the command gpupdate/force to update Group Policy.

Step 6: To get in detailed about the failed logon events, filter the Security Event Log for Event ID 4625.

Step 7: Now double-click on the event to see details of the source from where the failed logon attempts were made.

Windows Event ID 4625: An account failed to log on

From security point of view we can say that this is a useful event because it documents each and every failed attempt to logon to the local computer apart from this logon type, location and type of account.

Examples of 4625

[stextbox id=’info’]

An account failed to log on.

Subject:
Security ID:  NULL SID
Account Name:  –
Account Domain:  –
Logon ID:  0x0
Logon Type:  3
Account For Which Logon Failed:
Security ID:  NULL SID
Account Name:  asdf
Account Domain:
Failure Information:
Failure Reason:  Unknown user name or bad password.
Status:   0xc000006d
Sub Status:  0xc0000064
Process Information:
Caller Process ID: 0x0
Caller Process Name: –
Network Information:
Workstation Name: WIN-R9H529RIO4Y
Source Network Address: 10.42.42.201
Source Port:  53176
Detailed Authentication Information:
Logon Process:  NtLmSsp
Authentication Package: NTLM
Transited Services: –
Package Name (NTLM only): –
Key Length:  0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.

• Transited services indicate which intermediate services have participated in this logon request.
• Package name indicates which sub-protocol was used among the NTLM protocols
• Key length indicates the length of the generated session key. This will be 0 if no session key was requested

[/stextbox]

 

How to Troubleshoot Account Lockout in Active Directory

Here are the steps to troubleshoot account lockout issue in the Active Directory using Microsoft Account Lockout and Management Tools.

Microsoft Account Lockout and Management Tools:

Microsoft “Account Lockout and Management Tools” are included with AlTools.exe that assist you in managing accounts and in troubleshooting account lockouts.

http://www.microsoft.com/en-us/download/details.aspx?id=18465

Also, you can enable auditing at the domain level for the security events to effectively troubleshoot account lockout.

LockoutStatus Tool:

Account Lockout Status i.e. LockoutStatus.exe which displays lockout information about a particular user account State and Lockout Time on each Domain Controller.

Run the LockoutStatus.exe > File menu > Select target > Define Target User Name and Target Domain Name > OK

EventCombMT Tool:

You can use EventCombMT tool to search the event logs of several different computers for specific events, all from one central location.

Note: The EventCombMT utility is included in the Account Lockout and Management Tools download (ALTools.exe).

To search the event logs for account lockouts -> Start EventCombMT ->Right Click on Select to search field > Choose Get DCs in Domain > Mark your Domain Controllers for search

After that on the Searches menu, point to Built In Searches, and then click Account Lockouts.

Note: for Windows Server 2008 and above replace Event ID field values with 4740

Then click Search and wait for the process to complete the operation.

Possible Root Causes for Account Lockouts:

Persistent drive mappings
Mobile devices using domain services like Exchange mailbox
Service Accounts using cached passwords
Scheduled tasks
Programs using stored credentials
Misconfigured domain policy settings issues
Disconnected Terminal Server sessions
Active Directory delayed replication

View Saved Credentials on a Given System:

From a (run as admin) command prompt run:    psexec -i -s -d cmd.exe

From the new DOS window run:  rundll32 keymgr.dll, KRShowKeyMgr > Ok

Remove any items that appear in the list of Stored User Names and Passwords.

Restart the computer.

One can also use Netplwiz (Windows Server 2008 or above):
Start > Run > type in: netplwiz > OK
Click Advanced tab and then click Manage Passwords.

Enable and Disable Netlogon Logging:

To Enable:

Start > Run > type in:
nltest /dbflag:2080ffff > OK
After you restart Net Logon service, related activity may be logged to %windir%/debug/netlogon.log

To Disable:

Start > Run > type in:
nltest /dbflag:0 > OK

 

Common Causes for Account Lockouts – Resolution and Troubleshooting Steps:

In order to avoid account lockouts, you need to check each computer on which a lockout occurred for the following reasons:

Programs:

Most of the 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.

Bad Password Threshold is set too low:

Bad password threshold is one of the most common misconfiguration issues. Many companies/organizations set the Bad Password Threshold registry value to a value lower than the default value of 10.

User logging on to multiple computers:

Most of the time this happens user logon on multiple computers at one time and the running programs access network resources with the user credentials and If user change password in one computer and the program running in other computer using old/original password and when those programs authenticate they request access to network and then the old password continues to be used and user account becomes lockout. To avoid this user must logoff from all computers then change password from one after that logoff and logon back.

 Stored user names and passwords retain redundant credentials:

The credentials are redundant because Windows tries the logon credentials when explicit credentials are not found.

Scheduled tasks:

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

Persistent drive mappings:

Many times happens that the Persistent drives established with credentials that subsequently expired. When user type explicit credentials to connect a share, the credential is not persistent unless those credentials explicitly saved by Stored User Names and Passwords. Whenever the user logs off / 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. In order to avoid this behavior, you have to configure net use so that is does not make persistent connections.

Active Directory replication:

You need to verify that the proper Active Directory replication is occurring.

Disconnected Terminal Server sessions:

Always update authentication information because it happens that the Disconnected Terminal Server sessions running a process that accesses network resources with outdated authentication information.

Service accounts:

By default, most computer services are configured to start in the security context of the Local System account. Also, 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.

Internet Information Services:

By default, IIS uses a token-caching mechanism that locally caches user account authentication information. If lockouts are limited to users who try to gain access to Exchange mailboxes through Outlook Web Access and IIS, you can resolve the lockout by resetting the IIS token cache.

Old Connections:

Stored server connections can be displayed by opening a command prompt and running the command …

rundll32.exe keymgr.dll, KRShowKeyMgr

Then you can delete the old connections keys