Azure Sentinel Insecure Protocols Dashboard Implementation Guide


Azure Sentinel Insecure Protocols (IP) Dashboard Implementation Guide

Stage 0/Background: the Sentinel IP Dashbord

This guide will help you setup the Azure Sentiel IP Dashboard. The Azure Sentinel IP Dashboard allows you to gain insights into Insecure protocol traffic by collecting and analyzing security events from Microsoft products. You can view analytics and quickly identify use of weak authentication as well as sources of legacy protocol traffic, like NTLM and SMBv1. You will also have the ability to monitor use of weak ciphers, allowing you to find weak spots in your organization's security.

The IP dashboard consist of detections for the following insecure protocols and procedures:

  • NTLMv1
  • SMB1
  • wDigest
  • Unsigned LDAP Binds
  • Weak ciphers being used in the Keroberos stack

Let's have a quick look at the dashboard, and what each section helps you to accomplish. For a more thorough discussion of detecting insecure protocols, please navigate to the Project VAST blog. Project VAST forms the basis of the IP dashboard in Azure Sentinel; though the screen shots and some of the specifics are different, the same basic detective techniques are shared between the two solutions.

At the top of the IP dashboard page, you'll see the Insecure Protocols overview frames.

These visualizers provide you with a bird's eye view of the insecure protocol situation in your monitored estate. In the example above, I have around 1,400 logs showing Insecure LDAP, 1,200 showing SMB1, 504 with wDigest, and 244 showing NTLMv1. What's more, I can learn more about the situation by clicking to drill into the graph. For example, in my lab I see that Insecure LDAP and SMB1 comprise 77.3% of the insecure protocol binds that are taking place. All other things being equal, this suggests I should start the removal process of those two protocols.

Once we've decided where to focus our resources, we can drill into specific protocols or ciphers. For example, looking at the Insecure LDAP frames, I can see that 5.2% of the Insecure LDAP binds are coming from one IP address, while 94.8% are coming from a different IP address. All things being equal, it's clear where to start. 

Looking to the frame at the right, I can then focus on the Insecure LDAP traffic coming from IP address -67 by account.

Out of the Insecure LDAP traffic coming to -67, I see that an account called svc1 is responsible for a high number of binds. Therefore, the narrative becomes clearer -- I need to remediate Insecure LDAP traffic coming from account svc1 on IP -67 as my first step. I now have the beginnings of an action plan. And I can also demonstrate tangible progress to decision-makers over time.

Stage 1: Enable AD Auditing

The first step to setting up the Insecure Protocols dashboard is to ensure you are auditing the correct events in your Domain Controller Security logs. We’ll configure auditing for these events through Group Policy and verify them.

Note: This guide assumes that you are using Advanced Audit Configuration policies, as these policies are newer and offer more precision (and less over-collection) through granular subcategories. You may achieve the required level of auditing using only older auditing policies, but that auditing is much less granular.

  • To verify that you have enabled Advanced Audit Policy Configuration, navigate to this value in the winning GPO for your Domain Controllers:

Computer Configuration\Policies\Security Settings\Local Policies\Security Options\

Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings

This setting should be set to Enabled.

Next, you’ll need to set (or ensure that you have set) the following Advanced Audit Policies to log some specific events. These settings must apply to all servers you want to audit (DCs). You may add them to an existing DC GPO or create a new one.

Navigate to

Computer Configuration\Policies\Security Settings\Advanced Audit Policy Configuration:

  • Under Account Logon, set the following audit settings to Success, Failure
    • Audit Credential Validation
    • Audit Kerberos Authentication Service
    • Audit Kerberos Service Ticket Operations
  • Under Account Management set the following audit settings to Success, Failure
    • Audit Security Group Management
  • Under Logon/Logoff set the following settings to Success, Failure
    • Audit Logon
    • Account Lockout
    • Audit Other Logon/Logoff Events

The settings should look like this:

Once you have set the GPO settings and performed a GPO update, you can verify the settings using auditpol:

  • On a DC, launch an elevated CMD prompt and type
    auditpol /get /category:*
  • The output for other items will vary, depending on what else is being audited.
    Ensure the following settings appear as expected:

Note: Settings for other items will vary, depending on the existing configuration.

