Azure Sentinel Insecure Protocols Workbook Implementation Guide

Published Feb 26 2020 07:24 PM 16.4K Views

This blog post is authored by Jon Shectman and Brian Delaney.


In this blog article, we’ll examine the Insecure Protocols Workbook (IP Workbook) and how, with minimal on-premise configuration, you can leverage its capabilities. In this article, I’ll provide the configuration instructions you need to successfully use the IP Workbook.


If you’re not familiar with the IP Workbook, that’s ok. However, for the purposes of this blog entry, I’m going to presume a general familiarity with Azure Sentinel and with Workbooks.


Edit: when you're done here, pop over to the blog entry covering some recent functionality enhancements.


Stage 0/Background: the Sentinel IP Workbook

The Azure Sentinel IP Workbook 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 sources of legacy protocol traffic, like NTLM and SMBv1. You will also have the ability to monitor use of weak ciphers as well as legacy authentication to Azure AD (like IMAP and POP). These protocols comprise a rich attack surface for adversaries and should be removed from your estate.


The IP workbook consist of detections for the following insecure protocols:




Unsigned LDAP Binds

Weak ciphers being used in the Kerberos stack

Legacy authentication against Azure AD


Important Note: If you do not have sources of every kind of log present, or if you elect not to audit every one, that is perfectly fine. The workbook will simply not display that data; all other protocol collections remain unaffected. For example, if you are not using or collecting Azure AD Sign-in logs, you would still be able to view on-premise logs for protocols like NTLM and SMB.


Let’s take a brief look at the IP Workbook.




In the screenshot above, the estate has 258 Insecure LDAP connections logged in the last seven-day period; note the TimeRange filter is configurable. Right away, it becomes apparent that the most significant protocol in this particular estate is Insecure LDAP. Drilling down further, I can click on any one of the bars to filter to just that timeframe.




With this simple filter, a story emerges – On Feb 20, there were four insecure LDAP binds during the 4am hour. This particular filter is important for establishing patterns across the estate, as well as tracking remediation progress over time. To identify sources of the traffic, I would scroll down to the Insecure LDAP section of the workbook.


This is one example among many in the IP Workbook. For now, let’s turn our attention to how you can get data flowing into the IP Workbook and start mitigating your estate’s insecure protocols.


Stage 1: Enable AD Auditing (On-prem/IaaS)

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 insecure LDAP binds occur, on each Domain Controller.



Note: 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.


Stage 3: Enable SMB1 Auditing

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

  • 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 Security Events Data Connector Settings

In Azure Sentinel, navigate to Data Connectors and then choose the Security Events connector and click Open connector page.




On the blade that opens, scroll down to the Configuration section and 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:



Also, note that the Security Events Data connector requires the MMA agent to be installed on your in-scope servers. You may download it under Configuration.



Stage 5: Configure the Directory Services log in Log Analytics

In the Azure portal, navigate to the Log Analytics workspace. Click on Advanced settings. On the blade that opens up, choose Data and then Windows Event Logs.



In the box under Collect events from the following event logs, type Directory Service and click the Plus sign. When the log is added to the list, check INFORMATION. In the upper-left-hand corner, click Save.



Stage 6: Configure SMB Log Collection

In the same area, navigate back up to the Collect events from the following event logs box. This time you will type in Microsoft-Windows-SMBServer/Audit. Note: this particular log does not autofill in the pull-down. This is ok - type it and and hit the Plus sign.




Choose INFORMATION and hit Save.



Stage 7: Configure Azure AD Sign-in Logs Data Connector Settings

Navigate back out to the Data connectors blade in Azure Sentinel and choose Azure Active Directory and Open connector page.




On the blade that opens, navigate to Configuration and next to Azure Active Directory Sign-in logs, click  Connect.



Note: My data connector has already been connected and looks a bit different – as evinced by the Disconnect button. If you haven’t yet connected, this button will say Connect before you click it.


Stage 6: Implement the IP Workbook

On the main blade of Azure Sentinel, navigate to Workbooks and Insecure Protocols, and click Save. In the box that opens, choose an appropriate location and click OK.




You are now ready to begin using the IP Workbook by clicking View saved workbook.


In this article, we briefly discussed the use case for the IP Workbook and how you can leverage it to identify insecure protocols for removal. We then covered how to configure your estate to log and display the exact sources of insecure protocols, setting you up for the best chance of successful removal.


I hope you've found this article useful and that you'll let us know how you've used the IP Workbook. Until then, happy auditing.

Occasional Visitor

Nice work, gentlemen. It is critical for organizations to work toward eliminating these.  It is also important that organizations work to eliminate all authentication flows where an application handles user passwords directly including all LDAP authentication, WS-Trust, and the ROPC flow of OIDC.  Applications that handle passwords directly must be treated as tier 0, equivalent to AD domain controllers, etc.).  If you have more than a very small number of these applications, it often means that your tier 0 has expanded its footprint and attack surface resulting in too much risk exposure.  

