Windows Account Lock Outs for single user
One of our users keeps getting their account locked out, but for this user, eventcombMT.exe doesn't return any results for the Account Lockouts search.
I've not found anything obvious in the users own event logs either.
We have a Windows 2008 domain with a mixture of XP SP3 and Windows 7 clients. The client experiencing this issue is Window 7, but he also uses an XP PC that he remotes on to.
I've not found anything obvious in the users own event logs either.
We have a Windows 2008 domain with a mixture of XP SP3 and Windows 7 clients. The client experiencing this issue is Window 7, but he also uses an XP PC that he remotes on to.
Chris
Do you use exchange on your domain? I've seen it before where user's are using activsync on their phones. When they change their password on the domain, certain phones keep trying to log in using the old pw but don't prompt the user to enter their new one. Obviously this eventually leads to the account being locked out.
ASKER
Yes, we use out own Exchange, which is version 2007, however a 2010 Exchange server was recently added to our Exchange organisation which currently doesnt have any mailboxes on it.
The user isn't using any handheld devices either.
The user isn't using any handheld devices either.
The culprit is typically a mapped network drive with invalid credentials.
You can track the bad account attempts if you are auditing on your DCs.
You can track the bad account attempts if you are auditing on your DCs.
What event I'd in the security pool are you looking for?
529,
Does the lockout tool point to the dc that is the source of the lockout?
529,
Does the lockout tool point to the dc that is the source of the lockout?
ASKER
I will doube check the mapped drive theory, as I was assured this wasn't the case... hence not seen with my own eyes.
The tool looks for event 529, 644, 675, 676 and 681 and its finds nothing, which I can verify by examining the log myself. Very odd!
GPO for DCs is set to audit failure on 'Audit account logon events' and 'Audit logon events'.
I've also configured Netlogon auditing, but I'm not really sure what to look for. Entries do exist in the log for the users PC's, but nothing references his user account.
The tool looks for event 529, 644, 675, 676 and 681 and its finds nothing, which I can verify by examining the log myself. Very odd!
GPO for DCs is set to audit failure on 'Audit account logon events' and 'Audit logon events'.
I've also configured Netlogon auditing, but I'm not really sure what to look for. Entries do exist in the log for the users PC's, but nothing references his user account.
When an account is locked out, which dc does the tool says locked it out?
The default behavior is record many data points in the security log for logon attempts.
The system should reflect any failed logon attempt in the security log on a dc. Try providing an incorrect login and see if it gets recorded, if it does not, it would mean that the auditing you set may be overriding default settings.
The default behavior is record many data points in the security log for logon attempts.
The system should reflect any failed logon attempt in the security log on a dc. Try providing an incorrect login and see if it gets recorded, if it does not, it would mean that the auditing you set may be overriding default settings.
ASKER
We have 2 DCs, one has recently been added to a remote site (currently not configured as a separate site) and the other is local.
Initially, most locks occured on the remote site, so I turned the remote DC off and now the locks occur on the local DC, so I cant see it being DC specific.
I can try the forced password failure attempt, but as there are no events indicative of incorrect password attempts since 24th May, it makes me think there is a problem somewhere else. I cant confirm if this has happed, but could a domain promotion from 2003 level to 2008 have caused this?
Initially, most locks occured on the remote site, so I turned the remote DC off and now the locks occur on the local DC, so I cant see it being DC specific.
I can try the forced password failure attempt, but as there are no events indicative of incorrect password attempts since 24th May, it makes me think there is a problem somewhere else. I cant confirm if this has happed, but could a domain promotion from 2003 level to 2008 have caused this?
If you generate a failed login and it does not appear on the remaining dc, it means you altered the auditing policy of the default domain controller policy unnecessarily.
Use gpmc to run the computer group policy wizard to make sure the audit parameters have not been disabled.
Use gpmc to run the computer group policy wizard to make sure the audit parameters have not been disabled.
Verify that you are indeed auditing failed account logon attempts on your DCs.
Computer Configuration -> Windows Settings -> Security Settings -> Local Policy:
Audit account logon events -> Failed
Computer Configuration -> Windows Settings -> Security Settings -> Local Policy:
Audit account logon events -> Failed
ASKER
Both GPMC and Local Policy checks tell me that auditing it on.
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
http://www.windowsecurity.com/articles/event-ids-windows-server-2008-vista-revealed.html
Does the user resume a running session on the xp?
What about event I'd 4625?
http://www.windowsecurity.com/articles/event-ids-windows-server-2008-vista-revealed.html
Does the user resume a running session on the xp?
What about event I'd 4625?
http://www.windowsecurity.com/articles/event-ids-windows-server-2008-vista-revealed.html
Now that you found some events. You can determine how the account is being locked out by looking at the logon type.
Logon Type 2 – Interactive
This is what occurs to you first when you think of logons, that is, a logon at the console of a computer. You’ll see type 2 logons when a user attempts to log on at the local keyboard and screen whether with a domain account or a local account from the computer’s local SAM. To tell the difference between an attempt to logon with a local or domain account look for the domain or computer name preceding the user name in the event’s description. Don’t forget that logon’s through an KVM over IP component or a server’s proprietary “lights-out” remote KVM feature are still interactive logons from the standpoint of Windows and will be logged as such.
Logon Type 3 – Network
Windows logs logon type 3 in most cases when you access a computer from elsewhere on the network. One of the most common sources of logon events with logon type 3 is connections to shared folders or printers. But other over-the-network logons are classed as logon type 3 as well such as most logons to IIS. (The exception is basic authentication which is explained in Logon Type 8 below.)
Logon Type 4 – Batch
When Windows executes a scheduled task, the Scheduled Task service first creates a new logon session for the task so that it can run under the authority of the user account specified when the task was created. When this logon attempt occurs, Windows logs it as logon type 4. Other job scheduling systems, depending on their design, may also generate logon events with logon type 4 when starting jobs. Logon type 4 events are usually just innocent scheduled tasks startups but a malicious user could try to subvert security by trying to guess the password of an account through scheduled tasks. Such attempts would generate a logon failure event where logon type is 4. But logon failures associated with scheduled tasks can also result from an administrator entering the wrong password for the account at the time of task creation or from the password of an account being changed without modifying the scheduled task to use the new password.
Logon Type 5 – Service
Similar to Scheduled Tasks, each service is configured to run as a specified user account. When a service starts, Windows first creates a logon session for the specified user account which results in a Logon/Logoff event with logon type 5. Failed logon events with logon type 5 usually indicate the password of an account has been changed without updating the service but there’s always the possibility of malicious users at work too. However this is less likely because creating a new service or editing an existing service by default requires membership in Administrators or Server Operators and such a user, if malicious, will likely already have enough authority to perpetrate his desired goal.
Logon Type 7 – Unlock
Hopefully the workstations on your network automatically start a password protected screen saver when a user leaves their computer so that unattended workstations are protected from malicious use. When a user returns to their workstation and unlocks the console, Windows treats this as a logon and logs the appropriate Logon/Logoff event but in this case the logon type will be 7 – identifying the event as a workstation unlock attempt. Failed logons with logon type 7 indicate either a user entering the wrong password or a malicious user trying to unlock the computer by guessing the password.
Logon Type 8 – NetworkCleartext
This logon type indicates a network logon like logon type 3 but where the password was sent over the network in the clear text. Windows server doesn’t allow connection to shared file or printers with clear text authentication. The only situation I’m aware of are logons from within an ASP script using the ADVAPI or when a user logs on to IIS using IIS’s basic authentication mode. In both cases the logon process in the event’s description will list advapi. Basic authentication is only dangerous if it isn’t wrapped inside an SSL session (i.e. https). As far as logons generated by an ASP, script remember that embedding passwords in source code is a bad practice for maintenance purposes as well as the risk that someone malicious will view the source code and thereby gain the password.
Logon Type 9 – NewCredentials
If you use the RunAs command to start a program under a different user account and specify the /netonly switch, Windows records a logon/logoff event with logon type 9. When you start a program with RunAs using /netonly, the program executes on your local computer as the user you are currently logged on as but for any connections to other computers on the network, Windows connects you to those computers using the account specified on the RunAs command. Without /netonly Windows runs the program on the local computer and on the network as the specified user and records the logon event with logon type 2.
Logon Type 10 – RemoteInteractive
When you access a computer through Terminal Services, Remote Desktop or Remote Assistance windows logs the logon attempt with logon type 10 which makes it easy to distinguish true console logons from a remote desktop session. Note however that prior to XP, Windows 2000 doesn’t use logon type 10 and terminal services logons are reported as logon type 2.
Logon Type 11 – CachedInteractive
Windows supports a feature called Cached Logons which facilitate mobile users. When you are not connected to the your organization’s network and attempt to logon to your laptop with a domain account there’s no domain controller available to the laptop with which to verify your identity. To solve this problem, Windows caches a hash of the credentials of the last 10 interactive domain logons. Later when no domain controller is available, Windows uses these hashes to verify your identity when you attempt to logon with a domain account.
Logon Type 2 – Interactive
This is what occurs to you first when you think of logons, that is, a logon at the console of a computer. You’ll see type 2 logons when a user attempts to log on at the local keyboard and screen whether with a domain account or a local account from the computer’s local SAM. To tell the difference between an attempt to logon with a local or domain account look for the domain or computer name preceding the user name in the event’s description. Don’t forget that logon’s through an KVM over IP component or a server’s proprietary “lights-out” remote KVM feature are still interactive logons from the standpoint of Windows and will be logged as such.
Logon Type 3 – Network
Windows logs logon type 3 in most cases when you access a computer from elsewhere on the network. One of the most common sources of logon events with logon type 3 is connections to shared folders or printers. But other over-the-network logons are classed as logon type 3 as well such as most logons to IIS. (The exception is basic authentication which is explained in Logon Type 8 below.)
Logon Type 4 – Batch
When Windows executes a scheduled task, the Scheduled Task service first creates a new logon session for the task so that it can run under the authority of the user account specified when the task was created. When this logon attempt occurs, Windows logs it as logon type 4. Other job scheduling systems, depending on their design, may also generate logon events with logon type 4 when starting jobs. Logon type 4 events are usually just innocent scheduled tasks startups but a malicious user could try to subvert security by trying to guess the password of an account through scheduled tasks. Such attempts would generate a logon failure event where logon type is 4. But logon failures associated with scheduled tasks can also result from an administrator entering the wrong password for the account at the time of task creation or from the password of an account being changed without modifying the scheduled task to use the new password.
Logon Type 5 – Service
Similar to Scheduled Tasks, each service is configured to run as a specified user account. When a service starts, Windows first creates a logon session for the specified user account which results in a Logon/Logoff event with logon type 5. Failed logon events with logon type 5 usually indicate the password of an account has been changed without updating the service but there’s always the possibility of malicious users at work too. However this is less likely because creating a new service or editing an existing service by default requires membership in Administrators or Server Operators and such a user, if malicious, will likely already have enough authority to perpetrate his desired goal.
Logon Type 7 – Unlock
Hopefully the workstations on your network automatically start a password protected screen saver when a user leaves their computer so that unattended workstations are protected from malicious use. When a user returns to their workstation and unlocks the console, Windows treats this as a logon and logs the appropriate Logon/Logoff event but in this case the logon type will be 7 – identifying the event as a workstation unlock attempt. Failed logons with logon type 7 indicate either a user entering the wrong password or a malicious user trying to unlock the computer by guessing the password.
Logon Type 8 – NetworkCleartext
This logon type indicates a network logon like logon type 3 but where the password was sent over the network in the clear text. Windows server doesn’t allow connection to shared file or printers with clear text authentication. The only situation I’m aware of are logons from within an ASP script using the ADVAPI or when a user logs on to IIS using IIS’s basic authentication mode. In both cases the logon process in the event’s description will list advapi. Basic authentication is only dangerous if it isn’t wrapped inside an SSL session (i.e. https). As far as logons generated by an ASP, script remember that embedding passwords in source code is a bad practice for maintenance purposes as well as the risk that someone malicious will view the source code and thereby gain the password.
Logon Type 9 – NewCredentials
If you use the RunAs command to start a program under a different user account and specify the /netonly switch, Windows records a logon/logoff event with logon type 9. When you start a program with RunAs using /netonly, the program executes on your local computer as the user you are currently logged on as but for any connections to other computers on the network, Windows connects you to those computers using the account specified on the RunAs command. Without /netonly Windows runs the program on the local computer and on the network as the specified user and records the logon event with logon type 2.
Logon Type 10 – RemoteInteractive
When you access a computer through Terminal Services, Remote Desktop or Remote Assistance windows logs the logon attempt with logon type 10 which makes it easy to distinguish true console logons from a remote desktop session. Note however that prior to XP, Windows 2000 doesn’t use logon type 10 and terminal services logons are reported as logon type 2.
Logon Type 11 – CachedInteractive
Windows supports a feature called Cached Logons which facilitate mobile users. When you are not connected to the your organization’s network and attempt to logon to your laptop with a domain account there’s no domain controller available to the laptop with which to verify your identity. To solve this problem, Windows caches a hash of the credentials of the last 10 interactive domain logons. Later when no domain controller is available, Windows uses these hashes to verify your identity when you attempt to logon with a domain account.
Event I'd 4771, Is an informational event and I do not think it leads to an account lockout nor does it provide info if an account got locked out, why that happened.
http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4771
http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4771
Are you filtering? It really helps save a lot of time.
pre-authentication failed: usually means that the clocks are out of sync by more than 5 minutes.
Error 0x12 - means locked out http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4771
Error 0x12 - means locked out http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4771
ASKER
I got the user to check the server identified in event 4771 and he found he had an active RDP connection to it, which asked him to verify his connection! After logging off properly, there have been no further events.
I noticed lots of event 4769 that referenced his account prior to him logging off, but they stopped roughly before I unlocked his account and him logging off his RDP connection to the suspect server. There where other users referenced in other events of this type, but it was mainly for this user.
So far it looks like this is case closed. Event 4771 to the rescue!!!.... but I will monitor if for a few more hours.
Event 4769 as follows:
A Kerberos service ticket was requested.
Account Information:
Account Name: LOCKEDUSERNAME@DOMAIN.CO.U
Account Domain: FSI.CO.UK
Logon GUID: {00000000-0000-0000-0000-0
Service Information:
Service Name: exchangeRFR/EXCHANGESVR.DO
Service ID: NULL SID
Network Information:
Client Address: ::ffff:##.##.##.##
Client Port: 57090
Additional Information:
Ticket Options: 0x40810000
Ticket Encryption Type: 0xffffffff
Failure Code: 0x12
Transited Services: -
I noticed lots of event 4769 that referenced his account prior to him logging off, but they stopped roughly before I unlocked his account and him logging off his RDP connection to the suspect server. There where other users referenced in other events of this type, but it was mainly for this user.
So far it looks like this is case closed. Event 4771 to the rescue!!!.... but I will monitor if for a few more hours.
Event 4769 as follows:
A Kerberos service ticket was requested.
Account Information:
Account Name: LOCKEDUSERNAME@DOMAIN.CO.U
Account Domain: FSI.CO.UK
Logon GUID: {00000000-0000-0000-0000-0
Service Information:
Service Name: exchangeRFR/EXCHANGESVR.DO
Service ID: NULL SID
Network Information:
Client Address: ::ffff:##.##.##.##
Client Port: 57090
Additional Information:
Ticket Options: 0x40810000
Ticket Encryption Type: 0xffffffff
Failure Code: 0x12
Transited Services: -
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
I accepted my comment as the solution, as it was event 4771 that led me to the culprit. Points have been awarded appropriately as it was Motnahp00 who suggested I trawl the security logs on the server and Arnold who spelt out the answer for the readers, even though I new it. ;-)