EnterpriseAdmins.org

I have created several vRealize Operations (vROps) alerts in the past, mainly using the Log File Plugin and Standard Email Plugin. However, I recently had someone ask for more information on using the Rest Notification Plugin. I hadn’t used this, so I started looking for more detail on how to get started.

I found a couple really good blog posts on this, specifically https://blogs.vmware.com/management/2017/01/vrealize-webhooks-infinite-integrations.html and https://blogs.vmware.com/management/2018/02/extending-vrealize-operations-collaboration-tools-restful-apis-webhook-shims-david-davis-vrealize-operations-post-50.html . Both of these posts describe using an intermediary to accept what vROps is sending and convert it into a format that another endpoint expects. There are a handful of integrations provided, so I started looking at one that I could test with. The following post will describe the steps to get this working.

The Test Service
For testing, I’m going to use vROps to send an alert to Slack. This was pretty straight forward, I created a new channel where I wanted the alerts to appear, and then created a new incoming webhook by visiting https://api.slack.com/apps/new. I created a new app called vrealize-bot using my workspace. Once the app was created, I toggled on the ‘incoming webhooks’ feature, and mapped to my channel. This resulted in a webhook URL that looked like this:

https://hooks.slack.com/services/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

To confirm this was working, I used a quick PowerShell script to try and post to that webhook URL. This isn’t needed, but did prove that my web hook was correctly created.

Invoke-WebRequest `
   -Uri $webhookURL `
   -Method POST `
   -Headers @{"Content-type"="application/json"} `
   -Body (@{"text"="This is a test"}|ConvertTo-Json)

The ‘Shim’
We need a piece of code to covert from the vROps Rest output into a format Slack will accept. The first blog post mentioned above calls out a prebuilt tool to do this — called the loginsightwebhookdemo. There are instructions available on getting this running, but the easiest route for me was to use the docker image. I started by downloading the Photon OS 3.0 OVA, deployed it to an ESXi host, and then enabled docker using these instructions. I ran three commands… only the middle one is required, the other two will just show some supplemental info.

systemctl status docker
systemctl start docker
docker in

Once docker is running, you can start the webhook-shims container using these instructions. As described in the instructions, you launch the bash shell, which gives you the ability to edit files in the container file system to add things like our Slack API URL. If you choose this route, once the files are edited in the loginsightwebhookdemo directory, you’ll need to run ./runserver.py from the webhook-shims directory. However, since we are only using the Slack shim in this example, there is an easier way. All we need to do is pull & run the container using these commands:

docker pull vmware/webhook-shims
docker run -it -p 5001:5001 vmware/webhook-shims

With the container running we can access its info page at http://dockerhostnameorip:5001/. This will show everything is up and running and that you can connect to the website.

The vROps Alerts
From the Alerts > Alert Settings > Notification Settings area, we can add a new rule. We will select the Rest Notification Plugin method and add a new instance. We’ll name our instance SlackWebhook_vrealize-bot. We could enter anything we want here, but want to be descriptive as possible. This shows the service we are using, how we are connecting, and the application that will be doing the posting, which seems sufficient. The URL is where the magic happens. We’ll enter a URL like this:

http://dockerhostnameorip:5001/endpoint/slack/TTTTTTTTT/BBBBBBBBB/alphaNumericStr0ngOfText

This is the name of the host our container is on, the port that the service is exposed on, the endpoint/slack is to specifies which shim we want to use, and the TTTTTTTTT/BBBBBBBBB/alphaNumericStr0ngOfText comes from our Slack webhook at the beginning of the article. We will leave the username and password blank (all that authentication is done in our custom webhook URL). For content type we’ll select application/json. Pressing TEST should result in two new posts to our Slack channel.

Now all we need to finish up is to define the filtering criteria for which alerts we want to be sent to Slack. For testing, I just set criticality to Immediate or Critical, but we will likely want to narrow that down over time as it is a bit too chatty.

