Recent Blogs
As a Senior Product Manager | Developer Architect on the App Assure team working to bring Microsoft Sentinel and Security Copilot solutions to market, I interact with many ISVs building agents on Mic...
Apr 02, 2026
What's new in Defender for Cloud?
Kubernetes gated deployment is now generally available for AKS automatic clusters. Use help to deploy the Defender for Containers sensor to use this feature. Mor...
Apr 02, 2026
2 MIN READ
A new standards-based option for identity teams to manage user and group lifecycle in Microsoft Entra.
Apr 02, 2026
Why Agent Security Alone Is Not Enough?
Foundry‑level controls are designed to prevent unsafe behavior and bound autonomy at runtime. But even the strongest preventive controls cannot answer key go...
Apr 02, 2026Recent Discussions
Purview EXPORTS unreliable and missing "Top-of-information-store" folder
Has anyone noticed an issue where the exported PST files are either empty or missing folders? I don't normally check every PST file that I export, but after hearing from customers that there are either no emails or missing folders, I started to check after each export. I am noticing that the Seach and Export process seems to be fine and the Downloaded PST file show the correct size, but when i open the PST files, I'm seeing that they contain no emails OR they are missing folders - including the "Top-of-information-store" folder. When i look at the Properties > Folder Size settings, i can see that the PST file thinks that all the folders are there. This is incredibly tough to work with since I am now checking each PST file and then having to rerun the search/export/download all over again. It's been like this for about 3 weeks.
Do XDR Alerts cover the same alerts available in Alert Policies?
The alerts in question are the 'User requested to release a quarantined message', 'User clicked a malicious link', etc. About 8 of these we send to 'email address removed for privacy reasons'. That administrator account has an EOM license, so Outlook rules can be set. We set rules to forward those 8 alerts to our 'email address removed for privacy reasons' address. This is, very specifically, so the alert passes through the @tenant.com address, and our ticketing endpoint knows what tenant sent it. But this ISN'T ideal because it requires an EOP license (or similar - this actually hasn't been an issue until now just because of our customer environments). I've looked at the following alternatives: - Setting email address removed for privacy reasons as the recipient directly on the Alert Policies in question. This results in the mail going directly from microsoft to our Ticketing Portal - so it ends up sorted into Microsoft tickets. and the right team doesn't get it. SMTP Forwarding via either Exchange AC User controls or Mail Flow Rules. But these aren't traditional forwarding, and they have the same issue as above. Making administrator @tenant.com a SHARED mailbox that we can also login to (for administration purposes). But this doesn't allow you to set Outlook rules (or even login to Outlook). I've checked out the newer alerts under Defender's Settings panel - XDR alerts, I think they're called. Wondering if these can be leveraged at all for this? Essentially, trying to get these Alerts to come to our external ticketing address, from the tenants domain (instead of Microsoft). I could probably update Autotask's rules to check for a header, and set that header via Mail Flow rules, but.. just hoping I don't have to do that for everyone.Impersonation Protection: Users to Protect should also be Trusted Senders
Hey all, sort of a weird question here. Teaching my staff about Impersonation Protection, and it's kind of occurred to me that any external sender added to 'Senders to Protect' sort of implicitly should also be a 'Trusted Sender'. Example - we're an MSP, and we want our Help Desk (email address removed for privacy reasons) to be protected from impersonation. Specifically, we want to protect the 'Help Desk' name. So we add email address removed for privacy reasons to Senders to protect. However, we ALSO want to make sure our emails come thru. So we've ALSO had to add email address removed for privacy reasons to Trusted Senders on other tenants. Chats with Copilot have sort of given me an understanding that this is essentially a 'which is more usefuI' scenario. But CoPilot makes things up, and I want some human input. In theory, ANYONE we add to 'trusted senders' we ALSO want protected from Impersonation. Anyone we protect from Impersonation we ALSO want to trust. Copilot says you SHOULDN'T do both. Which is better / more practical?
Dedicated cluster for Sentinels in different tenants
Hello I see that there is a possibility to use a dedicated cluster for a workspace in the same Azure region. What about workspaces that reside in different tenants but are in the same Azure region? Is that possible? We are utilizing multiple tenants, and we want to keep this operational model. However, there is a central SOC, and we wonder if there is a possibility to utilize a dedicated cluster for cost optimization.Governing Entra‑Registered AI Apps with Microsoft Purview
As the enterprise adoption of AI agents and intelligent applications continues to accelerate, organizations are rapidly moving beyond simple productivity tools toward autonomous, Entra‑registered AI workloads that can access, reason over, and act on enterprise data. While these capabilities unlock significant business value, they also introduce new governance, security, and compliance risks—particularly around data oversharing, identity trust boundaries, and auditability. In this context, it becomes imperative to govern AI interactions at the data layer, not just the identity layer. This is where Microsoft Purview, working alongside Microsoft Entra ID, provides a critical foundation for securing AI adoption—ensuring that AI agents can operate safely, compliantly, and transparently without undermining existing data protection controls. Lets look at the role of each solution Entra ID vs Microsoft Purview A very common misconception is that Purview “manages AI apps.” In reality, Purview and Entra serve distinct but complementary roles: Microsoft Entra ID Registers the AI app Controls authentication and authorization Enforces Conditional Access and identity governance Microsoft Purview Governs data interactions once access is granted Applies classification, sensitivity labels, DLP, auditing, and compliance controls Monitors and mitigates oversharing risks in AI prompts and responses Microsoft formally documents this split in its guidance for Entra‑registered AI apps, where Purview operates as the data governance and compliance layer on top of Entra‑secured identities. Lets look at how purview governs the Entra registered AI apps. Below is the high level reference architecture which can be extended to low level details 1. Visibility and inventory of AI usage Once an AI app is registered in Entra ID and integrated with Microsoft Purview APIs or SDK, Purview can surface AI interaction telemetry through Data Security Posture Management (DSPM). DSPM for AI provides: Visibility into which AI apps are being used Which users are invoking them What data locations and labels are touched during interactions Early indicators of oversharing risk This observability layer becomes increasingly important as organizations adopt Copilot extensions, custom agents and third‑party AI apps. 2. Classification and sensitivity awareness Purview does not rely on the AI app to “understand” sensitivity. Instead the Data remains classified and labeled at rest. AI interactions inherit that metadata at runtime Prompts and responses are evaluated against existing sensitivity labels If an AI app accesses content labeled Confidential or Highly Confidential, that classification travels with the interaction and becomes enforceable through policy. This ensures AI does not silently bypass years of data classification work already in place. 3. DLP for AI prompts and responses One of the most powerful but yet misunderstood purview capabilities is the AI‑aware DLP. Using DSPM for AI and standard Purview DLP: Prompts sent to AI apps are inspected Responses generated by AI can be validated Sensitive data types (PII, PCI, credentials, etc.) can be blocked, warned, or audited Policies are enforced consistently across M365 and AI workloads Microsoft specifically highlights this capability to prevent sensitive data from leaving trust boundaries via AI interactions. 4. Auditing and investigation Every AI interaction governed by Purview can be recorded in the Unified Audit Log, enabling: Forensic investigation Compliance validation Insider risk analysis eDiscovery for legal or regulatory needs This becomes critical when AI output influences business decisions and regulatory scrutiny increases. Audit records treat AI interactions as first‑class compliance events, not opaque system actions 5. Oversharing risk management Rather than waiting for a breach, Purview proactively highlights oversharing patterns using DSPM: AI repeatedly accessing broadly shared SharePoint sites High volumes of sensitive data referenced in prompts Excessive AI access to business‑critical repositories These insights feed remediation workflows, enabling administrators to tighten permissions, re‑scope access, or restrict AI visibility into specific datasets. In a nutshell, With agentic AI accelerating rapidly, Microsoft has made it clear that organizations must move governance closer to data, not embed it into individual AI apps. Purview provides a scalable way to enforce governance without rewriting every AI workload, while Entra continues to enforce who is allowed to act in the first place. This journey makes every organizations adopt Zero Trust at scale as its no longer limited to users, devices, and applications; It must now extend to AI apps and autonomous agents that act on behalf of the business. If you find the article insightful and you appreciate my time, please do not forget to like it 🙂Stuck looking up a watchlist value
Hiya, I get stuck working with watchlists sometimes. In this example, I'm wanting to focus on account activity from a list of UPNs. If I split the elements up, I get the individual results, but can't seem to pull it all together. ===================================================== In its entirety, the query returns zero results: let ServiceAccounts=(_GetWatchlist('ServiceAccounts_Monitoring'))| project SearchKey; let OpName = dynamic(['Reset password (self-service)','Reset User Password','Change user password','User reset password','User started password reset','Enable Account','Change password (self-service)','Update PasswordProfile','Self-service password reset flow activity progress']); AuditLogs | where OperationName has_any (OpName) | extend upn = TargetResources.[0].userPrincipalName | where upn in (ServiceAccounts) //<=This is where I think I'm wrong | project upn ===================================================== This line on its own, returns the user on the list: let ServiceAccounts=(_GetWatchlist('ServiceAccounts_Monitoring'))| project SearchKey; ===================================================== This section on its own, returns all the activity let OpName = dynamic(['Reset password (self-service)','Reset User Password','Change user password','User reset password','User started password reset','Enable Account','Change password (self-service)','Update PasswordProfile','Self-service password reset flow activity progress']); AuditLogs | where OperationName has_any (OpName) | extend upn = TargetResources.[0].userPrincipalName | where upn contains "username" //This is the name on the watchlistlist - so I know the activity exists) ==================================================== I'm doing something wrong when I'm trying to use the watchlist cache (I think) Any help\guidance or wisdom would be greatly appreciated! Many thanksPURVIEW - SCANNER ACCOUNT MISMATCH
Hello I have a strange issue on Scanner Setup is fine also discover is fine, in activity explorer we see discovered file, issue was in USER column that reports not scanner dedicated user but purview admin user. We also try open a case with MS but no one respond Any suggestions? Thanks Zeno
Feature Request: Extend Security Copilot inclusion (M365 E5) to M365 A5 Education tenants
Background At Ignite 2025, Microsoft announced that Security Copilot is included for all Microsoft 365 E5 customers, with a phased rollout starting November 18, 2025. This is a significant step forward for security operations. The gap Microsoft 365 A5 for Education is the academic equivalent of E5 — it includes the same core security stack: Microsoft Defender, Entra, Intune, and Purview. However, the Security Copilot inclusion explicitly covers only commercial E5 customers. There is no public roadmap or timeline for extending this benefit to A5 education tenants. Why this matters Education institutions face the same cybersecurity threats as commercial organizations — often with fewer dedicated security resources. The A5 license was positioned as the premium security offering for education. Excluding it from Security Copilot inclusion creates an inequity between commercial and education customers holding functionally equivalent license tiers. Request We would like Microsoft to: Confirm whether Security Copilot inclusion will be extended to M365 A5 Education tenants If yes, provide an indicative timeline If no, clarify the rationale and what alternative paths exist for education customers Are other EDU admins in the same situation? Would appreciate any upvotes or comments to help raise visibility with the product team.
telemetryd_v2 High CPU in macOS
I've been seeing this process have consistently high CPU use. According to Activity Monitor, it's a child process of wdavdaemon_enterprise. I tried disabling realtime protection, but that did not decrease the CPU use. The other notable change that I can think of is that I downloaded the Chromium codebase yesterday and built it, so I'm wondering if that's causing the cloud submission process to go crazy. I looked at https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/mac-support-perf?view=o365-worldwide, but it only discusses realtime scanning. Can anyone provide insight on what this specific process is responsible for? Thanks.Sent email cannot be viewed by sender when encrypted.
Emails that are sent in outlook are not viewable in the sent items folder of the outlook desktop app but work fine in the outlook web app. The error that shows is the same as the one for when recipients cannot view the email in the email client but if they click on the link it still does not let them view the email. Seems to be affecting only certain members of the organisation but there does not seems to be a pattern of software/admin rights/plugins/etc. Does anyone have any ideas as to what is likely to cause this? Thanks.
Organisational vs model-level AI governance — where's the real gap?
Most AI governance conversations I'm seeing focus on model-level controls, like bias testing and prompt injection defence. These matter enormously for individual AI systems. But I'd argue the bigger gap is one level up: the organisational governance layer. Having the policies, accountability structures, risk frameworks, and oversight mechanisms to govern AI use at enterprise scale. Who is accountable for AI-related decisions? Where is sensitive data being processed? What AI tools are actually being used across the business? Forrester research indicates 60% of organisations still lack a formal AI governance framework. Meanwhile, the EU AI Act reaches full compliance obligations in August 2026, and ISO/IEC 42001 is gaining traction as the certifiable benchmark for AI management systems. Microsoft is building strong technical solutions for the model-level challenge, Purview for data governance, Entra Agent ID, Defender for threat protection, Compliance Manager for regulatory mapping. But in my experience, organisations that jump straight to configuring technical controls without first understanding their organisational maturity end up with tools deployed but governance gaps unchanged. Are we solving the right problem first?I would like to know the complete list of alerts whose serviceSource is MDO
Hi all In order to determine the alerts that should be monitored by the SOC, I would like to identify, from the alerts listed at the link below, those whose serviceSource is Microsoft Defender for Office 365 (MDO). https://learn.microsoft.com/en-us/defender-xdr/alert-policies I couldn’t find where this is documented, no matter how thoroughly I searched, so I would appreciate it if you could point me to the relevant documentation. thxWebinar Cancellation
Hi everyone! The webinar originally scheduled for April 14th on "Using distributed content to manage your multi-tenant SecOps" has unfortunately been cancelled for now. We apologize for the inconvenience and hope to reschedule it in the future. Please find other available webinars at: http://aka.ms/securitycommunity All the best, The Microsoft Security Community Team
'Microsoft App Access Panel' and Conditional Access with SSPR combined registration bug
Currently, enabling self-service password reset (SSPR) registration enforcement causes the app 'Microsoft App Access Panel' to be added to the login flow of users who have SSPR enabled. This app is not able to be excluded from Conditional Access (CA) polices and is caught by 'All cloud apps', which breaks secure zero-trust scenarios and CA policy configurations. Best way to demonstrate this is through examples... ----Example 1---- Environment: CA Policy 1 - 'All cloud apps' requiring hybrid/compliant device, but excluding [App] (for all non-guest accounts) CA Policy 2 - [App] requiring MFA only (for contractor accounts, etc) CA Policy 3 - [App] requiring hybrid/compliant device (for internal accounts, etc) SSPR registration enforcement (Password reset > Registration) - set to 'Yes' MFA registration enforcement (Security > Authentication Methods > Registration campaign) - set to 'Enabled' Scenario: A new user requires access to web [App] on an unenrolled device and is assigned an account that falls under CA Policy 1 and 2, however [App] is excluded from 1 and shouldn't apply to this login. When accessing [App] for the first time, users must register SSPR/MFA. They see the below message, click 'Next' and are directed to https://accounts.activedirectory.windowsazure.com/passwordreset/register.aspx: Then they see this screen, which will block the login and try to get the user to download the Company Portal app: While behind the scenes, the login to [App] is being blocked by 'Microsoft App Access Panel' because it is seemingly added to the login flow and caught in CA Policy 1 in Req 2/3: CA Policy 1 shows as not applied on Req 1, CA Policy 2 shows as successful for Req 1/2/3 and CA Policy 3 shows as not applied for Req 1/2/3. Creating a CA policy for the 'Register security information' user action has no effect on this scenario and also shows as not applied on all the related sign-in logs. ----Example 2---- Environment: Same as above, but SSPR registration enforcement - set to 'No' Scenario: Same as above, but when accessing the [App] for the first time, they see the below message instead, click 'Next' and are directed to https://accounts.activedirectory.windowsazure.com/proofup.aspx: Then they are directed to the combined SSPR/MFA registration experience successfully: The 'Microsoft App Access Panel' doesn't show in the sign-in logs and the sign-in is successful after registration. From the two examples, it seems to be a bug with the SSPR registration enforcement and the combined registration experience. ----Workarounds---- 1 - Prevent using 'All cloud apps' with device based CA policies (difficult, requires redesigning/thinking/testing policies, could introduce new gaps, etc) 2 - Turn off SSPR registration enforcement and turn on MFA registration enforcement like in example 2 (easy, but only enforces MS MFA App registration, doesn't seem to re-trigger registration if the MS MFA App is removed, no other methods are supported for registration, and doesn't remind users to update) 3 - Disable SSPR entirely for affected users (medium depending on available security groups, and doesn't allow for affected users to use SSPR) ----Related links---- https://feedback.azure.com/d365community/idea/d5253b08-d076-ed11-a81b-000d3adb7ffd https://feedback.azure.com/d365community/idea/1365df89-c625-ec11-b6e6-000d3a4f0789 Conditional Access Policies, Guest Access and the "Microsoft Invitation Acceptance Portal" - Microsoft Community Hub MS, please either: 1 - Allow 'Microsoft App Access Panel' to be added to CA policies so it can be excluded 2 - Prevent 'Microsoft App Access Panel' from showing up in the CA login flow when SSPR registration enforcement is enabled
KQL query not working
Hi everyone, I'm not a kusto expert so bare with me. I'm trying to replace a text to another text... The one in bold is what I'm tryng to use but is not working. Basically the log doesn't make a reference for (9999) which is actually "URL filtering log"... and I need this this to show on the results... not as (9999) but as "URL filtering log". I've been trying to use CommonSecurityLog | where DeviceProduct has 'PAN-OS' | where DeviceVendor =~ 'Palo AltoNetworks' //| where DeviceEventClassID =~ 'correlation' | extend ThreatId = extract('cat=([^;]+)', 1, AdditionalExtensions) | extend ThreatCategory = extract('PanOSThreatCategory=([^;]+)', 1, AdditionalExtensions) | extend str=strcat("9999", "9999", "URL") | extend replaced=replace_string(str, '9999', 'URL') | summarize Amount=count() by ThreatId, ThreatCategory, LogSeverity | top 20 by Amount RESULTS:Kerberos and the End of RC4: Protocol Hardening and Preparing for CVE‑2026‑20833
CVE-2026-20833 addresses the continued use of the RC4‑HMAC algorithm within the Kerberos protocol in Active Directory environments. Although RC4 has been retained for many years for compatibility with legacy systems, it is now considered cryptographically weak and unsuitable for modern authentication scenarios. As part of the security evolution of Kerberos, Microsoft has initiated a process of progressive protocol hardening, whose objective is to eliminate RC4 as an implicit fallback, establishing AES128 and AES256 as the default and recommended algorithms. This change should not be treated as optional or merely preventive. It represents a structural change in Kerberos behavior that will be progressively enforced through Windows security updates, culminating in a model where RC4 will no longer be implicitly accepted by the KDC. If Active Directory environments maintain service accounts, applications, or systems dependent on RC4, authentication failures may occur after the application of the updates planned for 2026, especially during the enforcement phases introduced starting in April and finalized in July 2026. For this reason, it is essential that organizations proactively identify and eliminate RC4 dependencies, ensuring that accounts, services, and applications are properly configured to use AES128 or AES256 before the definitive changes to Kerberos protocol behavior take effect. Official Microsoft References CVE-2026-25177 - Security Update Guide - Microsoft - Active Directory Domain Services Elevation of Privilege Vulnerability Microsoft Support – How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 (KB 5073381) Microsoft Learn – Detect and Remediate RC4 Usage in Kerberos AskDS – What is going on with RC4 in Kerberos? Beyond RC4 for Windows authentication | Microsoft Windows Server Blog So, you think you’re ready for enforcing AES for Kerberos? | Microsoft Community Hub Risk Associated with the Vulnerability When RC4 is used in Kerberos tickets, an authenticated attacker can request Service Tickets (TGS) for valid SPNs, capture these tickets, and perform offline brute-force attacks, particularly Kerberoasting scenarios, with the goal of recovering service account passwords. Compared to AES, RC4 allows significantly faster cracking, especially for older accounts or accounts with weak passwords. Technical Overview of the Exploitation In simplified terms, the exploitation flow occurs as follows: The attacker requests a TGS for a valid SPN. The KDC issues the ticket using RC4, when that algorithm is still accepted. The ticket is captured and analyzed offline. The service account password is recovered. The compromised account is used for lateral movement or privilege escalation. Official Timeline Defined by Microsoft Important clarification on enforcement behavior Explicit account encryption type configurations continue to be honored even during enforcement mode. The Kerberos hardening associated with CVE‑2026‑20833 focuses on changing the default behavior of the KDC, enforcing AES-only encryption for TGS ticket issuance when no explicit configuration exists. This approach follows the same enforcement model previously applied to Kerberos session keys in earlier security updates (for example, KB5021131 related to CVE‑2022‑37966), representing another step in the progressive removal of RC4 as an implicit fallback. January 2026 – Audit Phase Starting in January 2026, Microsoft initiated the Audit Phase related to changes in RC4 usage within Kerberos, as described in the official guidance associated with CVE-2026-20833. The primary objective of this phase is to allow organizations to identify existing RC4 dependencies before enforcement changes are applied in later phases. During this phase, no functional breakage is expected, as RC4 is still permitted by the KDC. However, additional auditing mechanisms were introduced, providing greater visibility into how Kerberos tickets are issued in the environment. Analysis is primarily based on the following events recorded in the Security Log of Domain Controllers: Event ID 4768 – Kerberos Authentication Service (AS request / Ticket Granting Ticket) Event ID 4769 – Kerberos Service Ticket Operations (Ticket Granting Service – TGS) Additional events related to the KDCSVC service These events allow identification of: the account that requested authentication the requested service or SPN the source host of the request the encryption algorithm used for the ticket and session key This information is critical for detecting scenarios where RC4 is still being implicitly used, enabling operations teams to plan remediation ahead of the enforcement phase. If these events are not being logged on Domain Controllers, it is necessary to verify whether Kerberos auditing is properly enabled. For Kerberos authentication events to be recorded in the Security Log, the corresponding audit policies must be configured. The minimum recommended configuration is to enable Success auditing for the following subcategories: Kerberos Authentication Service Kerberos Service Ticket Operations Verification can be performed directly on a Domain Controller using the following commands: auditpol /get /subcategory:"Kerberos Service Ticket Operations" auditpol /get /subcategory:"Kerberos Authentication Service" In enterprise environments, the recommended approach is to apply this configuration via Group Policy, ensuring consistency across all Domain Controllers. The corresponding policy can be found at: Computer Configuration - Policies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Audit Policies - Account Logon Once enabled, these audits record events 4768 and 4769 in the Domain Controllers’ Security Log, allowing analysis tools—such as inventory scripts or SIEM/Log Analytics queries—to accurately identify where RC4 is still present in the Kerberos authentication flow. April 2026 – Enforcement with Manual Rollback With the April 2026 update, the KDC begins operating in AES-only mode (0x18) when the msDS-SupportedEncryptionTypes attribute is not defined. This means RC4 is no longer accepted as an implicit fallback. During this phase, applications, accounts, or computers that still implicitly depend on RC4 may start failing. Manual rollback remains possible via explicit configuration of the attribute in Active Directory. July 2026 – Final Enforcement Starting in July 2026, audit mode and rollback options are removed. RC4 will only function if explicitly configured—a practice that is strongly discouraged. This represents the point of no return in the hardening process. Official Monitoring Approach Microsoft provides official scripts in the repository: https://github.com/microsoft/Kerberos-Crypto/tree/main/scripts The two primary scripts used in this analysis are: Get-KerbEncryptionUsage.ps1 The Get-KerbEncryptionUsage.ps1 script, provided by Microsoft in the Kerberos‑Crypto repository, is designed to identify how Kerberos tickets are issued in the environment by analyzing authentication events recorded on Domain Controllers. Data collection is primarily based on: Event ID 4768 – Kerberos Authentication Service (AS‑REQ / TGT issuance) Event ID 4769 – Kerberos Service Ticket Operations (TGS issuance) From these events, the script extracts and consolidates several relevant fields for authentication flow analysis: Time – when the authentication occurred Requestor – IP address or host that initiated the request Source – account that requested the ticket Target – requested service or SPN Type – operation type (AS or TGS) Ticket – algorithm used to encrypt the ticket SessionKey – algorithm used to protect the session key Based on these fields, it becomes possible to objectively identify which algorithms are being used in the environment, both for ticket issuance and session establishment. This visibility is essential for detecting RC4 dependencies in the Kerberos authentication flow, enabling precise identification of which clients, services, or accounts still rely on this legacy algorithm. Example usage: .\Get-KerbEncryptionUsage.ps1 -Encryption RC4 -Searchscope AllKdcs | Export-Csv -Path .\KerbUsage_RC4_All_ThisDC.csv -NoTypeInformation -Encoding UTF8 Data Consolidation and Analysis In enterprise environments, where event volumes may be high, it is recommended to consolidate script results into analytical tools such as Power BI to facilitate visualization and investigation. The presented image illustrates an example dashboard built from collected results, enabling visibility into: Total events analyzed Number of Domain Controllers involved Number of requesting clients (Requestors) Most frequently involved services or SPNs (Targets) Temporal distribution of events RC4 usage scenarios (Ticket, SessionKey, or both) This type of visualization enables rapid identification of RC4 usage patterns, remediation prioritization, and progress tracking as dependencies are eliminated. Additionally, dashboards help answer key operational questions, such as: Which services still depend on RC4 Which clients are negotiating RC4 for sessions Which Domain Controllers are issuing these tickets Whether RC4 usage is decreasing over time This combined automated collection + analytical visualization approach is the recommended strategy to prepare environments for the Microsoft changes related to CVE‑2026‑20833 and the progressive removal of RC4 in Kerberos. Visualizing Results with Power BI To facilitate analysis and monitoring of RC4 usage in Kerberos, it is recommended to consolidate script results into a Power BI analytical dashboard. 1. Install Power BI Desktop Download and install Power BI Desktop from the official Microsoft website 2. Execute data collection After running the Get-KerbEncryptionUsage.ps1 script, save the generated CSV file to the following directory: C:\Temp\Kerberos_KDC_usage_of_RC4_Logs\KerbEncryptionUsage_RC4.csv 3. Open the dashboard in Power BI Open the file RC4-KerbEncryptionUsage-Dashboards.pbix using Power BI Desktop. If you are interested, please leave a comment on this post with your email address, and I will be happy to share with you. 4. Update the data source If the CSV file is located in a different directory, it will be necessary to adjust the data source path in Power BI. As illustrated, the dashboard uses a parameter named CsvFilePath, which defines the path to the collected CSV file. To adjust it: Open Transform Data in Power BI. Locate the CsvFilePath parameter in the list of Queries. Update the value to the directory where the CSV file was saved. Click Refresh Preview or Refresh to update the data. Click Home → Close & Apply. This approach allows rapid identification of RC4 dependencies, prioritization of remediation actions, and tracking of progress throughout the elimination process. List-AccountKeys.ps1 This script is used to identify which long-term keys are present on user, computer, and service accounts, enabling verification of whether RC4 is still required or whether AES128/AES256 keys are already available. Interpreting Observed Scenarios Microsoft recommends analyzing RC4 usage by jointly considering two key fields present in Kerberos events: Ticket Encryption Type Session Encryption Type Each combination represents a distinct Kerberos behavior, indicating the source of the issue, risk level, and remediation point in the environment. In addition to events 4768 and 4769, updates released starting January 13, 2026, introduce new Kdcsvc events in the System Event Log that assist in identifying RC4 dependencies ahead of enforcement. These events include: Event ID 201 – RC4 usage detected because the client advertises only RC4 and the service does not have msDS-SupportedEncryptionTypes defined. Event ID 202 – RC4 usage detected because the service account does not have AES keys and the msDS-SupportedEncryptionTypes attribute is not defined. Event ID 203 – RC4 usage blocked (enforcement phase) because the client advertises only RC4 and the service does not have msDS-SupportedEncryptionTypes defined. Event ID 204 – RC4 usage blocked (enforcement phase) because the service account does not have AES keys and msDS-SupportedEncryptionTypes is not defined. Event ID 205 – Detection of explicit enablement of insecure algorithms (such as RC4) in the domain policy DefaultDomainSupportedEncTypes. Event ID 206 – RC4 usage detected because the service accepts only AES, but the client does not advertise AES support. Event ID 207 – RC4 usage detected because the service is configured for AES, but the service account does not have AES keys. Event ID 208 – RC4 usage blocked (enforcement phase) because the service accepts only AES and the client does not advertise AES support. Event ID 209 – RC4 usage blocked (enforcement phase) because the service accepts only AES, but the service account does not have AES keys. https://support.microsoft.com/en-gb/topic/how-to-manage-kerberos-kdc-usage-of-rc4-for-service-account-ticket-issuance-changes-related-to-cve-2026-20833-1ebcda33-720a-4da8-93c1-b0496e1910dc They indicate situations where RC4 usage will be blocked in future phases, allowing early detection of configuration issues in clients, services, or accounts. These events are logged under: Log: System Source: Kdcsvc Below are the primary scenarios observed during the analysis of Kerberos authentication behavior, highlighting how RC4 usage manifests across different ticket and session encryption combinations. Each scenario represents a distinct risk profile and indicates specific remediation actions required to ensure compliance with the upcoming enforcement phases. Scenario A – RC4 / RC4 In this scenario, both the Kerberos ticket and the session key are issued using RC4. This is the worst possible scenario from a security and compatibility perspective, as it indicates full and explicit dependence on RC4 in the authentication flow. This condition significantly increases exposure to Kerberoasting attacks, since RC4‑encrypted tickets can be subjected to offline brute-force attacks to recover service account passwords. In addition, environments remaining in this state have a high probability of authentication failure after the April 2026 updates, when RC4 will no longer be accepted as an implicit fallback by the KDC. Events Associated with This Scenario During the Audit Phase, this scenario is typically associated with: Event ID 201 – Kdcsvc Indicates that: the client advertises only RC4 the service does not have msDS-SupportedEncryptionTypes defined the Domain Controller does not have DefaultDomainSupportedEncTypes defined This means RC4 is being used implicitly. This event indicates that the authentication will fail during the enforcement phase. Event ID 202 – Kdcsvc Indicates that: the service account does not have AES keys the service does not have msDS-SupportedEncryptionTypes defined This typically occurs when: legacy accounts have never had their passwords reset only RC4 keys exist in Active Directory Possible Causes Common causes include: the originating client (Requestor) advertises only RC4 the target service (Target) is not explicitly configured to support AES the account has only legacy RC4 keys the msDS-SupportedEncryptionTypes attribute is not defined Recommended Actions To remediate this scenario: Correctly identify the object involved in the authentication flow, typically: a service account (SPN) a computer account or a Domain Controller computer object Verify whether the object has AES keys available using analysis tools or scripts such as List-AccountKeys.ps1. If AES keys are not present, reset the account password, forcing generation of modern cryptographic keys (AES128 and AES256). Explicitly define the msDS-SupportedEncryptionTypes attribute to enable AES support. Recommended value for modern environments: 0x18 (AES128 + AES256) = 24 As illustrated below, this configuration can be applied directly to the msDS-SupportedEncryptionTypes attribute in Active Directory. AES can also be enabled via Active Directory Users and Computers by explicitly selecting: This account supports Kerberos AES 128 bit encryption This account supports Kerberos AES 256 bit encryption These options ensure that new Kerberos tickets are issued using AES algorithms instead of RC4. Temporary RC4 Usage (Controlled Rollback) In transitional scenarios—during migration or troubleshooting—it may be acceptable to temporarily use: 0x1C (RC4 + AES) = 28 This configuration allows the object to accept both RC4 and AES simultaneously, functioning as a controlled rollback while legacy dependencies are identified and corrected. However, the final objective must be to fully eliminate RC4 before the final enforcement phase in July 2026, ensuring the environment operates exclusively with AES128 and AES256. Scenario B – AES / RC4 In this case, the ticket is protected with AES, but the session is still negotiated using RC4. This typically indicates a client limitation, legacy configuration, or restricted advertisement of supported algorithms. Events Associated with This Scenario During the Audit Phase, this scenario may generate: Event ID 206 Indicates that: the service accepts only AES the client does not advertise AES in the Advertised Etypes In this case, the client is the issue. Recommended Action Investigate the Requestor Validate operating system, client type, and advertised algorithms Review legacy GPOs, hardening configurations, or settings that still force RC4 For Linux clients or third‑party applications, review krb5.conf, keytabs, and Kerberos libraries Scenario C – RC4 / AES Here, the session already uses AES, but the ticket is still issued using RC4. This indicates an implicit RC4 dependency on the Target or KDC side, and the environment may fail once enforcement begins. Events Associated with This Scenario This scenario may generate: Event ID 205 Indicates that the domain has explicit insecure algorithm configuration in: DefaultDomainSupportedEncTypes This means RC4 is explicitly allowed at the domain level. Recommended Action Correct the Target object Explicitly define msDS-SupportedEncryptionTypes with 0x18 = 24 Revalidate new ticket issuance to confirm full migration to AES / AES Conclusion CVE‑2026‑20833 represents a structural change in Kerberos behavior within Active Directory environments. Proper monitoring is essential before April 2026, and the msDS-SupportedEncryptionTypes attribute becomes the primary control point for service accounts, computer accounts, and Domain Controllers. July 2026 represents the final enforcement point, after which there will be no implicit rollback to RC4.Understand New Sentinel Pricing Model with Sentinel Data Lake Tier
Introduction on Sentinel and its New Pricing Model Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) platform that collects, analyzes, and correlates security data from across your environment to detect threats and automate response. Traditionally, Sentinel stored all ingested data in the Analytics tier (Log Analytics workspace), which is powerful but expensive for high-volume logs. To reduce cost and enable customers to retain all security data without compromise, Microsoft introduced a new dual-tier pricing model consisting of the Analytics tier and the Data Lake tier. The Analytics tier continues to support fast, real-time querying and analytics for core security scenarios, while the new Data Lake tier provides very low-cost storage for long-term retention and high-volume datasets. Customers can now choose where each data type lands—analytics for high-value detections and investigations, and data lake for large or archival types—allowing organizations to significantly lower cost while still retaining all their security data for analytics, compliance, and hunting. Please flow diagram depicts new sentinel pricing model: Now let's understand this new pricing model with below scenarios: Scenario 1A (PAY GO) Scenario 1B (Usage Commitment) Scenario 2 (Data Lake Tier Only) Scenario 1A (PAY GO) Requirement Suppose you need to ingest 10 GB of data per day, and you must retain that data for 2 years. However, you will only frequently use, query, and analyze the data for the first 6 months. Solution To optimize cost, you can ingest the data into the Analytics tier and retain it there for the first 6 months, where active querying and investigation happen. After that period, the remaining 18 months of retention can be shifted to the Data Lake tier, which provides low-cost storage for compliance and auditing needs. But you will be charged separately for data lake tier querying and analytics which depicted as Compute (D) in pricing flow diagram. Pricing Flow / Notes The first 10 GB/day ingested into the Analytics tier is free for 31 days under the Analytics logs plan. All data ingested into the Analytics tier is automatically mirrored to the Data Lake tier at no additional ingestion or retention cost. For the first 6 months, you pay only for Analytics tier ingestion and retention, excluding any free capacity. For the next 18 months, you pay only for Data Lake tier retention, which is significantly cheaper. Azure Pricing Calculator Equivalent Assuming no data is queried or analyzed during the 18-month Data Lake tier retention period: Although the Analytics tier retention is set to 6 months, the first 3 months of retention fall under the free retention limit, so retention charges apply only for the remaining 3 months of the analytics retention window. Azure pricing calculator will adjust accordingly. Scenario 1B (Usage Commitment) Now, suppose you are ingesting 100 GB per day. If you follow the same pay-as-you-go pricing model described above, your estimated cost would be approximately $15,204 per month. However, you can reduce this cost by choosing a Commitment Tier, where Analytics tier ingestion is billed at a discounted rate. Note that the discount applies only to Analytics tier ingestion—it does not apply to Analytics tier retention costs or to any Data Lake tier–related charges. Please refer to the pricing flow and the equivalent pricing calculator results shown below. Monthly cost savings: $15,204 – $11,184 = $4,020 per month Now the question is: What happens if your usage reaches 150 GB per day? Will the additional 50 GB be billed at the Pay-As-You-Go rate? No. The entire 150 GB/day will still be billed at the discounted rate associated with the 100 GB/day commitment tier bucket. Azure Pricing Calculator Equivalent (100 GB/ Day) Azure Pricing Calculator Equivalent (150 GB/ Day) Scenario 2 (Data Lake Tier Only) Requirement Suppose you need to store certain audit or compliance logs amounting to 10 GB per day. These logs are not used for querying, analytics, or investigations on a regular basis, but must be retained for 2 years as per your organization’s compliance or forensic policies. Solution Since these logs are not actively analyzed, you should avoid ingesting them into the Analytics tier, which is more expensive and optimized for active querying. Instead, send them directly to the Data Lake tier, where they can be retained cost-effectively for future audit, compliance, or forensic needs. Pricing Flow Because the data is ingested directly into the Data Lake tier, you pay both ingestion and retention costs there for the entire 2-year period. If, at any point in the future, you need to perform advanced analytics, querying, or search, you will incur additional compute charges, based on actual usage. Even with occasional compute charges, the cost remains significantly lower than storing the same data in the Analytics tier. Realized Savings Scenario Cost per Month Scenario 1: 10 GB/day in Analytics tier $1,520.40 Scenario 2: 10 GB/day directly into Data Lake tier $202.20 (without compute) $257.20 (with sample compute price) Savings with no compute activity: $1,520.40 – $202.20 = $1,318.20 per month Savings with some compute activity (sample value): $1,520.40 – $257.20 = $1,263.20 per month Azure calculator equivalent without compute Azure calculator equivalent with Sample Compute Conclusion The combination of the Analytics tier and the Data Lake tier in Microsoft Sentinel enables organizations to optimize cost based on how their security data is used. High-value logs that require frequent querying, real-time analytics, and investigation can be stored in the Analytics tier, which provides powerful search performance and built-in detection capabilities. At the same time, large-volume or infrequently accessed logs—such as audit, compliance, or long-term retention data—can be directed to the Data Lake tier, which offers dramatically lower storage and ingestion costs. Because all Analytics tier data is automatically mirrored to the Data Lake tier at no extra cost, customers can use the Analytics tier only for the period they actively query data, and rely on the Data Lake tier for the remaining retention. This tiered model allows different scenarios—active investigation, archival storage, compliance retention, or large-scale telemetry ingestion—to be handled at the most cost-effective layer, ultimately delivering substantial savings without sacrificing visibility, retention, or future analytical capabilities.[HELP] "Action required for browser protections" alert
Hello! I have an Endpoint DLP policy with Device location. After several scoping changes (device groups, inclusions/exclusions) to narrow it to a specific target group, the orange alert appeared: Action required for browser protections. One or more policies were not applied in Edge for Business. This could be due to a policy sync issue, lack of required permissions, or an issue with the server. Either resync these policies or contact an admin with the required permissions to resync. After resyncing, you might still see this message for up to 1 day while the system completes the sync and activates protections. The policies were working before. Clicked Resync multiple times, only for the error to return. Please help!
Events
Take your AI security to the next level. Explore advanced techniques and best practices for safeguarding AI-powered applications against evolving threats in the cloud.
What you’ll learn:
Enable...
Online
Accidental changes and security compromises can quickly cascade across your tenant. Learn how to recover with confidence using Microsoft Entra Backup and Recovery.
Tune in to see how this Microsof...
Online