Share via


Get-WinEvent with non-administrative user

Question

Wednesday, December 4, 2013 12:27 PM | 1 vote

he idea here is to give a group of users in a help desk situation the ability to use a powershell script to quickly find out the source of account lockouts. The script is working wonderfully as myself, but a non-privileged user cannot run it.

I've provided access to the "Event Log Readers" group and confirmed a test user can remotely view the event log with eventvwr, but the following command still will not run successfully

Any thoughts?

Get-WinEvent -ComputerName dc01 -FilterHashtable @{logname='security'; id=4771} -ErrorAction Stop

The error is "Get-WinEvent: Could not retrieve information about the Security log. Error: attempted to perform an unauthorized operation."

Again, I can run this exact same command with an elevated account and it works, so I know it is permissions. The problem is finding which.

I've confirmed that logging into the server with the test account and running the command directly on the server still doesn't work--same error.

All replies (10)

Wednesday, December 4, 2013 5:13 PM ✅Answered | 11 votes

OK, I played around with this a bit on a test machine.  In order to get both Get-WinEvent and Get-EventLog working, I had to modify the permissions of the registry key HKLM\System\CurrentControlSet\Services\eventlog\Security , granting Read permission to something other than System / Administrators / eventlog.  I still don't know why this permission change isn't required for the MMC console, but there you go.

Turns out that the "manage auditing and security log" user right wasn't required, so ignore my previous comment.


Wednesday, December 4, 2013 4:29 PM | 1 vote

Users have to be granted the "Manage auditing and security log" user right in order to access the Security event log.  Odds are that right isn't being granted to the Event Log Readers group on your system.


Wednesday, December 4, 2013 4:31 PM

If that's the case, why can I access the security log locally and remotely as the test, non-administrative account?


Wednesday, December 4, 2013 4:38 PM | 1 vote

I'm not sure; I missed that bit when I read your original post.  Could be that the cmdlet or its underlying .NET classes are trying to pull back more information than you really need, whereas the MMC console is using a more focused call to the Win32 API instead.


Wednesday, December 4, 2013 4:54 PM

Try this link:

http://blogs.msdn.com/b/powershell/archive/2009/11/23/you-don-t-have-to-be-an-administrator-to-run-remote-powershell-commands.aspx


Wednesday, December 4, 2013 5:01 PM

Already done that. To re-enforce, I'm currently testing this by running the code directly on the machine without any remote activity happening. Same results.


Wednesday, December 4, 2013 5:17 PM

BOOM!

That did it my man.

Very awesome. Thanks a ton for your help.

Pretty crazy that it's just a read permission on a reg key. /shrug


Thursday, October 26, 2017 8:24 AM

A very Big Thank you from me as well! Been playing around with the event log readers and the Remote Management Users. Got it to work after providing a custom group read access on the registry key.  

Answers provided are coming from personal experience, and come with no warranty of success. I as everybody else do make mistakes.


Tuesday, April 3, 2018 5:55 PM

Can you please elaborate on the "modifying the permissions of the registry key". I can see everyone below has read permission for the registry key HKLM\System\CurrentControlSet\Services\eventlog\Security

Do we need to give read permissions to any other account?

FYI: My situation is exactly the question mentioned in this form - https://social.technet.microsoft.com/Forums/ie/en-US/57b4b3a3-8d1c-40e2-b39f-c058fe71a4fd/only-getwinevent-security-log-on-domain-controllers-fails?forum=winserverpowershell

But the issue still remains for me. Am I missing anything in the permissions of the registry key.

Please do reply back. Thanks in Advance !

surya teja yarlagadda


Friday, June 29, 2018 6:38 PM

I know this is old but I have a solution that I use that has proven very useful.

A script runs on all five of our DCs and is set through the task scheduler to fire on event 4740 (Account locked) in the security log.

The task is scheduled under the system account calls powershell.exe and has ** -noprofile -executionpolicy unrestricted "C:\Scripts\acc_lockout.ps1"** in the Add arguments box.

Whenever an event 4740 (account lock out) fires, the script is run.

It is limited to the last event (-MaxEvent 1) so it gets the last (latest)  occurrence.

The data is parsed and written into a SQL database.

It also sends an email to for testing, it will flood your inbox if you are a large organization, so I comment it out.

