Collecting Syslog to OMS Log Analytics using NXLog for Windows

Currently Microsoft provides no way to ingest Syslog messages from network equipment and other devices into OMS Log Analytics in a Windows-only environment. The Linux OMS agent can act as a Syslog collector, but there is no equivalent feature in the Windows agent. I’ve heard rumblings that a windows syslog collector is in the works but in the meantime we need a solution allowing Log Analytics to be our one-stop logging platform.

Enter NXLog Community Edition, an open-source syslog collector and processor. We can use this very light-weight service to act as a syslog collector and then write incoming logs to a file which can be picked up by the OMS monitoring agent.

Setup NXLog

You’ll need a windows server with the OMS monitoring agent installed to act as your syslog collector.

Download and install NXLog CE from here:

https://nxlog.co/products/nxlog-community-edition

Once installed, you can reference this sample config file to setup Syslog ingestion and write-out to log files. With this config, NXLog will create a separate .log file for each logging device, and rotate the files after they reach 10Mb, keeping 5 logs per host.


## This is a sample NXLog configuration file
## This configuration can be used to collect syslog messages from any RFC 5426 capable device
## and write those logs to a file which can be picked up by the Log Analytics agent
## Thanks to jorritfolmer for initial inspiration here: https://gist.github.com/jorritfolmer/bc6374b48bde2ba99f983cc0889da8a9
##
define ROOT C:\Program Files (x86)\nxlog
Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log
<Extension syslog>
Module xm_syslog
</Extension>
<Extension fileop>
Module xm_fileop
</Extension>
################################################
## Inputs
################################################
## Injest syslog over UDP port 514 from any host in IETF format
<Input syslog_in>
Module im_udp
Host 0.0.0.0
Port 514
Exec parse_syslog_ietf();
</Input>
###############################################
## Use this processor to filter out syslog based on severity
## Remember to add the processor to the Route
#<Processor syslog-severity-limit>
# Module pm_filter
# Condition $SeverityLevel > 5
#</Processor>
################################################
################################################
## Outputs
################################################
## Output syslog to file for pickup by OMS agent
<Output syslog_out_file>
Module om_file
File "C:/nxlog/syslog/" + $MessageSourceAddress + ".log"
CreateDir TRUE
Exec if (syslog_out_file->file_size() > 10M ) file_cycle("C:/nxlog/syslog/" + $MessageSourceAddress + ".log",5);
Exec syslog_out_file->reopen();
</Output>
<Route to_LogAnalytics>
Path syslog_in => syslog_out_file
</Route>

view raw

NXLog_to_OMS

hosted with ❤ by GitHub

Once your configuration file is set, restart the NXLog service. If successful you should now be able to point a syslog device to your NXLog server and see log files being written out right away.

Add a Custom Log type to Log Analytics

Now that incoming syslog is being written to a file, we can use the OMS monitoring agent already installed to collect the files and ingest them into Log Analytics. To do this, create a new Custom Log type in Log Analytics.

Open the OMS Log Analytics portal and go to:

Settings > Data > Custom Logs

1 Settings_Custom-Logs

Click Add + to create a new custom log type.

Upload one of the log files you are now generating as a sample to help Log Analytics learn to properly parse the files.

2 Upoad_sample_log

Make sure the records are delimited properly by Log Analytics, the New Line method should work well here.

3 Sample Uploaded

Configure the directory the Monitoring Agent should scan for log files. Keep in mind, this directory will be processed for all windows servers.

4 Collection directory

Name your new custom log type:

5 Name custom log type

 

After a short while, the OMS agent will begin picking up the log files and you can find your fresh syslogs in Log Analytics. From here you could create custom fields to pull out specific values, create alerts, or just leave as is.

6 Log Search

Protecting RD Gateway with the Azure MFA NPS Extension

Keep in mind the Azure MFA NPS extension is currently in public preview.

In February 2017, Microsoft released an Azure MFA extension for their Network Policy Server (NPS), Microsoft’s RADIUS server. This new plugin is designed to allow us to easily apply multi-factor authentication requirements to any RADIUS compatible service such as VPN or RD Gateway without the need for an on-premises Azure MFA Server. The NPS extension integrates directly with Azure MFA in the cloud.

In this post I will show you how to use the new Azure MFA NPS extension to protect Remote Desktop Gateway deployments.

Requirements

  • You will need an RD Gateway server and a separate NPS server. You cannot install the Azure MFA extension on your RD Gateway server.
  • Azure MFA licensing must be enabled on your tenant. Do not attempt to proceed with these instructions before subscribing to a license including Azure MFA (Azure AD Premium, EMS, or MFA subscription). If you do, the NPS configuration script will failed with an error such as:Service principal was not found”.
  • Your test user must have an applicable license assigned, and have a device enrolled in Azure MFA.

Setup a central NPS server

If you do not already have a central NPS server (not the RD gateway server) build a new server and install the NPS role via Roles and Features. Keep in mind, once the Azure MFA NPS plugin is installed, ALL NPS authentications on this server will require MFA. You will need a separate NPS server if you have applications which should not prompt for MFA.

Once the NPS role is installed you will need to create a Connection Request Policy and a Network Policy to control authentication for RD Gateway requests. You can model these after the existing policies on your RD Gateway server. Here is what I used:

NPS - connection request policy

NPS - Network Policy

Now add your RD Gateway server(s) under RADIUS clients on your central NPS server, set a Shared secret and save it for later.

NPS - RADIUS Client

Now stop here, and move onto configuring the RD Gateway server.

 

Configure the RD Gateway server

On your RD Gateway server, open the RD Gateway Manager and edit the server properties. On the RD CAP Store tab, select Central server running NPS and add your central NPS server IP address and shared secret.

RD Gateway - Central NPS

Still on the RD Gateway server, open the Network Policy Server console and find your central NPS server in the TS Gateway Server Group. Edit the server and adjust the authentication timeouts to allow enough time for MFA processing.

RDG NPS - TS Gateway Group

RDG NPS - Timeouts

 

Validate your central NPS setup

At this point you can test if your central NPS server is properly handling authentication requests from your RD Gateway server. Try launching an RDP session through your gateway. This should work as before, only now the authentication is happening on your central NPS server.

Setup the Azure MFA NPS plugin

If the above test was successful, you are now ready to add in MFA. Back on your central NPS server, install the Azure MFA plugin and prerequisites

Install Prerequisites:

The following is required:

Install the NPS Plugin:

https://www.microsoft.com/en-us/download/details.aspx?id=54688

Pay attention to the install instructions on that page, especially if you have an older version of powershell installed.

Configure the plugin

Once the plugin is installed, it must be configured. Microsoft supplies a powershell script for this. Open Powershell as an Administrator and run the following script:

C:\Program Files\Microsoft\AzureMfa\Config\AzureMfaNpsExtnConfigSetup.ps1

The script will ask for your Azure Active Directory Tenant ID. You can find this in the Azure Portal, under Azure Active Directory > Properties > Directory ID

Azure Portal - Tenant ID

Once the script completes you should now be prompted for MFA on your next RD Gateway login.

 

Reference

https://blogs.technet.microsoft.com/enterprisemobility/2017/02/06/azure-ad-news-azure-mfa-cloud-based-protection-for-on-premises-vpns-is-now-in-public-preview

https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-nps-extension