I recently read an interesting article on the vSphere Blog: https://blogs.vmware.com/vsphere/2020/01/microsoft-ldap-vsphere-channel-binding-signing-adv190023.html, which states Microsoft is making a change to the default behavior of LDAP servers that are part of Active Directory. This change will require secure LDAP channel binding by default, and is scheduled to be implemented in March 2020. The article goes on to say that vCenter using Integrated Windows Authentication (IWA) is not affected, so my lab should be fine…right? I have systems other than vCenter connecting over LDAP, so I have a need to double check. I found a really good article from 2016 ( https://docs.microsoft.com/en-us/archive/blogs/russellt/identifying-clear-text-ldap-binds-to-your-dcs) that shows how to increase logging levels and also includes an event viewer view and PowerShell script to find these events. However, I wanted to make this same data visible as a dashboard in Log Insight. The following post will recap the required steps to build a similar dashboard for your environment.

The first step was to enable the additional logging. I did this by adding the following registry key to all domain controllers in the environment. I did this in a lab with very few domain controllers, so I just ran this command on each, one at a time:

# Enable Simple LDAP Bind Logging
reg add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2 

My domain controllers were already running the Log Insight agent and the Active Directory content pack was already installed and configured. You can check this in your environment by going to Settings > Content Packs. If you do not see Microsoft-Active Directory listed under the Installed Content Packs header, you can get it from the Marketplace. When you install the content pack from Marketplace, it will display a set of instructions you need to follow to enable appropriate collection. If you have already installed the content pack, you can find these setup instructions by browsing to the content pack, clicking the ‘gear’ icon and selecting ‘setup instructions’ (screenshot below):

For example, you may need to enable additional audit logs in your Default Domain Controllers policy – the details are included in the popup. You will also need to create a copy of the agent configuration from Settings > Administration > Agents (among other settings, this will ensure the Directory Services log is captured — and that is where event 2889 is logged). Here is a sample of the agent configuration, showing that our newly created configuration applies to both of my lab domain controllers.

Now that Windows is logging eventid 2889, and Log Insight agent is picking that event up, we can focus on extracted fields and dashboards in Log Insight.

Extracted Fields
An extracted field is a regular expression definition of text we want to find in our event. If we look at a sample of one such event (screenshot below) we can see that there three fields that we likely want to capture:
– Client IP Address
– Identity the client attempted to authenticate as
– Binding Type

The easiest way to extract this event is to highlight the text we want to extract. A popup will appear and give us filtering choices as well as an option to extract a field. If we select that option, a new field definition will appear to the right of the page.

We can see that the default criteria is looking for an IPv4 address that appears after the text address: and before the text :38130. This is close to the text we want, but the pre-text is not as specific as we could be and the post text is too specific (the source port can be any random high numbered port). We can edit this default criteria
– Pre text: Client IP address:\s* [adding the Client IP prefix as shown in the example event]
– Post text: : [removing the ending port number, leaving only the single colon ]
We will also give this field a name (Ldap2889_ClientIP) and make it visible to all users. The resulting field definition should look like this:

Now that we know how to extract the data we want, we will repeat the process to create other extracted fields for Ldap2889_Identity and Ldap2889_BindingType.

Dashboard
Once we have extracted interesting fields, we can build visuals to consume that information. The easiest way to do this is from Interactive Analytics. We start by applying filters — in this example we add a filter for eventid = 2889. We can then add interesting groups of data. In the top section of interactive analytics we can see a timeline of findings. In the bottom left area we see a couple of drop downs. The first one starts ‘Count of events,’ which is typically the most logical grouping. There are other choices available so you should review those options. The second drop down list defaults to ‘over time,’ and this one is the one that is typically adjusted. For example, we can select ‘Non-time series’ and then Group By one of our custom extracted fields — for example, Ldap2889_ClientIP.

Using the options to the right, we could easily turn this visual from a column to a pie graph. Once we have it the way we like, we can use the ‘Add to Dashboard’ button in the top right to save this view for later. The popup will ask us for a visual name, and then to select the dashboard where we’d like to see this data. We can make a new dashboard from this same screen if needed, and even share with all other users. We can create other visuals, for example, groupings by Ldap2889_Identity or BindingType, or even include some time series metrics to see when most of the logins are occurring. Looking at my dashboard, I can see that I may have a bit more work ahead of that March 2020 deadline.