This is the complete code for acc_lockout.ps1.

#script to run locally on each dc and pulls security even 4740, then pulls user, pc, etc

$event = Get-WinEvent -FilterHashtable @{LogName='Security';Id=4740} -MaxEvents 1

$ns = @{'ns'='http://schemas.microsoft.com/win/2004/08/events/event'}
$target_xpath = "//ns:Data[@Name='TargetUserName']"
$targetd_xpath = "//ns:Data[@Name='TargetDomainName']"
$subject_xpath = "//ns:Data[@Name='SubjectUserName']"
$UserSID_xpath = "//ns:Data[@Name='SubjectUserSid']"
$TargetSID_xpath = "//ns:Data[@Name='TargetSid']"
$Domain_xpath = "//ns:Data[@Name='SubjectDomainName']"

$xml = $Event.ToXML()
$id = $event.Id
$time = $event.TimeCreated
$user = (Select-Xml -Content $xml -XPath $target_xpath -Namespace $ns).Node.'#text'
$pc = (Select-Xml -Content $xml -XPath $targetd_xpath -Namespace $ns).Node.'#text'
$server = (Select-Xml -Content $xml -XPath $subject_xpath -Namespace $ns).Node.'#text'
$UserSID = (Select-Xml -Content $xml -XPath $UserSID_xpath -Namespace $ns).Node.'#text'
$TargetSID = (Select-Xml -Content $xml -XPath $TargetSID_xpath -Namespace $ns).Node.'#text'
$Domain = (Select-Xml -Content $xml -XPath $Domain_xpath -Namespace $ns).Node.'#text'


if($user -ne "guest"){
$MailBody = " User Account locked at $time `r`r`n User: $user `n Device: $pc `n DCServer: $server `n Domain: $Domain `n
 UserSID: $userSID `n TargetSID: $TargetSID"

$MailSubject= "User Account locked, User: $user - $pc"
$SmtpClient = New-Object system.net.mail.smtpClient
$SmtpClient.host = "exchangeXXXXX.XXXXXX.org"           #SMTP host name
$MailMessage = New-Object system.net.mail.mailmessage
$MailMessage.from = "[email protected]"      #Email from..
$MailMessage.To.add("[email protected]")           #Emil to...
$MailMessage.IsBodyHtml = 0
$MailMessage.Subject = $MailSubject
$MailMessage.Body = $MailBody
$SmtpClient.Send($MailMessage)

#send results to SQL
$conn = New-Object System.Data.SqlClient.SqlConnection
$conn.ConnectionString =  "Data Source=XXXXXXXSQL;Initial Catalog=Interface;Persist Security Info=True;User ID=XXXXXX;PWD=XXXXXX;Initial Catalog=Interface "


$conn.open()
$cmd = New-Object System.Data.SqlClient.SqlCommand
$cmd.connection = $conn
#$cmd.commandtext = "INSERT INTO LockedAccounts (UserName,Computer,Date_Time) VALUES('{0}','{1}','{2}')" -f "$user","$pc","$(get-date -f g)"
$cmd.commandtext = "INSERT INTO LockedAccounts (UserName,Computer,Date_Time,DCserver) VALUES('{0}','{1}','{2}','{3}')" -f "$user","$pc","$(get-date -f g)","$server"
$cmd.executenonquery()
$conn.close()
}

For simple access to the data, I have a web page to query the SQL table for the user name.

The query returns a table of the users lock out history.

This gives our support people instant access to the latest history without any elevated privileges.

They can see the source of the lock out and what time.

This information can help figure out what is going on. There are a couple of examples.

 Suddenly an account starts to lock and the query has our Exchange CAS servers listed. The times are all night.

*Often we have found that this is indicative of pulling an old BYOD out and giving it to their kids or some other activity. I was set up to sync the users email using an old password. *

Or if the password has changed recently and we see the source is a single server, they may have left a disconnected RDP to the server running.

NOTE: Not all authenticating systems will reveal the source name.

We find it quite handy and quick.

NOTE: I don’t presume to have written all of this code. I like most coders, copy examples of how to do this and how to do that, put them together. Pretty soon you have an applicable script. It is not always about the coding. It’s more about the concept, the idea and the usefulness of what you are corbeling together.