best way to configure Windows devices for WinRM and add as event source

[JeremySamiec]

I would like to know the best way to configure windows servers and add them to NetWitness. The process I have right now (Windows Event Forwarding) has its own set of issues and would like something more native to NetWitness. However, manually running of scripts on a bunch of host servers (over 10K Windows servers) is not reliable and then having to create and import CSV's is another manual process.

is there anything more automated and enterprise friendly?

[MihaMesojedec]

Actually output from powershell print screen is when I ran script to add Windows event source via Rest API and connection was successful.

[JeremySamiec]

Hello Miha,

I was able to get the scripts run and the event sources added; however, when I use the API to add the machines I get the error stating the event source is not configured for https and to validate server.

Then if I delete the test machine from the event category and manually add it with no additional configuration, it works. Do you have any ideas what the issue could be?

Thanks.

[MihaMesojedec]

Are you configured WinRM on event source to use HTTP or HTTPS?

You need define right parameters in the script, so that they are passed to NetWitness.

Parameters in the script are actually same as you would manually configure event source via GUI.

So if you check on example how it's configured, then you can set this in the script and everything should work.

This are parameters below you need to change in the script in order to work properly in your environment. Check comment with possible option in the script.

For example if you are using WinRM over HTTP then transport mode is http, otherwise if you use WinRM over HTTPS is https. When you use WinRM https method you need to define certificate as well.

$LogCollectorIP = '192.168.16.11'
$LogCollectorPort = '50101'
$NWEventCategory = 'ASOC'
$WinRMPort = '5896'
$TransportMode = 'https'
$WindowsType = 'Non-Domain%20Controller'
$RenderLocale = 'en-US'
$ResolveSids = 'true'
$ValidateServer = 'true'
<# $CertName = 'XXXXXX'

<# Define Rest API User and passowrd #>
$RestAPIUser = 'admin'
$Password = 'netwitness'

As said check event source you have in NW and is working and then modify parameters in the script accordingly.

[JeremySamiec]

Hello,

Yes, I passed the parameters that are relevant to our environment.

I have the event sources configured for HTTPS and they do work when I manually create in the NW GUI. The machine does have the required cert from our CA. See previous images for creation via API (created but connection fails) vs. manual (connection succeeds), both from same event category.

This is a weird problem, if available maybe a WebEx would help?

[JeremySamiec]

Upon looking closer, I found the issue.

The variable for $WinRMPort = '5986' had a transposed value of $WinRMPort = '5896'

This script works like a charm.

Thank you very much for the help!

[MihaMesojedec]

I'm glad you fix your issue and successfully add event source with script. 

[JeremySamiec]

With your great help! I could not figure this out and had resorted to Windows event collection which is a valid option, but not optimal. This appears to be a fully automated process and leverages NW policy tooling so we can receive alerts when/if a critical asset stops logging.

I am very grateful for your help! This is awesome.

[KEVINDIENST]

FYI - I read through this convo and I'd like to add something to this discussion regarding Windows event collection. I saw you mentioned WEF in your initial question and this method uses WinRM, however WinRM has its own challenges I'd like to highlight in case others stumble across this thread. 

WinRM requires several dependencies as you've already mentioned such as:

1. WinRM configuration and service running on the server (can be configured via GPO)
2. Firewall rules to allow the collectors to reach all your Windows servers via 5985/5986
3. Service Account to authenticate remotely with the log source
4. Kerberos infrastructure (DNS, NTP, Kerberos config) to authenticate to the remote server successfully or you'll see 401 unauthorized errors in the WinRM logs on the remote system. (also shows up on the logs on the collector). 

One scenario where this will be a problem for some large enterprises is if you have network segments that also have segmented authentication silos. As WinRM must be able to authenticate to the remote system, if you segment a network tier (i.e. collector in Tier 3 and server in Tier 2) you won't be able to collect events from the Tier 3 collector. Instead you need a collector in each segment. This doesn't even get into the issue of trying to auto-enroll all Windows servers with local server certs for use in WinRM and properly expiring those certificates and renewing them in a timely and effective way to reduce log collection outage. 

We're investigating if using WEF and Subscription servers may be a more suitable architecture for massive Windows log collection. 

Jeremy - Would you be open to a private message so I can ask a few questions about your issues with WEF?

[JeremySamiec]

Yes, that is ok. Sorry for the delay. I was supposed to receive email updates on this but apparently did not get this one.

I can say WEF add its own complexities too, in that when it forwards logs busier log aggregating servers will cause the collector throw errors. I don't like that since all our servers are busy. 

As you have pointed out, we have have over 12k Windows servers and in segmented networks (in one domain,  we have many more too) and yes this can cause some headaches. For this we've utilized VLC's in the "remote" networks and carve out the FW rules to allow the traffic. We have not had issues with CA delays like you mention, but i am sure it is a possibility.

If it were me, i would stand up WEF as an interim solution until you can get the technical barriers out of the way. This is not a optimal long term solution, but works to get a great deal of logs in the SIEM fast. I will admit, it took some time to hammer out, but how we have it now is way better. 

I took the scripts provided above, made them functions and created another function to enroll in the CA. The script runs as a scheduled task with some if conditions. via GPO, this works awesome.