Recent Blogs
Modern insider risk investigations succeed or fail based on how quickly analysts can move from signal to decision with more context. Too often, investigations within Microsoft Purview require high sw...
Jun 30, 2026
Move from point-in-time restore to a full tenant recoverability strategy with Microsoft Entra Backup and Recovery, included in Entra P1 and P2.
Jun 30, 2026
5 MIN READ
Behind the Build is an ongoing series spotlighting standout Microsoft partner collaborations. Each edition dives into the technical and strategic decisions that shape real-world integrations—highligh...
Jun 30, 2026
Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl
The portal change was the easy part. The real upside is the operating model it unlocks—generative AI in every workflow, behav...
Jun 30, 2026Recent Discussions
PHS staged rollout works for existing users but not new synced users
We are troubleshooting an Entra ID PHS staged rollout issue with a federated domain using a third-party WS-Fed IdP. The intended behavior is that normal federated users redirect to the IdP, while users in the PHS staged rollout group receive the Microsoft/Entra password prompt instead. Existing users in the staged rollout group continue to work correctly. They enter their UPN and receive the Microsoft password prompt. One known-good test user is not provisioned in the third-party IdP and still signs in successfully through the Entra password prompt, so the working path does not require the user to exist in the IdP. The issue is only with newly created AD-synced users. Newly synced users in the same staged rollout group are still being routed to the federated IdP at HRD instead of receiving the Entra password prompt. We’ve verified the staged rollout policy and group membership from Graph, confirmed the affected users are properly AD-synced with clean immutableID/sourceAnchor, and confirmed PHS is working. Federation metadata and HRD policies also look clean. Seamless SSO/AZUREADSSOACC was checked and remediated, but the behavior did not change. For failed attempts, there is no Entra sign-in log entry, including tenant-wide interactive and non-interactive logs. However, the federated IdP logs show a WS-Fed inbound request from login.microsoftonline.com for the affected user. That makes it look like Entra HRD is routing the user to federation before sign-in logging or token issuance. The issue started around an Entra Connect AD connector/DC-path change. We have since reverted the connector to the previous known-good configuration. After reverting, we created a clean-room test user with the correct UPN set before first sync, confirmed sync/PHS/sourceAnchor, added the user directly to the staged rollout group, and waited 60+ minutes. The clean-room user still redirected to the federated IdP instead of getting the Entra password prompt. So the current behavior is that established staged-rollout users still get the Entra password prompt, but newly created synced staged-rollout users are sent to the federated IdP by HRD. Has anyone seen staged rollout get into this state, where existing users work but new synced users remain on the federated HRD path despite valid rollout policy, group membership, synced password hash, and clean immutableID/sourceAnchor? Is there any known backend cache/state reset or escalation path for HRD/staged rollout routing?Windows 11 24H2 Sec Baseline → Broken SSO to on‑prem (Root cause: PKINIT SHA‑1 baseline)
Hi all, I ran into an issue with Entra-joined devices using Windows Hello for Business (Cloud Kerberos Trust) that might help others working with Windows 11 24H2 security baselines. Scenario Windows 11 25H2 devices Entra-joined (not hybrid) Intune-managed Windows Hello for Business (WHfB) enabled Cloud Kerberos Trust configured On-prem AD (Windows Server 2019/2022 DCs) Access to SMB shares / on-prem applications Symptoms SSO to on-prem resources fails Users get credential/PIN prompt instead of SSO Error message: “The system cannot contact a domain controller to service the authentication request” Client-side observations: klist → no tickets (initially) After enabling Cloud Kerberos Trust: klist get krbtgt → works klist get cifs/server.domain → fails Error: 0xc000a100 / 0x3bc4 Hash generation for the specified version and hash type is not enabled on server Root Cause The issue was caused by a Windows 11 24H2 security baseline setting related to Kerberos/PKINIT. The 24H2 baseline introduces a policy for configuring hash algorithms for certificate-based Kerberos authentication (PKINIT). This setting allows environments to disable SHA-1 and require SHA-2 algorithms. [applepie.se] Important detail: This configuration only works if the domain controllers fully support PKINIT with SHA-2, which effectively requires Windows Server 2025 domain controllers across the environment. If SHA-1 is disabled while running: Windows Server 2019 or 2022 DCs Mixed environments then PKINIT authentication fails, which directly impacts: Windows Hello for Business Cloud Kerberos Trust Any passwordless Kerberos-based authentication Why this is difficult to troubleshoot Cloud Kerberos Trust appears correctly configured AzureADKerberos object exists PRT is valid Network connectivity is fine However: Kerberos tickets are not issued correctly Service tickets (CIFS, HTTP, etc.) fail Errors are misleading and point to KDC/hash issues No explicit warning is provided in baseline guidance that mixed environments will break Resolution Revert the baseline change and allow SHA-1 for PKINIT again. Policy location: Computer Configuration → System → Kerberos / KDC → Configure hash algorithms for certificate logon Ensure: SHA-1 is set to Allowed/Default After reverting: Kerberos ticket issuance works SSO to on-prem resources is restored Recommendation Do not disable SHA-1 for PKINIT unless: All domain controllers are Windows Server 2025, and PKINIT SHA-2 support has been fully validated Treat this setting as future hardening, not production-safe for mixed environments today. Takeaway If you experience: WHfB + Cloud Kerberos Trust SSO failures klist get errors with hash generation issues Missing or failing Kerberos service tickets check the PKINIT hash configuration from the 24H2 security baseline first.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.Sentinel to Defender Portal Migration - my 5 Gotchas to help you
The migration to the unified Defender portal is one of those transitions where the documentation covers "what's new" but glosses over what breaks on cutover day. Here are the gotchas that consistently catch teams off-guard, along with practical fixes. Gotcha 1: Automatic Connector Enablement When a Sentinel workspace connects to the Defender portal, Microsoft auto-enables certain connectors - often without clear notification. The most common surprises: Connector Auto-Enables? Impact Defender for Endpoint Yes EDR telemetry starts flowing, new alerts created Defender for Cloud Yes Additional incidents, potential ingestion cost increase Defender for Cloud Apps Conditional Depends on existing tenant config Azure AD Identity Protection No Stays in Sentinel workspace only Immediate action: Within 2 hours of connecting, navigate to Security.microsoft.com > Connectors & integrations > Data connectors and audit what auto-enabled. Compare against your pre-migration connector list and disable anything unplanned. Why this matters: Auto-enabled connectors can duplicate data sources - ingesting the same telemetry through both Sentinel and Defender connectors inflates Log Analytics costs by 20-40%. Gotcha 2: Incident Duplication The most disruptive surprise. The same incident appears twice: once from a Sentinel analytics rule, once from the Defender portal's auto-created incident creation rule. SOC teams get paged twice, deduplication breaks, and MTTR metrics go sideways. Diagnosis: SecurityIncident | where TimeGenerated > ago(7d) | summarize IncidentCount = count() by Title | where IncidentCount > 1 | order by IncidentCount desc If you see unexpected duplicates, the cause is almost certainly the auto-enabled Microsoft incident creation rule conflicting with your existing analytics rules. Fix: Disable the auto-created incident creation rule in Sentinel Automation rules, and rely on your existing analytics rule > incident mapping instead. This ensures incidents are created only through Sentinel's pipeline. Gotcha 3: Analytics Rule Title Dependencies The Defender portal matches incidents to analytics rules by title, not by rule ID. This creates subtle problems: Renaming a rule breaks the incident linkage Copying a rule with a similar title causes cross-linkage Two workspaces with identically named rules generate separate incidents for the same alert Prevention checklist: Audit all analytics rule titles for uniqueness before migration Document the title-to-GUID mapping as a reference Avoid renaming rules en masse during migration Use a naming convention like <Severity>_<Tactic>_<Technique> to prevent collisions Gotcha 4: RBAC Gaps Sentinel workspace RBAC roles don't directly translate to Defender portal permissions: Sentinel Role Defender Portal Equivalent Gap Microsoft Sentinel Responder Security Operator Minor - name change Microsoft Sentinel Contributor Security Operator + Security settings (manage) Significant - split across roles Sentinel Automation Contributor Automation Contributor (new) New role required Migration approach: Create new unified RBAC roles in the Defender portal that mirror your existing Sentinel permissions. Test with a pilot group before org-wide rollout. Keep workspace RBAC roles for 30 days as a fallback. Gotcha 5: Automation Rules Don't Auto-Migrate Sentinel automation rules and playbooks don't carry over to the Defender portal automatically. The syntax has changed, and not all Sentinel automation actions are available in Defender. Recommended approach: Export existing Sentinel automation rules (screenshot condition logic and actions) Recreate them in the Defender portal Run both in parallel for one week to validate behavior Retire Sentinel automation rules only after confirming Defender equivalents work correctly Practical Migration Timeline Phase 1 - Pre-migration (1-2 weeks before): Audit connectors, analytics rules, RBAC roles, and automation rules Document everything - titles, GUIDs, permissions, automation logic Test in a pilot environment first Phase 2 - Cutover day: Connect workspace to Defender portal Within 2 hours: audit auto-enabled connectors Within 4 hours: check for duplicate incidents Within 24 hours: validate RBAC and automation rules Phase 3 - Post-migration (1-2 weeks after): Monitor incident volume for duplication spikes Validate automation rules fire correctly Collect SOC team feedback on workflow impact After 1 week of stability: retire legacy automation rules Phase 4 - Cleanup (2-4 weeks after): Remove duplicate automation rules Archive workspace-specific RBAC roles once unified RBAC is stable Update SOC runbooks and documentation The bottom line: treat this as a parallel-run migration, not a lift-and-shift. Budget 2 weeks for parallel operations. Teams that rushed this transition consistently reported longer MTTR during the first month post-migration.
Unusual user agent found in table AADNonInteractiveUserSignInLogs
Hello, Investigating the registers of the table "AADNonInteractiveUserSignInLogs", I have found a user-agent "Rich Client 4.40.0.0", which investigating via web I have not found information about it, neither I have knowledge of what this user-agent is about. Has anyone seen this in a case related to Azure log-ins? Regards.
Content blocked by IT Admin
I am the IT Admin and I keep seeing this Windows Security pop up notification on my system about blocking mtalk.google.com. I do not have this installed nor can I find anything about it in the registry. How can I find and remove this completely to stop these notifications? Driving me crazy....
Best approach for contractor block policy
Hello there I need some assistance with your best approach for vendor block policy. I am thinking to create one policy with three rules Block all vendors with the block AD group Vendors to allow emails to approved domains only vendors to send email to external to organisation with ability to send to approve domains Do you think this is a good approach by breaking down into three different rules ? Also I am bit confused with the conditions on the rule 2 and rule 3. what would you your approach with complete breakdown ?
Is "Endpoint Security Policies" available to us? (error getting Intune policies)
Question We'd like to use Defender \ Endpoint Security Policies. Is that possible for my tenant's environment? Getting below error on "Defender \ Endpoint Security Policies" page "There seems to be an issue getting your Intune policies" Details of our environment Purpose of defender To protect our server fleet that's running outside of Azure Tenant GCC - Moderate Scoped Region Commercial Azure East US 2 Subscription Microsoft Defender for Servers Plan 1 (No other subscription, etc.) Defender Client OS Windows 2016, 2019, 2022 RHEL8, 9 (No desktops\laptops) Agents installed on each Windows and Linux server Defender is onboarded Arc is onboarded Configured Settings and Errors Defender \ Settings \ Configuration management \ Enforcement scope https://security.microsoft.com/securitysettings/endpoints/configuration_management2 Error at top of page "Intune is not configured to allow Microsoft Defender for Endpoint to manage security configuration settings." Use MDE to enforce security configuration settings from Intune Set to ON Enable configuration management Windows Server devices On tagged devices Windows Server Domain Controller devices On tagged devices Linux devices On tagged devices Security settings management for Microsoft Defender for Cloud onboarded devices. Set to ON Manage Security settings using Configuration Manager Set to OFF Defender \ Settings \ Configuration management \ Intune Permissions https://security.microsoft.com/securitysettings/endpoints/intune_permissions Getting error "Access needed You don't have the right permissions in AAD to view this information (in addition to those you already have in MDE). To adjust your permissions, go to the AAD portal." Defender \ Endpoint Security Policies https://security.microsoft.com/policy-inventory On main page, getting below error There seems to be an issue getting your Intune policies If I try to make a new policy There seems to be an issue loading the policy authoring wizard. Intune \ Endpoint security https://intune.microsoft.com/#view/Microsoft_Intune_Workflows/SecurityManagementMenu Getting Error You don't have access Intune roles | My permissions https://intune.microsoft.com/#view/Microsoft_Intune_DeviceSettings/RolesLandingMenuBlade/~/myPermissions You're an administrator with full permissions to all Microsoft Intune resources. Intune roles | Administrator Licensing https://intune.microsoft.com/#view/Microsoft_Intune_DeviceSettings/RolesLandingMenuBlade/~/administratorLicensing Allow admins without an Intune license to access Intune. Their scope of access is determined by the Intune roles you've assigned them. I've clicked the box "Allow access to unlicensed admins" Alternatives If Defender \ Endpoint Security Policies isn't available, as alternatives, I guess we could use SCCM Antimalware policies to manage Windows servers Deploying a central mdatp_managed.json to manage Linux servers However, it would be greatly preferred to use the Defender \ Endpoint Security Policies feature for Windows and Linux
Onboarding Devices to Purview
I am not clear on how can I onboard devices to MDE so that I can enforce EDLP policies. We have CrowdStrike as Primary AV and other policies. Devices are managed through Intune for Bitlocker encryption and all the other settings except they don't have Defender. These devices are not showing up in Purview nor under "Endpoint detection and response" location under Endpoint Security. If we create an EDR onboarding policy and deploy to devices, then it shows the devices and says that AMRUnningMode is Passive, but Antivirus is true. Which I feel like Defender is taking over CrowdStrike? or am I wrong. My goal is to make sure CrowdStrike still primary AV and devices should be onboarded to MDE and then to Purview so that we can scope EDLP policies properly. Can anyone help me to understand or provide right steps?Need information on generating sample events for Threat Intelligence" (both duplicate posts)
Two things are tripping this up, and they're common mix-ups: First — Attack Simulation Training doesn't generate Threat Intelligence events. If you used the built-in phishing simulator, its logs only show up under Email & collaboration → Attack simulation training → Simulations — they're intentionally excluded from real Threat Intelligence telemetry. That's likely why nothing's showing up even though you ran a campaign. Second — your EICAR test should actually work, but check the right place: not the generic Office 365 Management Activity API's AuditLogRecordType page in isolation — go specifically to the RecordType values used for Defender for Office 365 threat events: 28 = ThreatIntelligence (phishing/malware events) 41 = ThreatIntelligenceUrl (Safe Links time-of-click/block events) Plus ThreatIntelligenceAtpContent, ThreatFinder, MSTIC To reliably generate one: Confirm Purview audit logging is enabled for the tenant first — if it isn't, nothing downstream gets logged regardless of what you trigger. From an external mailbox, send a test user the EICAR string as a .txt attachment (exact 68-byte string, see Microsoft's anti-malware testing doc). Defender for Office 365 should detect and quarantine it. Verify it landed first in the portal UI: Email & collaboration → Explorer → Malware tab — if it's there, the underlying ThreatIntelligence record exists and the Management API call should return it (allow a short delay; these aren't instant). For the Safe Links side, send a known-safe-but-flagged test URL (Microsoft publishes test URLs for this) to trigger ThreatIntelligenceUrl. If it shows up in Explorer but still doesn't appear via the Management API, that's usually an API subscription/permission issue (you need an active subscription to the DLP.All or relevant Office 365 Management API content type, not just Graph permissions) — worth checking separately from the detection side.Can the Microsoft Defender portal show the server details as per security group?
Yes — this is exactly what Device Groups + RBAC are designed for in Microsoft Defender (assuming you're managing these servers through Defender for Endpoint, which is the typical path for cross-vendor server monitoring). The model: Device groups are the scoping unit (not Entra security groups directly) — create one per vendor/company (e.g., "Company A Servers", "Company B Servers"), using a matching rule (tag, OS, name pattern, etc.) to auto-assign devices. RBAC roles then get tied to an Entra security group and granted access to only specific device groups. So: Company A's people go in an Entra group → that group is assigned an MDE role scoped to "Company A Servers" only → they only ever see those devices, alerts, and incidents in the portal. You as admin keep your existing Global Admin/Security Admin role (or get added to both device groups' RBAC scope), so you retain visibility across both. Path: Settings → Endpoints → Permissions → Device groups to create the groups, then Permissions → Roles to create a role and tie it to your Entra security group with that device group as the scope. One thing to verify before committing to this design: this RBAC model affects what shows in alerts, incidents, advanced hunting (scoped automatically), and inventory — but make sure nobody from Company A/B also needs organization-wide Defender features like global threat analytics, since those aren't scopable the same way. If you're actually talking about servers monitored via Defender for Cloud (Azure subscription-based, not MDE-onboarded), the equivalent mechanism is Azure RBAC at the subscription/resource group level (assign Security Reader scoped to the RG containing Company A's VMs) — different mechanism, same outcome. Worth clarifying which portal/product this is so the right one gets recommended.Microsoft Defender Incident – Handling incident severity change
There's no dedicated history/audit endpoint for field-level transitions (like "this incident went from Low → High at timestamp X") in the /security/incidents Graph API — the incident object only exposes the current severity plus a lastUpdateDateTime, not a change log. So this isn't something you're missing; it genuinely doesn't exist as a queryable history today. Also worth knowing before you build around it: Graph change notifications (webhooks) are not documented as supported for /security/incidents — subscription/webhook support is only documented for the legacy /security/alerts resource, and that resource is deprecated with removal expected around April 2026. So polling is currently the only supported pattern for incidents specifically, not a limitation of your approach — there's no webhook alternative to fall back to yet. Given that, the fix is in your polling strategy, not in finding a hidden feature: instead of filtering once at creation time and then ignoring the incident, poll using $filter=lastUpdateDateTime gt {last_poll_timestamp}. Since lastUpdateDateTime bumps on any property change — including a severity escalation — this catches incidents that started as Low/Informational and later got escalated, without re-fetching everything. A pattern that works well in practice: GET /security/incidents?$filter=lastUpdateDateTime gt {last_poll_time}&$orderby=lastUpdateDateTime asc Then in your own store, diff the incoming severity against what you last recorded for that id to detect the transition yourself — you're effectively reconstructing the history client-side since the API won't give it to you natively. Store (incidentId, severity, lastUpdateDateTime) on each poll and compare. One gotcha: this still won't tell you the exact moment the severity changed if multiple fields changed between polls — only that it changed sometime between your last two poll timestamps. If you need second-level precision on transition timing, you'd need to poll more frequently (your 5-minute interval is probably fine for SOC triage purposes, but not for precise SLA timestamping).Exempt a specific container in MDC
You don't need a full exemption for this — the built-in policy behind "Immutable (read-only) root filesystem should be enforced for containers" already supports per-container and per-image exclusions natively, which is more precise than exempting at the resource/cluster level. This recommendation is implemented via the Azure Policy Add-on for Kubernetes (Gatekeeper constraint) as part of Defender for Cloud's data plane hardening. The underlying policy definition supports these parameters: excludedContainers — exclude by container name excludedImages — exclude by image (supports prefix matching, e.g. myregistry.azurecr.io/legacy-app:*) excludedNamespaces — exclude entire namespaces (e.g., kube-system, useful for system pods that legitimately can't run read-only) To configure: Defender for Cloud → Recommendations → select this recommendation → Take action tab, where you can set these parameters directly without touching raw policy JSON. Alternatively, if you manage policy via Environment Settings → Security policies → Standards, you can set the same parameters on the standard assignment. Given you said multiple containers across airflow/db1, airflow/sql1, etc. show "Unhealthy" — if these are legitimate exceptions (e.g., a database container that needs to write to its filesystem by design, not just a misconfiguration), excludedContainers naming each container is the cleanest fix and keeps the recommendation enforcing everywhere else in the cluster. I'd reserve a full policy exemption (Azure Policy exemption resource) for cases where you need it tracked for compliance/audit purposes specifically — the parameter-based exclusion is the more "native" and maintainable fix for ongoing operational cases like this.Exempt - Azure CSPM Recommendation" (Terraform exemption
The reason you're not finding a standalone policyAssignmentId/policyDefinitionId for this specific recommendation is that it isn't a standalone assignment — it's one control inside the built-in CSPM initiative (the "ASC Default" / Microsoft Cloud Security Benchmark assignment). That initiative does have an assignment ID; you just need to target the specific control within it, not look for a separate one. In azurerm_resource_policy_exemption (or the subscription/resource-group variants), the relevant fields are: policy_assignment_id → the ID of the initiative assignment (ASC Default / MCSB), not a per-recommendation assignment policy_definition_reference_ids → an array scoping the exemption to just this one control instead of the whole initiative resource "azurerm_resource_policy_exemption" "function_app_network_exemption" { name = "exempt-function-network-restriction" resource_id = azurerm_linux_function_app.example.id policy_assignment_id = data.azurerm_subscription_policy_assignment.asc_default.id policy_definition_reference_ids = [ "<reference-id-for-the-specific-control>" ] exemption_category = "Waiver" # or "Mitigated" if an equivalent control exists expires_on = "2026-12-31T00:00:00Z" } To find the policy_definition_reference_id for this specific control: in the Azure Portal, go to Policy → Definitions, search for "Restricted network access should be configured on Internet exposed Function app" to get its definition ID, then open the initiative definition (ASC Default) and find the matching entry in its policyDefinitions[].policyDefinitionReferenceId array — that string is what goes in the array above. Two things worth deciding upfront before automating this: Waiver vs Mitigated — if you've genuinely restricted access another way (e.g., Private Endpoint), use Mitigated so it's distinguishable from accepted risk in reporting. Consider whether the exemption belongs at the resource scope (just this Function App) vs resource group/subscription — narrower is safer, but if you have a pattern of similar apps, a tagged-based resourceSelectors block can scale this without per-resource blocks.Registering user becomes local admin on Joined Devices
This setting works exactly as named, but the confusion is understandable because the privilege is invisible in the places people normally look. Per Microsoft's official docs (assign-local-admin): at the moment of Microsoft Entra join, two principals get added to the local administrators group — the Microsoft Entra Joined Device Local Administrator role and the user performing the join. This happens only during the join operation itself. It's not a directory role assignment, so it won't show up in role assignments, audit logs, or under "Device Administrators" — that's by design. Critically: users aren't directly listed in the local admin group; the privilege is delivered through the Primary Refresh Token (PRT) at sign-in. So: To validate on the device itself, sign in as the user and run whoami /groups — you should see the device-local Administrators SID. If you just changed the setting and want to force re-evaluation, run dsregcmd /refreshprt, then sign out and back in (lock/unlock won't trigger it — you need a fresh PRT, which can take up to ~4 hours to propagate otherwise). This setting only applies to joined devices, not registered (workplace-joined) ones — so your distinction there is correct. The "Manage Additional local administrators on all Microsoft Entra joined devices" link is a separate, tenant-wide mechanism (the same Device Administrator role) — it can't be scoped to specific devices, which is also worth knowing if you're trying to limit blast radius. If you want to stop this going forward for new joins without ripping out existing admins, set "Registering user is added as local administrator" to None, and consider a Windows Autopilot profile or Intune Local Users and Groups policy to manage membership going forward — existing devices won't be retroactively changed.Remediation Workflow Automation — Biggest Gap vs. Competing Exposure Management Platforms?
Exposure graph and attack path correlation in MSEM are genuinely strong — the cross-domain visibility (endpoints, identities, cloud, external surface) is one of the better implementations I've worked with, especially for shops already standardized on the Microsoft stack. The gap I keep running into is closed-loop remediation orchestration. Right now, when an attack path or critical exposure is identified, there's no native way to auto-generate a ticket, assign ownership, and track an SLA against it — that handoff still has to be built externally (Logic Apps, Sentinel playbooks, or a 3rd-party ITSM integration). This isn't just my experience; it's echoed in published Gartner Peer Insights reviews of the product, where users specifically flag the absence of in-platform workflows to raise tickets automatically and route them to the owning team. For comparison, Qualys built this natively into their Enterprise TruRisk Platform (QFlow) — automatic ticket creation in ServiceNow/Jira, ownership assignment, and SLA tracking, all without manual handoffs. Tenable One markets "workflow automation" as a core differentiator of its unified platform for the same reason: it's what turns continuous detection into continuous risk reduction, not just a better dashboard. Questions for the team / community: Is closed-loop ticketing/SLA tracking on the roadmap natively, or is the expectation that this stays external (Logic Apps/Sentinel)? For those running MSEM at scale — how are you currently bridging this gap operationally? Custom playbooks, or a 3rd-party orchestration layer on top?
Microsoft Defender (GCC) - User Submitted "Mark and Notify" for Third Party Phishing Simulations
Our Microsoft 365 tenant is in the GCC environment, and we use a third party phishing simulation platform along with the built in Outlook Report Message button (not a third party reporting add in). When a user correctly reports one of our simulated phishing emails, the message appears in Microsoft Defender > User Submitted as expected. The problem is what happens next. When we select Mark and notify, the only available options are: Phishing Spam No threat found There is no option to notify the user that the email was actually part of a phishing simulation. This creates a difficult situation: If we choose No threat found, Defender tells the user the message was safe, making it appear they incorrectly reported the email even though they did exactly what we trained them to do. If we choose Phishing, the user receives the correct feedback, but the message is counted as a real phishing event, affecting our Defender metrics and potentially generating false incidents and reporting. It feels like we're stuck in a design loop where neither option provides the desired outcome. My questions are: Is there a supported way in Microsoft Defender (particularly GCC) to notify users that a reported message was a simulated phishing email when using the native Outlook Report Message button? Is this capability available in Commercial tenants but not GCC, or is it unavailable across all environments? If this functionality does not exist, what is the recommended process for submitting a feature request specifically for the GCC version of Microsoft Defender? This seems like a valuable enhancement for organizations that use third party phishing simulation platforms while relying on Microsoft's native reporting experience. Has anyone else found a good workflow for this scenario?Microsoft Purview Unified Catalog; Governance Domains and Business Concepts
I've been using the attached artefacts for some time to help explain the knowledge exchange aspects of Microsoft Purview Unified Catalog, particularly how Governance Domains and Business Concepts work together to provide business context, ownership, stewardship and operational insights. They have been useful in workshops with data architects, governance professionals, product owners and business stakeholders to demonstrate how concepts fit together within a governance domain and contribute towards trusted information and better business outcomes. I'm interested in hearing from the wider Purview community: Do these artefacts accurately represent the intent and capabilities of Governance Domains within Microsoft Purview? Are there any concepts that you feel are missing, over-emphasised, or could be represented more clearly? How are others explaining Governance Domains and Business Concepts to non-technical stakeholders? Any feedback, suggestions, or alternative approaches would be greatly appreciated. I'm always looking to refine these materials and make them more useful for organisations adopting Purview Unified Catalog. #MicrosoftPurview #DataGovernance #DataManagement #Metadata #DataProducts #MicrosoftData #Purview #DataArchitecture #UnifiedCatalogConfusion around Purview Definitions and Risk Scoring
In the early days of implementation and we've done our 'Quick setup' of Insider Risk Management which created our Adaptive Protection Policy for IRM, two IRM DLP policies (Endpoint & Teams/Exchange) and the Conditional Access policy. My question is around 'Triggering events', Indicators and Insider Risk Levels. To my understanding, a triggering event is the event that decides when the policy will start assigning risk scores to user activity which will then allow us to then give users risk levels. We have the option to either set this triggering event to either the DLP policies, or when a user performs an exfiltration activity/ sequence. The DLP policies only match activity when a user has a defined risk level and attempts to perform a specific activity i.e. sharing M365 with people outside the organisation. I'm not sure if I'm thinking about this backwards, but if I set my Adaptive protection policy to only start assigning risk scores to user activity when they match a DLP policy, how can they trigger a DLP policy if they wont be assigned a risk level until that scoring begins to happen? Should I be setting my triggering events to be "User performs an Exfiltration Activity" instead of "User Matches a DLP policy"?
Events
in 18 hours
As organizations scale, tenant sprawl becomes inevitable. Legacy test tenants, employee‑created environments, and forgotten tenants create blind spots for security and identity teams.
Get to know M...
Online
Learn more about attack disruption—Microsoft Defender’s built‑in, AI-powered capability that stops in‑progress attacks at machine speed by analyzing attacker intent, identifying compromised assets, ...
Online