- June 27, 2016 at 8:17 pm #44980
I am in the process of creating a remoting endpoint to grant permission to read the Security event logs. I've created a group and placed it in the Event Log Readers group. This lets me read the Security events by opening eventvwr.msc. However, I am still getting 'unauthorized operation' errors when trying to read the events via:
Get-WinEvent -logname Security
Get-EventLog -logname Security
Oddly enough, I can get the events with a WMI query:
Get-WmiObject -Query "Select * from win32_ntlogevent where (logfile='security')"
Are there additional permissions I need to configure in order to read events via Get-WinEvent?June 27, 2016 at 8:21 pm #44987
You're getting an error when running these commands inside the endpoint you've created? And are the commands attempting to read from the local computer where the endpoint exists, or from a remote computer?June 27, 2016 at 8:34 pm #44993
Yes, I am getting the error when running the commands both inside and outside the endpoint.
The commands are attempting to read from the local computer where the endpoint exists, but I am getting the error while connected to the default PS endpoint as well (microsoft.powershell).June 27, 2016 at 8:49 pm #44996
It's entirely possible that the ports needed to communicate with those services aren't open, although I'd think that'd "break" the GUI as well, so that might not be it.
My other guess would be authentication. When you're using the GUI, you're making one "hop" to the service, from the computer the GUI is running on to the machine you're querying. But with remoting, your first "hop" is a delegated authentication into the endpoint. From there, _if those commands are actually making a network request_, you're on a second "hop" which by default would not carry a security token. It'd be an anonymous request, in other words, which would likely fail. Get-WmiObject works a little differently _when you query against localhost_ – it deliberately makes a local repository connection, so it'd make sense that it's working.
This is a little tricky to fix. Especially with older protocols like RPC/DCOM (Get-EventLog), turning on CredSSP might not help. But, it's worth reading about the double hop problem ("Secrets of PowerShell Remoting", our Ebooks menu) so you understand the potential problem.
A potential fix is to assign a RunAs Credential to your custom endpoint. THAT credential would need permission to read the event logs, but the people remoting into the endpoint would not. You could then lock down who was allowed to enter the endpoint by using a group, and setting the ACL on the endpoint appropriately. This would eliminate the double hop, since the hop "from" the endpoint "to" the log service would carry a hardcoded token.June 27, 2016 at 8:50 pm #44998
It's also possible it's a protocol problem. RPC/DCOM might be blocked.June 29, 2016 at 1:49 am #45200
I'm not sure if it is a double hop problem since I am also getting the error while running the cmdlets locally against my machine. Furthermore, I can successfully run the cmdlets with an elevated account within the custom endpoint AND outside of it.
Since WinRm runs under the Network Service account I've also tried adding it via the wevtutil command with no luck:
wevtutil sl security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)June 30, 2016 at 12:22 am #45309
This is purely a permissions problem then. If you can't run it locally, you need to fix that first. Unfortunately that's really outside powershell – without access to your environment I'm not going to be of any help troubleshooting it :(. Sorry.
You must be logged in to reply to this topic.