These audit settings will produce the following discrete Event IDs in the Security Log of the Domain Controllers in scope:

  • 4776 - Non-Kerberos Authentication
  • 4771 - Kerberos Pre-auth Failure
  • 4740 – Account Lockout
  • 4624 - Successful Logon
  • 4625 - Failed Logon
  • 4768 - TGT request
  • 4769 - TGS request
  • 4627 – Group membership change

Stage 2: Enable Logging of Unsigned LDAP Binds

An important step to setting up the Insecure Protocols dashboard is to ensure you are auditing insecure LDAP traffic in your Domain Controller (or ADLDS) Directory Service Log.

We’ll set these events and verify them through Group Policy (GPO). Specifically, we’re going to log EventID 2889: The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing.

  • We’ll need to enable LDAP Logging on each DC. This is a registry setting.

From an elevated CMD prompt, this can be performed simply with:

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
/v "16 LDAP Interface Events" /t REG_DWORD /d 2

Note: The above is a single command, line-wrapped for readability

As shown in Regedit below:

  • Environments with many DCs should utilize Group Policy Preferences to set this value through a linked Group Policy.

In the policy object, open Computer Configuration, Preferences, Windows Settings, and click Registry.

Right-click Registry and choose New -> Registry Item

Set the properties as shown.

Action:                                           Replace

Hive:                                              HKEY_LOCAL_MACHINE

Key Path to:

Value Name to:                 16 LDAP Interface Events

Value type:                                    REG_DWORD

Set the Value data to:       2

Ensure to check the box on the Common tab for "Remove this item when it is no longer applied."

Close the GPO and run GPUPDATE on one DC to verify application.

  • Once you set this registry key, you should start receiving Event ID 2889 in your Directory Service log whenever un-secured LDAP binds occur, on each Domain Controller.

  • Depending on the volume of unsigned LDAP data in your environment, you may need to increase the size of your Directory Service event log on your DCs to ensure all events are captured.

NOTE: As this feature requires more resources, it is recommended to pay additional attention to the resource utilization on the Domain controllers

  • To do this, open Event Viewer, right click the Directory Service log, and choose Properties. You may adjust the maximum log size there.

NOTE: the value shown below is for illustration only, not a suggested size

  • Alternatively, a size can be set for many DCs using Group Policy Preferences, using the same technique as above, using the following registry path:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\Directory Service

Value Name: MaxSize
Value Type: REG_DWORD

Value data: use the following as a guide:

10000000 (Hex) -> 256MB
08000000 (Hex) -> 128MB
00800000 (Hex) -> 8MB

Stage 3: Enable SMB1 Auditing

Note: this setting is only available on Windows Server 2012 R2 and 2016

  • On each target server, run the following PowerShell command:

set-SmbServerConfiguration –AuditSmb1Access $true

To use PS Remoting to run this against multiple servers:

$computers = Get-Content "c:\SMBservers.txt"

foreach ($computer in $computers) { Invoke-Command -ComputerName $computer -ScriptBlock {set-smbserverconfiguration -auditsmb1Access $true -Force } }

Where C:\SMBservers.txt is an export of all server names that you wish to target.

Stage 4: Configure Data Settings in Azure Sentinel

Launch the Azure Portal (https://portal.azure.com) and sign in.

Click Log Analytics and then click the name of the Log Analytics implementation you’re using.

  • If a log analytics management solution is not already added:
    • Select Add

  • In Log Analytics workspace blade, choose Create New and the other appropriate information.

Next, we'll enable the importing of to All Events. This is necessary to ensure we capture the necessary log files in Sentinel.

Click Data connectors. On the Data connectors blade, click CONFIGURE in the Security Events data connector.

On the blade that opens, choose All Events.

Note: if the choices are greyed out (as mine are in this example), pay special attention to the alert on this page:

Stage 5: Install the Insecure Protocols Dashboard

You are now ready to install and view the Insecure Protocols dashboard in Azure Sentinel. In Azure Sentinel, click Dashboards, choose the Insecure Protocols dashboard and click Install. If you have already installed the dashboard (as I have in the screenshot below), you'll click View dashboard instead of Install.

For Azure Sentinel pricing information, please go here.

One final caveat. This guide assumes you have the MMA installed on your source computers or on your WEF forwarder box. You will need either of these setups complete in order to upload the necessary log files to Azure Sentinel.

Skip to main content