Forum Widgets
Latest Discussions
BlackHat Community Interest Survey
Hey all! We’re planning Microsoft Security community circles, meetups, and AMA sessions during Black Hat week and would love your input on the topics and conversations most valuable to you. Please help us by filling out this form with your opinions (NO PERSONAL DATA COLLECTED): https://forms.cloud.microsoft/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR11eh_DyBlNCr6Pu5FQsI9ZUN1VQWTRDOTRZUVpQNEFLR05HMkg2RkFRTi4u Thank you!
Windows Hello passkeys dialog appearing and cannot remove or suppress it.
Hi everyone, I’m dealing with a persistent Windows Hello and passkey issue in Chrome and Brave and yes this is relevant as they're the only browsers having this issue whilst Edge for example is fine, and at this point I’m trying to understand whether this is expected behavior, a bug, or a design oversight. PS. Yes, I'm in contact with related browser support teams but since they seem utterly hopeless i'm asking here, since its at least partially Windows Hello issue. Problem description Even with: Password managers disabled in browser settings, Windows Hello disabled in Chrome/Brave settings, Windows Hello PIN enabled only for device login, Passkeys still stored under chrome://settings/passkeys (which I cannot delete since its used for logging on the device), The devices are connected to Entra ID but this is not required to reproduce the issue although a buisness account configuration creates a Passkey with Windows Hello afaik. Observed behavior When I attempt to sign in on office.com, Windows Hello automatically triggers a dialog offering authentication via passkeys, even though: I don’t want passkeys used for browser logins, passkeys are turned off everywhere they can be, Windows Hello is intended only for local device authentication. The dialog cannot be suppressed, disabled, or hidden(trust me, i tried for weeks). It effectively forces the Windows Hello prompt as a primary option, which causes problems both personally and in business contexts (wrong credential signaling, misleading users that are supposed to use a dedicated password manager solution insted of browser password managers, enforcing an unwanted authentication flow, etc.). What I already verified Many, many, (too many) Windows registry workarounds that never worked. Dug through almost all flags on those browsers. Chrome/Brave → Password Manager: disabled Chrome/Brave → Windows Hello toggle: off Looked through what feels like almost every related option in Windows Settings. Tried gpedit.msc local rules System up to date Windows Hello configured to use PIN, but stores "passkeys used to log on to this device" Why this is a problem Windows Hello automatically assumes that the device-level Windows Hello credentials should always be available as a WebAuthn authenticator. This feels like a big security and UX issue due to: unexpected authentication dialogs, Inability to controll where and how passkey credential are shared to applications, inability to turn the feature off, no administrative or local option to disable Hello for WebAuthn separately from device login. Buisness users either having issues with keeping passwords in order (our buissnes uses a dedicated Password Manager but this behaviour covers its dialog option) or not having PIN to their devices (when I disable windows hello entierly, since when there is no passkeys the option doesn't appear) Questions Is there any supported way to disable Windows Hello as a WebAuthn/passkey option in browsers, while keeping Hello enabled for local device login? Is this expected behavior from the Windows Hello, or is it considered a bug? Are there registry/policy settings (documented or upcoming) that allow disabling the Windows platform authenticator specifically for browsers like Chrome and Brave? Is Microsoft aware of this issue? If so, is it tracked anywhere? Additional notes This issue replicates 100% across (as long as there are passkeys configured): Windows 11 devices i've managed to get my hands on, Chrome and Brave (latest versions), multiple Microsoft accounts and tenants, multiple clean installations. Any guidance or clarification from the Windows security or identity teams would be greatly appreciated. And honestly if there is any more info i could possibly provide PLEASE ask away.
Critical identities in the Agent 365 era
From identity governance to execution control in the age of AI agents As organizations accelerate AI adoption, a fundamental shift is taking place in enterprise security: Identity is no longer just about access it is becoming the control plane. What started with user identities evolved into application and workload identities. Now, with AI agents entering the enterprise, we are entering a new phase: Every actor human, application or AI agent must be governed through identity. Why identity needs to evolve AI agents are no longer passive tools. They: Access enterprise data Trigger workflows Interact across systems Act autonomously This introduces a new reality: Security is no longer about who can log in It is about what is being executed, by which identity, in which context Introducing critical identities To address this, identity must evolve into a unified model: Critical identities = Human + Non-human + Agent identities Human identities — Employees, partners Non-human identities (NHIs) — Workloads, APIs, service principals Agent identities — AI agents powered by Entra Agent ID The next shift: a new identity plane Beyond users and applications, we now have: A third identity plane : Agent identities This identity type: Operates in its own execution context Acts autonomously Requires continuous governance Identity is no longer static It becomes contextual, behavioral and execution-driven The first principle: Converged identity is non-negotiable You cannot secure AI without converged identity This is not a priority. This is a prerequisite. Organizations must move from fragmented identity silos to: One unified identity fabric across all actors Where: Every identity is governed Every permission is controlled Every action is attributable Converged identity becomes the foundation of the agentic enterprise The next principle: AI SOC is no longer optional Your SOC must operate at machine speed not human speed This is not modernization. This is survival in an AI-led environment. In an AI-driven world: Events are continuous Signals increase exponentially Actions are autonomous SOC must evolve to: AI-powered, identity-aware and automation-driven operations Without it: Threats outpace detection Agents execute unnoticed Security becomes reactive AI SOC is not an enhancement it is the new operating model The next principle: Data security becomes the first line of defense Data not infrastructure is the primary risk surface AI agents: Aggregate enterprise data Generate new outputs Share insights dynamically Organizations must shift to: Protecting data in interaction not just at rest Without it: Sensitive data is exposed Agents amplify over-permissioned access Compliance breaks silently AI without data security is exposure not innovation The next principle: Agent 365 is the control plane for agents Agents must be governed as identities, not treated as background components Without governance: ❌ No visibility ❌ No ownership ❌ No lifecycle control Agent 365 delivers: Agent Registry → complete visibility Entra Agent ID → identity foundation Policy enforcement → Conditional Access + least privilege Lifecycle governance → full control Observability → execution tracking Without this: Agents act without accountability & Introducing Agent Inventory One view across identity, execution and control As AI scales, the challenge is no longer deployment: It is visibility into how identities behave Why Agent Inventory matters Traditional IAM answers: Who has access But now the real question is: Which identity is executing what, in which context, under which policy? What Agent Inventory surfaces Blueprints → Identity design layer Agent identities → Execution entities Agent users → Context (on-behalf-of) Orphan risk → Governance gaps Credential expiry → Identity hygiene Privilege gap analysis → Behavior vs access Registry gaps → Missing control plane coverage Action queue → Prioritized remediation Relationship graph → Identity + execution mapping What’s fundamentally new Traditional IAM Agentic IAM Identity = access Identity = execution control Static roles Context-aware permissions Identity lists Identity graphs Periodic review Continuous monitoring Bringing it all together When you step back and connect these capabilities, a clear pattern emerges. Identity becomes the foundation that governs every actor human, workload and agent while AI-powered SOC ensures detection and response can operate at the speed of execution. Data security establishes the guardrails, protecting what truly matters as agents interact with enterprise information. On top of this, Agent 365 provides the control plane bringing visibility, governance, and lifecycle management to every AI agent in the environment. And finally, Agent Inventory completes the picture by making identity and execution observable, helping organizations understand not just what exists, but how it behaves. Together, these layers form a cohesive model one that enables organizations to move from fragmented security to a unified, identity-driven approach that is ready for the realities of the agentic enterprise. We are entering a new paradigm: Humans define intent Applications execute logic Agents drive autonomous actions And all of it is governed by identity. So, You can’t govern agents without understanding their identity. You can’t secure identity without understanding execution. Critical identities + Agent 365 + Agent Inventory establish the control plane for the agentic enterprise.Microsoft Sovereignty 2026: From Data Residency to Digital Control
Over the past few years, data sovereignty has evolved from a compliance checkbox to a board-level priority. What began as a discussion around where data is stored has now expanded to who controls it, who operates it and under which jurisdiction it is governed. As we move into 2026, Microsoft Sovereignty is no longer just a roadmap, it is actively shaping how enterprises design cloud and AI architectures, especially across regulated industries. Why Sovereignty Matters More Than Ever Organizations today are navigating a complex landscape: Increasing regulatory mandates (GDPR, NIS2, DORA) Rising geopolitical concerns around cross-border data access Accelerated adoption of AI, copilots, and agentic systems But what’s changing in 2026 is the scale of AI adoption: 1.3B AI agents expected by 2028 82% of organizations plan to integrate AI agents within 1–3 years 90% of developers will use AI-assisted coding tools This fundamentally shifts the sovereignty discussion: It’s no longer about protecting data, it’s about governing AI-driven decisions and automation. Sovereignty in the Age of AI Agents A critical insight emerging from the field: Not all AI workloads can run in public cloud environments. Some AI scenarios require sovereignty by design, especially when: Data must remain within national jurisdiction Operational access must be restricted Systems must continue functioning during disconnection or crisis Examples include: Government AI copilots for citizen services Defense systems requiring air-gapped AI Financial services with strict regulatory oversight Healthcare workloads with sensitive patient data AI strategies must now survive regulation, disruption and disconnection not just scale. Microsoft Sovereignty: A Multi-Layered Approach Microsoft’s approach to sovereignty is not a single feature it’s a comprehensive framework spanning infrastructure, operations, security and AI. At its core, Microsoft Sovereign Cloud introduces three key deployment models: 1. Sovereign Public Cloud Regional data boundaries and in-country processing Built-in sovereign controls at hyperscale AI model choice with localized processing 2. Sovereign Private Cloud (AI-Driven Evolution) This is where sovereignty is evolving the fastest in 2026. Runs on Azure Local + Microsoft 365 Local + Foundry Local Enables continuous operations in hybrid or disconnected environments Supports AI workloads with local inferencing and GPU acceleration This is no longer traditional on-prem it is cloud-grade AI deployed locally. 3. National Partner Clouds Operated by local entities Meets country-specific certifications Bridges global cloud and national regulations Sovereign AI: From Data Control to Full Lifecycle Control The biggest shift in 2026: Sovereignty is no longer just about data it’s about the entire AI lifecycle. Sovereign AI ensures: Data stays local and under customer authority AI systems operate even without connectivity Customers control model selection (proprietary, OSS or custom) This introduces a new dimension: Model Sovereignty + Operational Sovereignty + Infrastructure Sovereignty The Rise of Foundry Local: AI From Cloud to Edge One of the most important innovations enabling this shift is Microsoft Foundry Local. Foundry Local extends AI capabilities across: Cloud Edge devices On-premises environments Fully disconnected deployments This allows organizations to: Run models locally using containers Use Arc-enabled Kubernetes for deployment Maintain consistent governance across environments AI Models Under Sovereign Control Microsoft enables multiple AI model strategies: Models-as-a-Platform (MaaP) → Customer-managed Models-as-a-Service (MaaS) → Microsoft-managed BYO Models → Full flexibility (Open-source or proprietary) This means enterprises can shift from: ❌ Vendor-dependent AI ✅ Sovereign, customer-controlled AI ecosystems Sovereign AI Deployment Patterns Two dominant patterns are emerging: 1. Hybrid Sovereign AI Develop in cloud Deploy to edge or sovereign environments Maintain flexibility 2. Fully Disconnected AI Air-gapped environments No dependency on cloud connectivity Full local processing and inference This is critical for defense, public sector and critical infrastructure. The Reality Check: What Enterprises Must Still Own While Microsoft provides the platform, sovereignty is not “set and forget.” Organizations must still: Design region-first and sovereignty-aware architectures Implement governance across hybrid and disconnected environments Manage model lifecycle and inferencing policies locally Ensure compliance with evolving regulatory frameworks Sovereignty is now an architecture decision not just a cloud feature. My Perspective (Field Insight) From working with regulated customers (BFSI, telecom, public sector), I see three clear patterns: 1. Sovereignty is now directly tied to AI adoption → Customers will not scale GenAI without sovereign guarantees 2. Hybrid + Sovereign AI is becoming the default architecture → Cloud-only strategies are no longer sufficient 3. Control of models and inferencing is the new trust boundary → Trust is shifting from infrastructure to AI execution layers Final Thoughts: Sovereignty as an AI Enabler The narrative around sovereignty is shifting: ❌ Earlier: “Sovereignty restricts innovation” ✅ Now: “Sovereignty enables trusted AI at scale” Microsoft’s Sovereign Cloud strategy reflects this evolution bringing together: Cloud-scale capabilities Local control and resilience AI lifecycle governance The opportunity ahead is clear: Design sovereign-by-default AI architectures that are secure, compliant and built for resilience whether connected, hybrid or fully disconnected.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.
Defender Threat & Vulnerability Management Reporting
Hello, we're looking at implementing DTVM for our endpoints, but are curious about reporting. Is there a way we can get these reports in a PDF format, and scoped to specific devices only? I'd like to use the evidence paths gathered from KQL to help build the reports. Are there any guides or steps out there that shows how we can do this with tools like PowerBI? Thanks in advance.
BIT LOCKER RECOVERY
Greetings everyone, Recently Microsoft Windows forced into entering an update upon closing my laptop. After that I could not boot up without being asked to enter a Bit Locker Recovery key.I eventually found the correct key and entered it this morning successfully.Laptop was up and running ok or so I thought.Switched the laptop on just now and low and behold I have to put the Recovery key in again.!!I gather the problem arrived during the last update.I s there a fix for this or am I now having to put the key in every single time I switch the laptop on!! Is it possible to remove the faulty update? Many thanks for any help received Dave1950
Unsanctioned cloud apps generates constant alerts
When I mark a cloud app as unsanctioned it created a URL based indicator to block the site. However, it also by default enables the Generate Alert option on the indictor. This causes my SOC to bet inundated with garbage alerts. Now normally if I'm just unsanctioning one Cloud App a could go and turn of the alert. However, I use cloud app policy that will identify any new Cloud Apps in an entire category and then unsanction it. But it enables Generate Alert on the URL indicator. Then if someone accesses that new one the generate alert kicks off. I don't want to have to go into every new app and untick generate alert manually that's just too time consuming. Is there a way to change the default behaviour when adding an indicator to not enable the generate alert? Of is there some other way to do this? I could consider using power automate or something but I'd rather the default behaviour be the fix as automation can break. I don't have time to babysit it.
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.
