This was my preparation for the exam Microsoft Certified: Cybersecurity Architect Expert (SC-100)!
Dear Microsoft 365 Security and Azure Security Friends, When I first read about this certification I was immediately excited! But at the same time I had a lot of respect, because it is an expert certification. I quickly started collecting information. The first thing I learned was that it takes a so-called prerequisite exam to become a Microsoft Certified: Cybersecurity Architect Expert certification. The following prerequisite exams are available (only one of these exams must be passed): Microsoft Certified: Security Operations Analyst Associate (SC-200) https://docs.microsoft.com/en-us/learn/certifications/security-operations-analyst/ Microsoft Certified: Identity and Access Administrator Associate (SC-300) https://docs.microsoft.com/en-us/learn/certifications/identity-and-access-administrator/ Microsoft Certified: Azure Security Engineer Associate (AZ-500) https://docs.microsoft.com/en-us/learn/certifications/azure-security-engineer/ Microsoft 365 Certified: Security Administrator Associate (MS-500) https://docs.microsoft.com/en-us/learn/certifications/m365-security-administrator/ I have taken all these prerequisite exams. The two exams AZ-500 and MS-500 helped me the most in preparing for the SC-100 (this is certainly not the case for everyone). In this SC-100 exam you will be quizzed on topics in Microsoft Sentinel, Microsoft Defender for Cloud, Microsoft 365 Defender for Cloud Apps (and all other Defender products), Azure Policy, Azure landing zone, etc. This spectrum is huge, please take enough time to "explore" these "portals" deeply. You don't have to have the technical knowledge down to the last detail. No not at all, in this exam it is important to use all the features and products with the right strategy. This was among other things my way to success! Now to my preparations for the exam: 1. First of all, I looked at the Exam Topics to get a first impression of the scope of topics. https://docs.microsoft.com/en-us/learn/certifications/cybersecurity-architect-expert/ Please take a close look at the skills assessed: https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWVbXN 2. So that I can prepare for an exam I need an Azure test environment (this is indispensable for me). You can sign up for a free trial here. https://azure.microsoft.com/en-us/free/ Next, I set up a Microsoft 365 test environment. You can sign up for a free trial here. https://www.microsoft.com/en-us/microsoft-365/business/compare-all-microsoft-365-business-products I chose the "Microsoft 365 Business Premium" plan for my testing. I have also registered several free trials to test the various Defender products. 3. Now it goes to the Microsoft Learn content. These learn paths (as you can see below, all 4) I have worked through completely and "mapped"/reconfigured as much as possible in my test environment. https://docs.microsoft.com/en-us/learn/paths/sc-100-design-zero-trust-strategy-architecture/ https://docs.microsoft.com/en-us/learn/paths/sc-100-evaluate-governance-risk-compliance/ https://docs.microsoft.com/en-us/learn/paths/sc-100-design-security-for-infrastructure/ https://docs.microsoft.com/en-us/learn/paths/sc-100-design-strategy-for-data-applications/ 4. Register for the exam early. This creates some pressure and you stay motivated. https://docs.microsoft.com/en-us/learn/certifications/cybersecurity-architect-expert/ 5. Please also watch the video of John Savill, it is very helpful! https://youtu.be/2Qu5gQjNQh4 6. The Exam Ref for the SC-200 exam was also very supportive. https://www.microsoftpressstore.com/store/exam-ref-sc-200-microsoft-security-operations-analyst-9780137666720 7. Further I have summarized various links that have also helped me a lot. Sorted by Functional Group. Design a Zero Trust strategy and architecture: https://docs.microsoft.com/en-us/security/cybersecurity-reference-architecture/mcra https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/secure/security-governance https://docs.microsoft.com/en-us/azure/architecture/framework/security/monitor-audit https://docs.microsoft.com/en-us/security/benchmark/azure/security-control-logging-monitoring https://docs.microsoft.com/en-us/azure/security/fundamentals/log-audit https://docs.microsoft.com/en-us/azure/architecture/framework/security/design-network-connectivity https://docs.microsoft.com/en-us/azure/architecture/framework/security/design-network-segmentation https://docs.microsoft.com/en-us/security/zero-trust/deploy/infrastructure https://docs.microsoft.com/en-us/security/zero-trust/integrate/infrastructure https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/strategy/define-security-strategy https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/secure/business-resilience https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/strategy/technical-considerations/ https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/organize/ https://docs.microsoft.com/en-us/azure/security/fundamentals/operational-checklist https://azure.microsoft.com/en-us/services/defender-for-cloud/#features https://docs.microsoft.com/en-us/azure/sentinel/overview https://docs.microsoft.com/en-us/azure/defender-for-cloud/workflow-automation https://docs.microsoft.com/en-us/security/compass/incident-response-overview https://docs.microsoft.com/en-us/security/compass/incident-response-planning https://docs.microsoft.com/en-us/security/compass/incident-response-process https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/secure/security-operations https://docs.microsoft.com/en-us/security/compass/security-operations https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-setup-guide/organize-resources https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-setup-guide/manage-access https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices https://docs.microsoft.com/en-us/azure/active-directory/external-identities/external-identities-overview https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-methods https://docs.microsoft.com/en-us/microsoft-365/education/deploy/design-credential-authentication-strategies https://docs.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn https://docs.microsoft.com/en-us/azure/architecture/framework/security/design-identity-authentication https://docs.microsoft.com/en-us/azure/architecture/framework/security/design-identity-authorization https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/plan-conditional-access https://docs.microsoft.com/en-us/azure/architecture/guide/security/conditional-access-zero-trust https://docs.microsoft.com/en-us/azure/active-directory/roles/best-practices https://docs.microsoft.com/en-us/azure/active-directory/governance/entitlement-management-delegate https://docs.microsoft.com/en-us/azure/active-directory/roles/groups-concept https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure https://docs.microsoft.com/en-us/security/compass/identity https://docs.microsoft.com/en-us/azure/active-directory/governance/entitlement-management-overview https://docs.microsoft.com/en-us/azure/active-directory/governance/entitlement-management-delegate https://docs.microsoft.com/en-us/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services https://docs.microsoft.com/en-us/microsoft-identity-manager/pam/principles-of-operation https://docs.microsoft.com/en-us/azure/active-directory/roles/security-planning Evaluate Governance Risk Compliance (GRC) technical strategies and security operations strategies: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/govern/policy-compliance/regulatory-compliance https://docs.microsoft.com/en-us/azure/security/fundamentals/technical-capabilities https://docs.microsoft.com/en-us/security/compass/governance https://docs.microsoft.com/en-us/azure/defender-for-cloud/regulatory-compliance-dashboard https://docs.microsoft.com/en-us/microsoft-365/compliance/compliance-manager?view=o365-worldwide https://docs.microsoft.com/en-us/microsoft-365/compliance/compliance-score-calculation?view=o365-worldwide https://docs.microsoft.com/en-us/azure/defender-for-cloud/secure-score-security-controls https://docs.microsoft.com/en-us/azure/governance/policy/overview https://docs.microsoft.com/en-us/azure/governance/policy/tutorials/create-and-manage https://azure.microsoft.com/en-us/global-infrastructure/data-residency/ https://azure.microsoft.com/en-us/resources/achieving-compliant-data-residency-and-security-with-azure/ https://azure.microsoft.com/en-us/overview/trusted-cloud/privacy/ https://azure.microsoft.com/en-us/blog/10-recommendations-for-cloud-privacy-and-security-with-ponemon-research/ https://docs.microsoft.com/en-us/security/benchmark/azure/introduction https://docs.microsoft.com/en-us/azure/defender-for-cloud/update-regulatory-compliance-packages https://docs.microsoft.com/en-us/azure/defender-for-cloud/regulatory-compliance-dashboard https://docs.microsoft.com/en-us/azure/defender-for-cloud/secure-score-access-and-track https://docs.microsoft.com/en-us/azure/defender-for-cloud/enhanced-security-features-overview https://docs.microsoft.com/en-us/azure/architecture/framework/security/design-governance-landing-zone https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/considerations/landing-zone-security https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/security https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/office-365-ti?view=o365-worldwide https://docs.microsoft.com/en-us/microsoft-365/compliance/insider-risk-management?view=o365-worldwide https://techcommunity.microsoft.com/t5/security-compliance-and-identity/reduce-risk-across-your-environments-with-the-latest-threat-and/ba-p/2902691 Design security for infrastructure: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-security-configuration-framework/windows-security-baselines https://docs.microsoft.com/en-us/windows-server/security/security-and-assurance https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/minimum-requirements?view=o365-worldwide https://docs.microsoft.com/en-us/mem/intune/protect/security-baselines https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory https://docs.microsoft.com/en-us/azure/active-directory-domain-services/secure-your-domain https://docs.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates https://docs.microsoft.com/en-us/azure/security/fundamentals/management https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/cloud-services-security-baseline https://azure.microsoft.com/en-us/overview/iot/security/ https://docs.microsoft.com/en-us/azure/azure-sql/database/security-overview?view=azuresql https://docs.microsoft.com/en-us/azure/azure-sql/database/security-best-practice?view=azuresql https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/sql-database-security-baseline https://docs.microsoft.com/en-us/azure/cosmos-db/database-security?tabs=sql-api https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/synapse-analytics-security-baseline https://docs.microsoft.com/en-us/azure/app-service/overview-security https://docs.microsoft.com/en-us/azure/app-service/security-recommendations https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/app-service-security-baseline https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/storage-security-baseline https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/container-instances-security-baseline https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/container-registry-security-baseline https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/aks-security-baseline https://docs.microsoft.com/en-us/azure/aks/concepts-security https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-cluster-security?tabs=azure-cli https://docs.microsoft.com/en-us/azure/architecture/framework/services/compute/azure-kubernetes-service/azure-kubernetes-service Design a strategy for data and applications: https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-mitigations https://docs.microsoft.com/en-us/azure/architecture/framework/security/design-threat-model https://docs.microsoft.com/en-us/compliance/assurance/assurance-security-development-and-operation https://docs.microsoft.com/en-us/azure/security/develop/secure-design https://docs.microsoft.com/en-us/azure/defender-for-cloud/defender-for-app-service-introduction https://docs.microsoft.com/en-us/azure/architecture/framework/security/resilience https://docs.microsoft.com/en-us/security/benchmark/azure/security-controls-v3-governance-strategy https://docs.microsoft.com/en-us/azure/architecture/data-guide/scenarios/securing-data-solutions https://docs.microsoft.com/en-us/azure/architecture/framework/security/design-storage https://docs.microsoft.com/en-us/security/benchmark/azure/security-controls-v3-data-protection https://docs.microsoft.com/en-us/azure/security/fundamentals/encryption-overview https://docs.microsoft.com/en-us/azure/security/fundamentals/data-encryption-best-practices https://docs.microsoft.com/en-us/azure/security/fundamentals/encryption-atrest https://docs.microsoft.com/en-us/azure/architecture/framework/security/design-storage-encryption 8. You can find a list of all the links here: https://github.com/tomwechsler/Microsoft_Cloud_Security/blob/main/SC-100/Links.md I know you've probably read and heard this many times: read the exam questions slowly and accurately. Well, that was the key to success for me. It's the details that make the difference between success and failure. Let me give you an example at this point. You want to make a business app available. The authentication should be done by each person with his own LinkedIn account. Which variant of Azure Active Directory do you use for this? At this point you should know the different types of Azure Active Directory. One final tip: When you have learned something new, try to explain what you have learned to another person (whether or not they know your subject). If you can explain it in your own words, you understand the subject. That is exactly how I do it, except that I do not explain it to another person, but record a video for YouTube! I hope this information helps you and that you successfully pass the exam. I wish you success! Kind regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechslerUpcoming Webinar Series: ITDR
Update: the recordings of the webinar series ITDR can be found here, please scroll down to "MICROSOFT DEFENDER XDR" The Microsoft POC as a Service (POCaaS) Program is a unique service available to our customers to help evaluate and try out our security offerings, we deliver these on a regular basis to customers around the world. They provide a fully managed test environment where customers can get hands-on experience with some of our core security products. Namely, Microsoft Defender for Identity, Defender for Endpoint, Defender for Cloud Apps, Defender for Office 365, and Sentinel. In addition to the hands on elements of the service one of our subject matter experts delivers a deep dive workshop for the relevant service showcasing its end to end capability and providing full education on the product. With this, we are thrilled to announce a new webinar series where we will take the workshop materials from each of our POCaaS programs, share best practices and provide education on each of the products we cover. What to Expect The webinar series will take the educational content from our POC offerings and condense into multipart 1 hour webinars. We will start with a four-part webinar series with Chris Ayres to guide you through ITDR, Identity Threat Detection and Response. Session 1: ITDR Introduction and Prevention Capabilities | April 23, 09:00 AM PST Hear Microsoft's Incident Detection and Response (ITDR) story and understand its critical role in today's dynamic threat landscape. Explore the significance of prevention and adaptive controls. Session 2: Detection | April 24, 09:00 AM PST Discuss the imperative need for robust detection capabilities against advanced identity attacks, whether identities reside on-premises, in hybrid environments, or in the cloud, and discover the comprehensive solutions Microsoft offers to safeguard your entire identity estate effectively. Session 3: Investigation and Hunting | April 30, 09:00 AM PST Learn to empower your SOC with deep visibility into identity entities, context, and telemetry and understand how this capability streamlines efficient investigation and incident triage. Session 4: Response | May 1, 09:00 AM PST Gain insights into native response capabilities seamlessly integrated into the SOC workflow. Learn how to leverage them to effectively respond to identity-related attacks and remediate issues within your environment. We will finish off with a short view on how you can best evaluate the products. Save the Date Reserve your spot for any session or the entire series on the Microsoft Security webinars page: Microsoft Sentinel & Defender XDR Security Public Webinars Don't miss this opportunity to learn directly from our experts and have your questions addressed. We look forward to your participation!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.Achieve higher security with certificate bindings - How it works!
Dear Microsoft Entra friends, In this article I would like to take a closer look at the subject of certificate affinity binding. So that even more security can be applied during authentication. Let's start with a few links to the Microsoft documentation pages. Overview of Microsoft Entra certificate-based authentication: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication How to configure Microsoft Entra certificate-based authentication: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-certificate-based-authentication Microsoft Entra certificate-based authentication technical deep dive: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication-technical-deep-dive What does it mean "Achieve higher security with certificate bindings"? Microsoft Entra ID, formerly known as Azure Active Directory, is a cloud identity and access management solution that controls application access and protects identities. The term “Achieve higher security with certificate bindings” refers to a feature of Microsoft Entra ID that enhances user authentication security. This feature is part of the certificate-based authentication (CBA) process. Certificate bindings refer to the methods used to bind a certificate to a user’s identity, enhancing the security of the authentication process. There are seven supported methods for certificate bindings. These methods are considered high-affinity if they’re based on identifiers that can’t be reused, such as Subject Key Identifiers or SHA1 Public Key. This way, Microsoft Entra ID provides a secure and efficient way for users to authenticate and access applications. Let's examine achieve higher security with certificate bindings. Object Identifiers (OID): First we look at the certificate template on the certificate server (sorry some print screens are in German). Here we see the details of the Object Identifiers (OID). Add a new rule: Configure an additional rule in the Entra ID Admin Center and use the same Object Identifiers (OID) value here as in the certificate template. Subject Key Identifier (SKID): The certificate was issued on the user's system. We obtain the subject key identifier (SKID) from this certificate. We need this value in the Entra ID Admin Center to assign it to a person. The same person for whom the certificate was issued on the system (in my case it is Tina Fluenza). Authorization info: In the Entra ID Admin Center, we now set the value of the Subject Key Identifier (SKID) for the user in the properties. Note: Please pay attention to the syntax (X509:\<SKI\>a8052e8485eb17d865ba5d5ff0f7b326234f2860) Entra ID Sign-In Logs: "Tina Fluenza" has now registered on the portal https://myapps.microsoft.com and selected the certificate during the application process. This information can be found in the Entra ID Admin Center in the sign-in logs. With the confirmation of MFA by the claim in the token. HAPPY BINDING! I hope this information was helpful to you. I would like to thank you for your interest and for taking the time to read the article. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on GitHub! https://github.com/tomwechslerProtect your identities from a Token theft using Token Protection in Conditional Access
In this blog post, I will show you the steps required to enable the Token Protection feature using Conditional Access in Entra ID. Along with a brief simulation of the Token Theft and how Token protection will prevent the attacker from stealing the token. https://www.linkedin.com/pulse/protect-your-identities-from-token-theft-using-access-elie-karkafy
