PS1 blocked for reading event log?

PowerShell Help
1

I have a very odd problem I cant seem to get figured.

Here is a very simple script:

$XPath = "Event[System[EventID=4740]]"
Get-WinEvent -LogName 'Security' -FilterXPAth $XPath

If I execute this line by line from an Admin PowerShell, I have no issues.

As soon as I save this to a .PS1 and execute, I get the following error:

unable to perform an unauthorized operation

Any ideas on where I might look? I have checked all the registry and event log permissions and they seem to be normal. I also checked:

$ExecutionContext.SessionState.LanguageMode

And it is set to FullLanguage. I am stumped. Thanks in advance for any help/suggestions.

2

Have you tried turning it off and on again?

Haha j/k. How are you executing your script?

3

Google fu led me here:

user accounts - Why am I getting unauthorized errors with Powershell get-winevent? - Server Fault

4

Thanks Rob and Doug for the suggestions.

I wont have access to the systems until Monday.
Rob, I have already validated everything in the post you referred to EXCEPT for the -computerName parameter. I will check that Monday.

I was thinking maybe AppLocker or Device Guard might be the cause and somehow blocking PS1 access to the logs as that simple script fails as a PS1, but not direct from the command line.

Doug, I (far end user actually) was executing the script as such from a Command and PowerShell, failed in both:

PowerShell -ExecutionPolicy Bypass .\test.PS1

Again, thanks for the suggestions. I will post what I find on Monday. The system(s) are air gapped so I dont have direct access. There are actually two systems with the same behavior.

5

OK, I did find out the user is using -ComputerName. So, when you add that, it does fail. We checked just about every network setting I can think of, and also a reboot, and still no joy.

Using -ComputerName ,we tried the FQDN, $ENV:ComputerName, the Netbios name and the ip address, All failed in the same way.

Any ideas on what to check next?

6

IIRC each cmdlet that offered -Computername was implemented in their own remoting (many using DCOM) except of course Remoting commands. This is why the *-Service cmdlets no longer have -ComputerName in core. So my guess would be you can’t connect to event viewer remotely either?

7

Doug, we are going to try the remote connection tomorrow. BTW, I should have mentioned this earlier, the PowerShell version is 5.1.

Basically, the end user is running a very large Script that audits the systems, and it does support remote systems (using the ComputerName argument). The only Cmdlet that uses this argument is Get-WinEvent. Everything else is done via a CimSession.

I was hoping to solve this issue via remote, so I am hoping you are wrong on that :frowning:
Is there any way to get Event Log data (easily) via a CimSession?

I had a look at the PowerShell source and the issue seems to be related to creating an EventLogSession. One thing I noticed in the source is they fall back to setting the computername to “localhost” if the ComputerName argument is not present. I did NOT try that in my testing with the user. I will try that tomorrow using:

-ComputerName 'localhost'

And see if this works.

I did have them ping localhost and that worked.

8

Trying with Localhost produces the same error:

“attempted to perform an illegal operation”

And, coming at it remotely gives the same error (as you suspected). Test-WsMan works properly. What would I check in the DCOM settings to possibly resolve this?

Thanks Doug.

9

Nothing in dcom. Need to allow remote event viewer in firewall.

10

Thanks Doug. We already tried disabling all firewalls, still no joy.

11

Doug … posting this as it may help someone in the future.

To summarize, any time we used Get-WinEvent with the -ComputerName argument (either local shell or remote), we were getting “Attempted to perform an unauthorized operation”. All permissions were proper everywhere. The “fix” was under
/Computer Configuration/Admin Templates/System/Remote Procedure Call/Restrict Unauthenticated RPC Clients.

We changed from “Enabled:Authenticated without exceptions”
To: “Enabled:Authenticated”

FYI

1 Like
12

Is that the only computer with that configuration or are others configured the same yet still working?

13

So, out of 8 systems, two were failing. Setting not pushed via AD GPO, was Local GPO. The fix worked on both BTW. The working systems were set to Authenticated.

1 Like