Occasional Contributor

How can this "Insecure Protocols" dashboard can be recreated after accidental deletion?

My guess:

+ reversal of "Step 2 - Export the dashboard into a JSON file"


Hi Rafal

if you delete accidentally the workbook from MyWorkbook, you can restore it back from templates or copy from GitHub as Custom


Senior Member

About the Log Analytics workspace config.


Step 5 says that Directory Service needs only "Information" level logging. However in the Step 6 screenshot, it looks like Warning-level is also selected for Directory Service. Should we also select Warning events?


And does the mentioned Log Analytics "Collect events from the following event logs" config need nothing enabled for LDAP, NTLM, Kerberos... ?


Hi @Mikko_Koivunen thanks for your message and your sharp eyes.  :)  Yes, Step 5 is correct - only Informational is required. The Step 6 screenshot reflects a later configuration unrelated to Step 5. I'll fix that screenshot.


So long as you've followed the directions here, no other config is needed for the other events.

- Jon

Occasional Contributor

Hi community


With respect to the AAD legacy authentication section of this workbook is it reporting on successes and failures i.e. attempts or only successes?


Hi there - if it's in AAD Sign-in logs as a legacy Auth attempt, it will appear in this workbook.

Respected Contributor

I'm confused, the is showing some Legacy auth sign ins, but when i look at the sign-in report in AAD, there are not any . How can I investigate this discrepancy? @Jon_Shectman 



Hi Dean - I suspect what is happening is that there are blanks in AAD Sign-in logs for the type of Auth being used. That can happen since it's up to the App to report. When they don't, our thought is that it's safest to categorize them as Legacy (since most Apps using Modern Auth would also be likely to report).

New Contributor

Hello – great article and solution. May I ask a specific question on Stage 4: Configure Security Events Data Connector Settings and the requirement to stream ‘All Events’.


Currently we use ‘Common Events’ setting – namely as we have concerns on log ingestion volumes and onwards data retention costs within our Azure Sentinel deployment.

Therefore can I ask


  1. Is ‘All Events’ setting definitely a pre-req for this solution or would ‘Common Events’ setting suffice?
  2. If the answer to a) is ‘Yes’ can you advise on a way to mitigate the impact of this. I assume you would need another Sentinel Instance where this setting can be applied (and IP dashboard solution added) and only connect In-Scope Servers through MMA Agent Configuration?
  3. Can I ask to clarify my understanding around the definition of ‘In-Scope’ servers for the solution – I assume this needs to be Domain Controllers as a must but does the solution need Domain Member servers also for in-scope purposes?


HI Andy - 

1. Yes. The partial data set won't do it.

2. This is one of the most requested capabilities in my experience with customers. Log filtering at the MMA would let you choose which logs. I believe that this feature is slated for later this year.

3. Just Domain Controllers

- Thanks, Jon


Occasional Contributor

I'm busy with this and what I've done is set the MMA agent to report to two separate Log Analytics Workspaces and the second one has the Option set to "All Events". However I've only done this config on the Domain controllers and my identity infrastructure such as AADConnect servers and PTA agent boxes etc.


Right now that is you best option to reduce the ingestion volumes...

Occasional Contributor

Hi everyone..


I'm busy setting this workbook up and all appears to fine and dandy thus far... 


I do have one question driven by curiosity more than anything else. I was looking at the actual KQL query used to generate the detailed NTLM table and I will admit to being confused as to what this code chunk does: where '{\"WorkstationName\":\"All\"}' contains "All" or ('{\"WorkstationName\":\"All\"}' contains WorkstationName and '{\"WorkstationName\":\"All\"}' contains Computer) Not being an KQL expert at any level I'm just trying to figure what filtering this code actually does... 




HI @PeterJNGL - I am afraid I am not seeing that chunk of code in any of the NTLM queries. Can you share a larger snippet? Are you on an older version of the Workbook?

Occasional Contributor



Here's the complete query


| where EventID == 4624
| where AuthenticationPackageName == 'NTLM'
| where LmPackageName == 'NTLM V1'
| where Account !contains 'ANONYMOUS LOGON'
| where '{\"WorkstationName\":\"All\"}' contains "All" or ('{\"WorkstationName\":\"All\"}' contains WorkstationName and '{\"WorkstationName\":\"All\"}' contains Computer)
| summarize Count = count() by Account, WorkstationName, DC=Computer, LogonProcessName, TargetDomainName, TargetAccount, IpAddress
| sort by Count desc


And now for a really dumb question.. How do I go about verifying that I have the latest version of the workbook?

Version history
Last update:
‎Sep 22 2020 03:12 PM
Updated by: