Get-WinEvent: Reading Security logs

This topic contains 6 replies, has 2 voices, and was last updated by Profile photo of Don Jones Don Jones 3 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #44980
    Profile photo of Alfano Greg
    Alfano Greg
    Participant

    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

    or

    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?

    #44987
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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?

    #44993
    Profile photo of Alfano Greg
    Alfano Greg
    Participant

    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).

    #44996
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

    #44998
    Profile photo of Don Jones
    Don Jones
    Keymaster

    It's also possible it's a protocol problem. RPC/DCOM might be blocked.

    #45200
    Profile photo of Alfano Greg
    Alfano Greg
    Participant

    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)
    #45309
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.