What is the event id in Event Viewer for lock, unlock for a computer in Windows XP, Windows 7, Windows Vista and Windows Server 2008?
The lock event ID is 4800, and the unlock is 4801. You can find them in the Security logs. You probably have to activate their auditing using Local Security Policy (secpol.msc, Local Security Settings in Windows XP) -> Local Policies -> Audit Policy. For Windows 10 see the picture below.
Look in Description of security events in Windows 7 and in Windows Server 2008 R2 under Subcategory: Other Logon/Logoff Events.
You will need to enable logging of these events. Do so by opening the group policy editor:
run -> gpedit.msc
and configuring the following category:
Computer Configuration ->
Windows Settings ->
Security Settings ->
Advanced Audit Policy Configuration ->
System Audit Policies - Local Group Policy Object ->
Logon/Logoff ->
Audit Other Login/Logoff Events
(In the Explain tab it says "... allows you to audit ... Locking and unlocking a workstation".)
For newer versions of Windows (including but not limited to both Windows 10 and Windows Server 2016), the event IDs are:
4800 - The workstation was locked.
4801 - The workstation was unlocked.
Locking and unlocking a workstation also involve the following logon and logoff events:
4624 - An account was successfully logged on.
4634 - An account was logged off.
4648 - A logon was attempted using explicit credentials.
When using a Terminal Services session, locking and unlocking may also involve the following events if the session is disconnected, and event 4778 may replace event 4801:
4779 - A session was disconnected from a Window Station.
4778 - A session was reconnected to a Window Station.
Events 4800 and 4801 are not audited by default, and must be enabled using either Local Group Policy Editor (gpedit.msc) or Local Security Policy (secpol.msc).
The path for the policy using Local Group Policy Editor is:
Local Computer Policy
Computer Configuration
Windows Settings
Security Settings
Advanced Audit Policy Configuration
System Audit Policies - Local Group Policy Object
Logon/Logoff
Audit Other Logon/Logoff Events
The path for the policy using Local Security Policy is the following subset of the path for Local Group Policy Editor:
Security Settings
Advanced Audit Policy Configuration
System Audit Policies - Local Group Policy Object
Logon/Logoff
Audit Other Logon/Logoff Events
The event IDs to look for in pre-Vista Windows are 528, 538, and 680. 528 usually stands for successful unlock of workstation.
The codes for newer Windows versions differ, see below answers for more infos.
Unfortunately there is no such a thing as Lock/Unlock. What you have to do is:
Click on "Filter Current Log..."
Select the XML tab and click on "Edit query manually"
Enter the below query:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[EventData[Data[#Name='LogonType']='7']
and
(System[(EventID='4634')] or System[(EventID='4624')])
]</Select>
</Query>
</QueryList>
That's it
To identify unlock screen I believe that you can use ID 4624. But then you also need to look at the Logon Type which in this case is 7: http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4624
Event ID for Logoff is 4634
Security Settings -> Advanced Audit Policy -> System Audit -> Logon/Logoff -> Audit Other Logon/Off Events -> On Success
Enables the following:
4800 - workstation locked
4801 - workstation unlocked
4802 - screensaver invoke
4803 - screensaver dismissed
Windows 10 professional
For Windows 10 the event ID for lock=4800 and unlock=4801.
As it says in the answer provided by Mario and User 00000, you will need to enable logging of lock and unlock events by using their method described above by running gpedit.msc and navigating to the branch they indicated:
Computer Configuration ->
Windows Settings ->
Security Settings ->
Advanced Audit Policy Configuration ->
System Audit Policies - Local Group Policy Object ->
Logon/Logoff ->
Audit Other Login/Logoff
Enable for both success and failure events.
After enabling logging of those events you can filter for Event ID 4800 and 4801 directly.
This method works for Windows 10 as I just used it to filter my security logs after locking and unlocking my computer.
Using Windows 10 Home edition. I was unable to get my event viewer to capture events 4800 and 4801, even after installing the Windows Group Policy Editor, enabling auditing on all the relevant events, and restarting the computer. However, I was able to discover other events that are tied to locking and unlocking that you can use as accurate and reliable indicators of when the PC was locked. See configurations below - the first is for PC Locked (the event connected to displaying C:\Windows\System32\LogonUI.exe) - and the second is for PC Unlocked (the event for successful logon).
Related
I have been trying to get the event viewer logs of application, security and system and store the output into an xml file. While application and system work just fine I have been having problems with security.
The Security event log is secured to machine administrators only.
As you've added your account to the "Event Log Readers" group, you need to add the "BUILTIN\Event Log Readers" group to the following registry key permissions:
HKLM\System\CurrentControlSet\Services\Eventlog\Security
This key only
Query Value, Enumerate Subkeys, Notify, Read Control
On a domain you can do this using group policy to cover all machines:
Group Policy Object Editor: Computer Configuration > Policies > Windows Settings > Security Settings
enter image description here
In windows server 2012 R2, I checked the boxes of Audit these attempts: Success , Failure , then the Security Setting of this policy is in "Success, Failure" status. But after around 10 muinutes, the status was changed to "No auditing" automatically and the boxes were unchecked. I checked the DC local policy was not overritten by global policy. And other DCs in my domain did not have this problem. Does anyone have idea or encountered similar situation?
Thanks
Below articles are about how to Audit account logon events, which may be helpful to you:
Audit account logon events
Enable Active Directory Logon/Logoff Audit events
Audit Successful Logon/Logoff and Failed Logons in Active Directory
I have Windows server 2012 R2 azure virtual instance and few ports are open on it i.e. (80,443,RDC). I have observed the below logs into windows event viewer in security section.
Event 4625 : Microsoft windows security auditing
-------log description start
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: ALLISON
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:
Source Network Address: -
Source Port: -
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.
-------log description end
The logs are continuously generating in event viewer (3-4 request per second) and account name always changes as mention below.
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: ATCNSBAYFG
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: SUPPORT
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: SUPPORT
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: HAYLEY
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: TEST5
and more...
What I tried:
1. Disabled the all open ports from azure portal even RDC.
2. Disabled the Windows Essentials services.
3. Disabled Alert Evaluations task from windows scheduler.
but still the logs are generating in event viewer. Is this windows attacked or some thing else? and how to prevent this?
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
For testing, remove EVERYONE from folder and use local group Users with modify permission instead of EVERYONE.
4625: An account failed to log on
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4625
Some application usually use the guest account to achieve some function, if you worry about the safety you can keep the disable or enable base on your practical application.
Can you turn on failure auditing for authentication attempts?
Get help fro this auditing solution to track the source of failed logon attempts in Active Directory.
Hope this helps!
I was looking for answer to this and came across this post. In the end I raised a paid Microsoft support case which came up with the following solution and wanted to share in case it helps anyone in the future:
Export the .cer file used for the WCF connection (unless it available elsewhere already):
a. Launch the manage local computer certificates mmc plugin
b. Navigate to Trusted People > Certificates
c. Right click on the coreapi.server01.gold.nas.faa.gov cert and click All tasks > Export.
d. Click Next
e. Click Next (DER encoded binary X.509 (.CER) is fine).
f. Choose a sensible place to export (i.e. Documents)
g. Click Next
h. Click Finish
i. Click OK on dialog that pops up.
Open Windows administrative tools from the start menu
Double click on Active Directory Users and Computers
In the menu click on View > Advanced Features
Double click on Users
Right click on suitable account (You can use any account I think but I used our special services account. The Microsoft support engineer also implied you can use a computer too)
Click on Name Mappings…
Click Add
Select exported cert from step 1.
Click Open
Click OK (leave both identity Mapping options ticked)
Click OK.
No need to reboot. The login failure is replaced with a login success (4648) which shouldn't trigger an intrusion detection issues.
I'm looking to setup a Queue Manager Using WebSphere MQ V7 MQ Explorer.
After Creating my Queue Manager, normally I expect that some sub directories are automatically generated under it, "Queues", "Topics", "Channels" .. as illustrated in the photo below.
In my case, no sub directories are generated, as illustrated below in the second snapshot.
PS: the status of my Queue manager is : Running but disconnected from WebSphere MQ Explorer.
When I right-click on the QMgr Name and choose Connect, I get "An unexpected error (2063) has occurred (AMQ4999)"
Could you advise please about a possible cause of this behavior ?
Administrative tools -> Local Security Policy -> Local Policies -> User Rights Assignment -> Log on as a service -> Properties -> add your user here
Same problem with MQ v9 and i solved it this way.
Go to control panel – Administrative tools
Control Panel\All Control Panel Items\Administrative Tools
Local
Inside Local Security Policy
Enter your domain user name then click check names – finalize by clicking ok. Then apply.
Now the domain user can log on as a service – Now open the services running on your machine.
Double click on the MQ service – then go on log on tab
Then apply click okay button – from the restart your machine for the changes to take effect
Finally open WebSphere MQ Explorer as admin - queue manager should be able to connect
Same issue with MQ 9.0 installed on Windows 10 EE.
(Run as Administrator) secpol.msc /s
(open) Local Policies > User Rights Assignment > Log on as a service
then add your User. Same user should be used for "IBM MQ (Installation1)" (Properties> Log On), installation default (when you do not setup the Domain Policy during installation) is MUSR_MQADMIN.
(Maybe you can try to run "MQ Explorer" as MUSR_MQADMIN user, but it's password is automatically generated during the installation. It's possible to change it, but it doesn't seem to be a safer against the using local account to run the MQ service)
I'm curious to know the order of Windows startup during a user login. Does anyone know?
Basically, my application was being invoked by login script that a GPO calls. While 3rd party EXE was being invoked, it was failing to start.
Then, through trial and error, I found that HKCU...\RunOnce keys execute after the login script. Same result, the EXE was being called, but failing to start.
What worked: updated the login script create a shortcut in the user's Startup folder. Now the EXE starts up as expected.
I know that AutoRuns can tell me all the locations where startup items can be placed, does anyone know the execution order as a whole? I was able to find that Run and RunOnce keys get called asynchronously. I can keep testing each startup item that AutoRuns states, but this could take days.
I'm mostly interested in Windows 2003 Server login startup flow, but I would suspect its very similar to other Windows flavors in use today.
Source: Understanding the Startup Process - Windows 7 Tutorial
The normal startup sequence for Windows 7 is:
Power-on self test (POST) phase
Initial startup phase
Windows Boot Manager phase
Windows Boot Loader phase
Kernel loading phase
Logon phase
Kernel Loading Phase The Windows Boot Loader is responsible for loading the Windows kernel (Ntoskrnl.exe) and the HAL into memory.
Together, the kernel and the HAL initialize a group of software
features that are called the Windows executive. The Windows executive
processes the configuration information stored in the registry in
HKLM\SYSTEM\CurrentControlSet and starts services and drivers. The
following sections provide more detail about the kernel loading phase.
Logon Phase
The Windows subsystem starts Winlogon.exe, a system service that
enables you to log on and log off. Winlogon.exe then does the
following:
Starts the Services subsystem (Services.exe), also known as the SCM. The SCM initializes services that the registry entry Start
designates as Autoload in the registry subkey
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Servicename.
Starts the Local Security Authority (LSA) process (Lsass.exe).
Parses the Ctrl+Alt+Delete key combination at the Begin Logon prompt (if the computer is part of an
AD DS domain).
The logon user interface (LogonUI) feature and the credential provider
(which can be the standard credential provider or a third-party
credential provider) collect the user name and password (or other
credentials) and pass this information securely to the LSA for
authentication. If the user supplied valid credentials, access is
granted by using either the default Kerberos V 5 authentication
protocol or Windows NT LAN Manager (NTLM).
Winlogon initializes security and authentication features while PnP
initializes auto-load services and drivers. After the user logs on,
the control set referenced by the registry entry LastKnownGood
(located in HKLM\SYSTEM\Select) is updated with the contents in the
CurrentControlSet subkey. By default, Winlogon then starts
Userinit.exe and the Windows Explorer shell. Userinit may then start
other processes, including:
Group Policy settings take effect Group Policy settings that apply to the user and computer take effect.
Startup programs run When not overridden by Group Policy settings, Windows starts logon scripts, startup programs, and services
referenced in the following registry subkeys and file system folders:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Runonce
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
SystemDrive\Documents and Settings\All Users\Start Menu\Programs\Startup
SystemDrive\Documents and Settings\username\Start Menu\Programs\Startup
Several applications might be configured to start by default after you
install Windows, including Windows Defender. Computer manufacturers or
IT departments might configure other startup applications.
Windows startup is not complete until a user successfully logs on to
the computer. If startup fails during the logon phase, you have a
problem with a service or application configured to start
automatically.
If you want further information check the source link.