Platform SSO for macOS
Introduction As organizations accelerate their journey to passwordless authentication, Microsoft’s Platform SSO for macOS offers a seamless, secure, and user-friendly experience for device and application sign-in. Built on Apple’s SSO framework and tightly integrated with Microsoft Entra ID, Platform SSO empowers users to leverage modern authentication methods Touch ID, smart cards, and passkeys across their macOS devices, enterprise apps, and browsers. In this blog, we’ll walk through the essentials of Platform SSO, supported authentication methods, configuration steps, and best practices for deployment in enterprise environments. What is Platform SSO for macOS? Platform SSO is a Microsoft feature for macOS (13+) that leverages Apple’s SSO framework to enable single sign-on using Entra ID credentials. Users benefit from passwordless authentication, enhanced security, and a consistent experience whether logging into their device, enterprise applications, or web browsers. Key highlights: Passwordless sign-in: Use Touch ID (Secure Enclave), smart cards, or passwords for device and app authentication. Enterprise SSO plug-in: Activated for both application and browser-based sign-in, ensuring centralized identity management. No agent required: Utilizes built-in macOS platform capabilities for easy deployment and management. Authentication Methods Supported by Platform SSO Platform SSO supports three primary authentication methods on macOS: Feature Secure Enclave Smart Card Password Passwordless (phishing resistant) ✅ ✅ ❌ Touch ID supported for unlock ✅ ✅ ✅ Can be used as passkey ✅ ❌ ❌ Local Mac password synced with Entra ID ❌ ❌ ✅ Supported on macOS 14.x+ ✅ ✅ ✅ MFA mandatory for setup ✅ ✅ ❌ Secure Enclave: Recommended for most users, Secure Enclave uses hardware-bound cryptographic keys for app and web sign-ins, enabling passwordless and phishing-resistant MFA. After a reboot, users enter their local password once, then Touch ID can be used for subsequent unlocks. The device receives a hardware-backed Primary Refresh Token (PRT) for device-wide SSO. Smart Card: Ideal for high-security or compliance-driven environments, Smart Card authentication provides complete passwordless sign-in and unlock. After sign-in, the device receives a PRT and Workplace Join (WPJ) certificate for seamless SSO to Microsoft 365, Safari, and Entra-protected apps. Password: Users sign in with their Entra ID password, which syncs to the local account for SSO across apps. Intune password policies ensure alignment with Entra ID password rules, preventing sync or sign-in issues. How Platform SSO Works When a Mac device joins a Microsoft Entra ID tenant, it receives a hardware-bound WPJ certificate accessible only by the Microsoft Enterprise SSO plug-in. Apps and browsers require this certificate to access resources protected by Conditional Access policies. Platform SSO is configured using the Intune settings catalog and should ideally be assigned at device enrollment, but can also be applied to existing devices. Deployment Steps Device Enrollment in Intune: Organization-owned devices use Apple Business Manager or Apple Configurator; personally-owned devices enroll via Company Portal. Prerequisites: macOS 13+, Intune Company Portal app v5.2404.0+, supported browsers (Edge, Chrome with SSO extension, Safari), Intune RBAC permissions. Create Platform SSO Policy in Intune: Enable Platform SSO, select authentication method (Secure Enclave, Password, Smart Card), assign to user groups. Define Policies in Platform SSO Settings: Assign to users or groups with user affinity; avoid assigning to device groups to prevent Conditional Access issues. Enable MDM Push Certificate: Required for macOS enrollment in Intune. Deploy Company Portal App: Via Intune or manually from https://aka.ms/EnrollMyMac. Enroll Device and Validate Profiles: Sign in to Company Portal with Entra ID credentials and confirm device management profile. Customizing the macOS Login Experience Platform SSO allows administrators to push Login Window Text and Show Full Name settings from Intune, enabling a personalized and informative login experience for users. These settings help display the user’s full name and custom messages during sign-in, improving clarity and branding. Best Practices Assign Platform SSO policies during device enrollment for a seamless experience. Ensure password policies in Intune and Entra ID are aligned. Use Secure Enclave for most users; Smart Card for compliance scenarios. Regularly review group memberships and issuer assignments for certificate-based authentication. Document all scoped policies for compliance and troubleshooting. Conclusion Microsoft Platform SSO for macOS is a game-changer for organizations seeking secure, passwordless authentication across devices and applications. By leveraging Entra ID credentials, Touch ID, smart cards, and passkeys, IT teams can deliver a modern, seamless, and secure experience for users while maintaining compliance and reducing operational overhead. Ready to get started? Explore the official documentation and accelerate your passwordless journey today!Empower Your Cloud Identity: How to Convert User SOA from AD to Entra ID
For years, hybrid identity has been the standard. We synchronize users from on-premises Active Directory (AD) to Microsoft Entra ID (formerly Azure AD), giving our people one set of credentials for both cloud and local resources. But this setup comes with a hidden limitation: Active Directory remains the Source of Authority (SOA). This traditional model limits your ability to leverage modern security, governance, and management tools available in the cloud. The good news? Microsoft has introduced the capability to shift the SOA for your users entirely to Entra ID. Here’s a deep dive into why this shift is essential, how simple the change is, and the critical implications you need to plan for. The Hybrid Dilemma: Why AD SOA is Limiting: In a typical hybrid setup, every synced user object in Entra ID has properties that are permanently locked down or "grayed out." This is because the object has an underlying attribute, isCloudManaged, set to false. This status means: Limited Lifecycle Management: You can’t fully leverage cloud-based identity governance or lifecycle features. HR Provisioning Complexity: If your Human Resources (HR) system is the true source of truth for new employees, updates must flow: HR → AD → Entra ID. This creates latency and points of failure. Increased Attack Surface: If you are primarily cloud-focused, maintaining an AD object for synchronization creates an unnecessary on-premises attack surface that you must continually protect. No Cloud Editing: You are forced to make all major attribute changes in AD, even if the user only interacts with cloud services. By making Entra ID the Source of Authority, you break this dependency and unlock a truly cloud-first identity posture. The Core Mechanism: A Single Attribute Flip: The actual technical process of changing the SOA is surprisingly simple, it boils down to flipping a single attribute. The change is made using the Microsoft Graph API (or PowerShell) with a PATCH command against the user's onPremisesSyncBehavior endpoint. Action Method Endpoint Body Change SOA PATCH /beta/users/{user-id}/onPremisesSyncBehavior { "isCloudManaged": true } Once this change is made, two immediate things happen: Synchronization Stops: Entra Connect or Cloud Sync immediately recognize the change and stop synchronizing any updates from the on-premises AD object to the Entra ID object. Properties Unlocked: The user's properties in the Entra ID portal are instantly un-grayed, allowing cloud administrators to manage the user's identity directly. Critical Warning: No Write-Back Before you perform this change, you must understand the most critical implication: There is no user write-back capability from Entra ID to AD today. Once you shift the SOA, the connection is unidirectional and then effectively severed. Changes made to the cloud object will not be reflected in the on-premises AD object. Post-Migration Scenarios: Planning the Cutover: After flipping the SOA, you must plan what happens to the on-premises AD object. There are two main scenarios: Scenario 1: Full Cloud Cutover (The Ideal) If your user no longer requires any legacy Kerberos or AD-dependent services: Action in AD: Disable the user account in Active Directory immediately. After a period of validation, the account can be safely deleted. Benefit: This achieves the goal of minimizing your AD footprint, reducing attack surface, and simplifying your HR flow to HR → Entra ID. Scenario 2: Maintaining On-Premises Kerberos Access Many organizations still rely on Kerberos for resources like file shares, legacy applications, or Remote Desktop (RDP) access. Fortunately, you can still access these resources with an Entra ID-managed user, but it requires a few key technical components: Keep the AD Object: You must keep the on-premises AD user account (though it should no longer be managed by AD tools). Passwordless Authentication: The user must utilize a modern passwordless method (like Windows Hello for Business or FIDO2 keys). Cloud Kerberos Trust: Your environment must be configured with a Cloud Kerberos Trust. How it works: The cloud-managed user authenticates with Entra ID using passwordless methods. Entra ID, acting as a pseudo Read-Only Domain Controller, issues a partial Kerberos Ticket Granting Ticket (TGT). This partial TGT is used with your domain controllers to acquire a full Kerberos service ticket, which then grants access to the on-premises resource (e.g., the file share). Final Planning Checklist: While the Graph API command is easy, the preparation is everything. Plan your deployment carefully: Step Action Why 1. Migrate Groups First Shift the SOA for all security groups the user belongs to before shifting the user's SOA. Groups are often a logical first step for moving access controls. 2. Retire Exchange Hybrid Ensure all user mailboxes have been moved to Exchange Online. Entra ID SOA users are incompatible with the on-premises Exchange Hybrid configuration. 3. Plan for HR Flow Update your HR provisioning to target Entra ID directly, bypassing AD, for the affected users. This ensures the user's identity lifecycle is entirely cloud-managed going forward. 4. Automate Write a robust PowerShell script to manage the process, allowing for staged rollouts based on Organizational Units (OUs) or security groups. Avoid making changes one-by-one in the portal for scale and consistency. Moving the Source of Authority to Microsoft Entra ID is a major step toward a modern, highly secure, and simplified identity environment. Understand the implications, plan your path for Kerberos access, and start unlocking the full potential of the cloud.Empower Your Cloud Identity: How to Convert User SOA from AD to Entra ID
For years, hybrid identity has been the standard. We synchronize users from on-premises Active Directory (AD) to Microsoft Entra ID (formerly Azure AD), giving our people one set of credentials for both cloud and local resources. But this setup comes with a hidden limitation: Active Directory remains the Source of Authority (SOA). This traditional model limits your ability to leverage modern security, governance, and management tools available in the cloud. The good news? Microsoft has introduced the capability to shift the SOA for your users entirely to Entra ID. Here’s a deep dive into why this shift is essential, how simple the change is, and the critical implications you need to plan for. The Hybrid Dilemma: Why AD SOA is Limiting: In a typical hybrid setup, every synced user object in Entra ID has properties that are permanently locked down or "grayed out." This is because the object has an underlying attribute, isCloudManaged, set to false. This status means: Limited Lifecycle Management: You can’t fully leverage cloud-based identity governance or lifecycle features. HR Provisioning Complexity: If your Human Resources (HR) system is the true source of truth for new employees, updates must flow: HR → AD → Entra ID. This creates latency and points of failure. Increased Attack Surface: If you are primarily cloud-focused, maintaining an AD object for synchronization creates an unnecessary on-premises attack surface that you must continually protect. No Cloud Editing: You are forced to make all major attribute changes in AD, even if the user only interacts with cloud services. By making Entra ID the Source of Authority, you break this dependency and unlock a truly cloud-first identity posture. The Core Mechanism: A Single Attribute Flip: The actual technical process of changing the SOA is surprisingly simple, it boils down to flipping a single attribute. The change is made using the Microsoft Graph API (or PowerShell) with a PATCH command against the user's onPremisesSyncBehavior endpoint. Action Method Endpoint Body Change SOA PATCH /beta/users/{user-id}/onPremisesSyncBehavior { "isCloudManaged": true } Once this change is made, two immediate things happen: Synchronization Stops: Entra Connect or Cloud Sync immediately recognize the change and stop synchronizing any updates from the on-premises AD object to the Entra ID object. Properties Unlocked: The user's properties in the Entra ID portal are instantly un-grayed, allowing cloud administrators to manage the user's identity directly. Critical Warning: No Write-Back Before you perform this change, you must understand the most critical implication: There is no user write-back capability from Entra ID to AD today. Once you shift the SOA, the connection is unidirectional and then effectively severed. Changes made to the cloud object will not be reflected in the on-premises AD object. Post-Migration Scenarios: Planning the Cutover: After flipping the SOA, you must plan what happens to the on-premises AD object. There are two main scenarios: Scenario 1: Full Cloud Cutover (The Ideal) If your user no longer requires any legacy Kerberos or AD-dependent services: Action in AD: Disable the user account in Active Directory immediately. After a period of validation, the account can be safely deleted. Benefit: This achieves the goal of minimizing your AD footprint, reducing attack surface, and simplifying your HR flow to HR → Entra ID. Scenario 2: Maintaining On-Premises Kerberos Access Many organizations still rely on Kerberos for resources like file shares, legacy applications, or Remote Desktop (RDP) access. Fortunately, you can still access these resources with an Entra ID-managed user, but it requires a few key technical components: Keep the AD Object: You must keep the on-premises AD user account (though it should no longer be managed by AD tools). Passwordless Authentication: The user must utilize a modern passwordless method (like Windows Hello for Business or FIDO2 keys). Cloud Kerberos Trust: Your environment must be configured with a Cloud Kerberos Trust. How it works: The cloud-managed user authenticates with Entra ID using passwordless methods. Entra ID, acting as a pseudo Read-Only Domain Controller, issues a partial Kerberos Ticket Granting Ticket (TGT). This partial TGT is used with your domain controllers to acquire a full Kerberos service ticket, which then grants access to the on-premises resource (e.g., the file share). Final Planning Checklist: While the Graph API command is easy, the preparation is everything. Plan your deployment carefully: Step Action Why 1. Migrate Groups First Shift the SOA for all security groups the user belongs to before shifting the user's SOA. Groups are often a logical first step for moving access controls. 2. Retire Exchange Hybrid Ensure all user mailboxes have been moved to Exchange Online. Entra ID SOA users are incompatible with the on-premises Exchange Hybrid configuration. 3. Plan for HR Flow Update your HR provisioning to target Entra ID directly, bypassing AD, for the affected users. This ensures the user's identity lifecycle is entirely cloud-managed going forward. 4. Automate Write a robust PowerShell script to manage the process, allowing for staged rollouts based on Organizational Units (OUs) or security groups. Avoid making changes one-by-one in the portal for scale and consistency. Moving the Source of Authority to Microsoft Entra ID is a major step toward a modern, highly secure, and simplified identity environment. Understand the implications, plan your path for Kerberos access, and start unlocking the full potential of the cloud.Subscription Governance: The Relationships and Dependencies Involved with Managing Subscriptions
In this article Introduction Relationships and dependencies between Entra ID, Billing Accounts and Subscriptions Identity and Roles Billing Account and Subscription Creation Summary Introduction In cloud governance, the relationships between Entra ID, Billing Accounts, Subscriptions, and User Permissions are frequently misunderstood even by experienced practitioners. Many organizations assume these components form a simple hierarchy or that permissions and associations are inherited in certain ways. In reality, these elements are loosely associated, and their dependencies are far more nuanced. Misunderstanding these relationships and dependencies poses a challenge to governance and can allow subscription sprawl. For example, assuming that billing accounts and subscriptions are always tied to the same Entra ID tenant, or that user roles in Entra ID automatically confer billing permissions, can result in misconfigured access controls and the creation of subscriptions outside of your corporate procurement and deployment processes. There can also be confusion about where to go to manage permissions. Is it Entra ID, is it in the resource RBAC, is it in the billing account? Effective governance requires clarity on: How Entra ID tenants, billing accounts, and subscriptions are associated and how these associations can be changed. Which roles have the authority to create or manage subscriptions and billing accounts, and where those roles are found. How the type of billing account (EA, MCA, MOSP, Partner) determines who can create subscriptions and what controls are available. By understanding these foundational relationships and the specific permissions required, organizations can avoid common pitfalls and build a governance model that is both secure and flexible. Relationships and dependencies between Entra ID, Billing Accounts and Subscriptions In order to manage subscriptions, it is key to understand the components and dependencies related to subscriptions. Let’s first understand the relationship between subscriptions, billing accounts and Entra ID tenants. Do not think of the tenant as a container for billing accounts which are containers for subscriptions. Think of the relationship between these components as “associations” rather than a hierarchy. A billing account is typically associated with a single Entra ID tenant. However, with MCA billing accounts you can configure Associated Billing Tenants which allow users from multiple tenants to have billing permissions on a single billing account. Entra ID can have many different billing accounts of different types. A billing account can be associated with many subscriptions, but a subscription can only be associated with a single billing account. An Entra ID tenant can be associated with many subscriptions, but a subscription can only be associated with a single tenant. A subscription is first associated with the tenant in which the user is logged in, which isn’t always the same tenant for which the associated billing account belongs to. These relationships or associations can also be changed later. For example, Subscription Owners can change the association of the subscription’s Entra ID tenant to ANY other Entra ID tenant in which they have access. They don’t need elevated permissions in the target tenant. One of the most important things to know is that the billing account that is associated with a subscription does not need to be associated with the same Entra ID tenant for which the subscription is associated with. See the following example associations: Identity and Roles Entra ID is a directory of user identities and other objects. A user identity can be associated with many Entra ID tenants. While the primary account belongs to a single tenant, users can be invited as guest users to any number of Entra ID tenants using B2B collaboration. There are three places that house roles/permissions that are mapped to those user identities: Entra ID roles, Azure Resource Manager (ARM) Role Based Access Control (RBAC), and Billing Accounts. Entra ID Roles Entra ID roles manage directory level objects such as user identities. The Global Administrator is the most well-known role within Entra ID. Entra ID roles are typically limited to managing the directory, however there is the ability to elevate access so that the Global Administrator can access and assign RBAC and Billing roles to themselves or others (two exceptions are that the Global Admin cannot elevate billing permissions for EA or MOSP billing accounts). Entra ID roles assigned to a user in one tenant do not follow them when they gain access to another tenant. ARM RBAC RBAC is a function of the ARM and is scoped to either management groups, subscriptions, resource groups or resources. RBAC is inherited from parent scopes. The RBAC assigned for a user in one tenant, is not shared with any another tenant as the mappings are maintained by ARM for each resource in the tenant. As each tenant has unique resources, the RBAC mapping the user has for resources in one tenant logically cannot exist in another tenant. While user identity is handled by Entra ID, the RBAC is handled at the resource level. Billing Roles Billing roles are a part of the billing/commerce engine and depend on the billing account type. For example, with an MCA billing account you manage them in Cost Management + Billing instead and not in Entra ID. These billing roles are different depending on the billing account type. While billing roles manage access to billing details, they also control the creation of subscriptions. If you have the correct billing role, you can create subscriptions under that billing account. Subscription creation is not managed by Entra ID roles nor RBAC. Billing Accounts There are 4 main billing account types: Enterprise Agreements (EA): Legacy contractual model for large enterprises. Provides volume licensing discounts, centralized invoicing, and long-term pricing commitments but is gradually being replaced by MCA. Billing roles to create subscriptions: Enterprise Administrator, Account Owner Microsoft Customer Agreements (MCA) The modern default billing model for enterprise customers. Free trial and pay-go subscriptions are supported. Invoice-based or credit card billing, supports multiple billing profiles and invoice sections. Billing roles to create subscriptions: Billing Account Owner/Contributor, Billing Profile Owner/Contributor, Billing Invoice Owner/Contributor, Subscription Creator Microsoft Online Services Program (MOSP) Agreements Tied to a single user, lacks enterprise governance features, and is the most common source of subscription sprawl. Typically used by individuals or small businesses and supports free trial, pay-go and Visual Studio subscriptions. Billing role to create subscriptions: Account Administrator Microsoft Partner Agreements (MPA) A billing account owned and managed by a Microsoft partner. Subscriptions billed under CSP appear in your tenant but financially roll up under the partner’s agreement. Control over invoicing and some subscription-level actions is delegated to the CSP, not directly to corporate IT. Billing role to create subscriptions: Admin agent role in the CSP partner organization Billing Account and Subscription Creation As the roles within the billing account provide the permissions to create subscriptions it is important to understand who can create these billing accounts. Because whoever can create a billing account, is also able to create a subscription. And remember, subscriptions do not need to be associated with the same Entra ID tenant as the billing account. Billing accounts are created in the following ways: Enterprise Agreements (EA) An individual at your company works with Microsoft to set up an EA contract. An EA billing account is created for them, and they become the Enterprise Administrator for that billing account. Microsoft Customer Agreements (MCA) An individual at your company works with Microsoft to set up an MCA contract. An MCA billing account is created for them, and they become the Billing Account Owner for that billing account. Microsoft Online Services Program (MOSP) Agreements Any individual can perform a self-signup for a pay-go or free-trial subscription. When they do this, a billing account is created for them, and they become the Account Administrator for that billing account. This can be done in any Entra ID tenant for which they have an identity (including guest accounts). Microsoft Partner Agreements A Microsoft Partner registers and manages the CSP billing account on behalf of a customer. They become the Admin agent. Summary Understanding the associations between Entra ID tenants, identity, permissions, billing accounts, and subscriptions is foundational for effective governance. With these building blocks in place, you can design for and establish governance that will ensure your environment aligns with your corporate strategy and reduce opportunity for subscription sprawl.
Update Entra ID Device Extension Attributes via PowerShell & Create Dynamic Security Groups.
2) Overview of Extension Attributes and Updating via PowerShell What Are Extension Attributes? Extension attributes (1–15) are predefined string fields available on Entra ID device objects. They are exposed to Microsoft Graph as the extensionAttributes property. These attributes can store custom values like department, environment tags (e.g., Prod, Dev), or ownership details. Why Use Them? Dynamic Group Membership: Use extension attributes in membership rules for security or Microsoft 365 groups. Policy Targeting: Apply Defender for Endpoint (MDE) policies, Conditional Access or Intune policies to devices based on custom tags. For details on configuration of the policies refer below documentation links. https://learn.microsoft.com/en-us/defender-endpoint/manage-security-policies https://learn.microsoft.com/en-us/intune/intune-service/ https://learn.microsoft.com/en-us/entra/identity/conditional-access/ Updating Extension Attributes via PowerShell and Graph API Use Microsoft Graph PowerShell to authenticate and update device properties. Required permission: “Device.ReadWrite.All”. 3) Using PowerShell to Update Extension Attributes create app registration in Entra ID with permissions Device.ReadWriteall and Grant admin Consent. Register an app How to register an app in Microsoft Entra ID - Microsoft identity platform | Microsoft Learn Graph API permissions Reference. For updating Entra ID device properties you need “Device.ReadWrite.all” permission and Intune administrator role to run the script. Microsoft Graph permissions reference - Microsoft Graph | Microsoft Learn Below is the script Important things to note and update the script with your custom values. a) update the path of the excel file in the script. column header is 'DeviceName' Note: You may want to use CSV instead of excel file if Excel is not available on the admin workstation running this process. b) update the credential details - tenantId,clientId & clientSecret in the script. Client id and client secret are created as a part of app registration. c) update the Externsionattribute and value in the script. This is the value of the extension attribute you want to use in dynamic membership rule creation. ___________________________________________________________________________ #Acquire token $tenantId = "xxxxxxxxxxxxxxxxxxxxx" $clientId = "xxxxxxxxxxxxxxxx" $clientSecret = "xxxxxxxxxxxxxxxxxxxx" $excelFilePath = "C:\Temp\devices.xlsx" # Update with actual path $tokenResponse = Invoke-RestMethod -Uri "https://login.microsoftonline.com/ $tenantId/oauth2/v2.0/token" -Method POST -Body $tokenBody $accessToken = $tokenResponse.access_token # Import Excel module and read device names Import-Module ImportExcel $deviceList = Import-Excel -Path $excelFilePath foreach ($device in $deviceList) { $deviceName = $device.DeviceName # Assumes column header is 'DeviceName' Get device ID by name $headers = @{ "Authorization" = "Bearer $accessToken"} $deviceLookupUri = "https://graph.microsoft.com/beta/devices?`$filter=displayName eq '$deviceName'" try { $deviceResponse = Invoke-RestMethod -Uri $deviceLookupUri -Headers $headers -Method GET } catch { Write-Host "Error querying device: $deviceName - $_" continue } if ($null -eq $deviceResponse.value -or $deviceResponse.value.Count -eq 0) { Write-Host "Device not found: $deviceName" continue } $deviceId = $deviceResponse.value[0].id # Prepare PATCH request $uri = "https://graph.microsoft.com/beta/devices/$deviceId" $headers["Content-Type"] = "application/json" $body = @{ extensionAttributes = @{ extensionAttribute6 = "MDE" } } | ConvertTo-Json -Depth 3 try { $response = Invoke-RestMethod -Uri $uri -Method Patch -Headers $headers -Body $body Write-Host "Updated device: $deviceName"} catch { Write-Host "Failed to update device: $deviceName - $_" } } Write-Host "Script execution completed." ________________________________________________________________________________________________________________________ Here’s a simple summary of what the script does: Gets an access token from Microsoft Entra ID using the app’s tenant ID, client ID, and client secret (OAuth 2.0 client credentials flow). Reads an Excel file (update the path in $excelFilePath, and ensure the column header is DeviceName) to get a list of device names. Loops through each device name from the Excel file: Calls Microsoft Graph API to find the device ID by its display name. If the device is found, sends a PATCH request to Microsoft Graph to update extensionAttribute6 with the value "MDE". Logs the result for each device (success or failure) and prints messages to the console. 4) Using Extension Attributes in Dynamic Device Groups Once extension attributes are set, you can create a dynamic security group in Entra ID: Go to Microsoft Entra admin center → Groups → New group. Select Security as the group type and choose Dynamic Device membership. Add a membership rule, for example: (device.extensionAttributes.extensionAttribute6 -eq "MDE") 4. Save the group. Devices with extensionAttribute6 = MDE will automatically join. 5) Summary Extension attributes in Entra ID allow custom tagging of devices for automation and policy targeting. You can update these attributes using Microsoft Graph PowerShell. These attributes can be used in dynamic device group rules, enabling granular MDE policies, Conditional Access and Intune deployments. Disclaimer This script is provided "as-is" without any warranties or guarantees. It is intended for educational and informational purposes only. Microsoft and the author assume no responsibility for any issues that may arise from the use or misuse of this script. Before deploying in a production environment, thoroughly test the script in a controlled setting and review it for compliance with your organization's security and operational policies.Using Entra ID Authentication with Arc-Enabled SQL Server in a .NET Windows Forms Application
Introduction: This guide demonstrates how to securely connect a .NET Framework Windows Forms application to an Arc-enabled SQL Server 2022 instance using Entra ID (Azure AD) authentication. It covers user authentication, token management, and secure connection practices, with code samples and screenshots. In many modern applications, it is common practice to use an application web service to mediate access to SQL Server. This approach can offer several advantages, such as improved security, scalability, and centralized management of database connections. However, there are scenarios where directly connecting to SQL Server is more appropriate. This guide focuses on such scenarios, providing a solution for applications that need direct access to SQL Server. This model is particularly useful for applications like SQL Server Management Studio (SSMS), which require direct database connections to perform their functions. By using Entra ID authentication, we can ensure that these direct connections are secure and that user credentials are managed efficiently. By following the steps outlined in this guide, developers can ensure secure and efficient connections between their .NET Windows Forms applications and Arc-enabled SQL Server instances using Entra ID authentication. This approach not only enhances security but also simplifies the management of user credentials and access tokens, providing a robust solution for modern application development. SAMPLE CODE: GitHub Repository Prerequisites Arc-enabled SQL Server 2022/2025 configured for Entra ID authentication Entra ID (Azure AD) tenant and app registration .NET Framework 4.6.2 Windows Forms application (Not required .NET version, only what the solution is based on) Microsoft.Identity.Client, Microsoft.Data.SqlClient NuGet packages Application Overview User authenticates with Entra ID Token is acquired and used to connect to SQL Server Option to persist token cache or keep it in memory Data is retrieved and displayed in a DataGridView Similar setup to use SSMS with Entra ID in articles below. Windows Form Sample Check User Button shows the current user The Connect to Entra ID at Login button will verify if you are logged in and try to connect to SQL Server. If the user is not logged in, an Entra ID authentication window will be displayed or ask you to log in. Once logged in it shows a Connection successful message box stating the connection to the database was completed. The Load Data button queries the Adventure Works database Person table and loads the names into the datagridview. The Cache Token to Disk checkbox option either caches to memory when unchecked and would require reauthentication after the application closes, or the option to cache to disk the token to be read on future application usage. If the file is cached to disk, the location of the cached file is (C:\Users\[useraccount]\AppData\Local). This sample does not encrypt the file which is something that would be recommended for production use. This code uses MSAL (Microsoft Authentication Library) to authenticate users in a .NET application using their Microsoft Entra ID (Azure AD) credentials. It configures the app with its client ID, tenant ID, redirect URI, and logging settings to enable secure token-based authentication. //Application registration ClientID, and TenantID are required for MSAL authentication private static IPublicClientApplication app = PublicClientApplicationBuilder.Create("YourApplicationClientID") .WithAuthority(AzureCloudInstance.AzurePublic, "YourTenantID") .WithRedirectUri("http://localhost") .WithLogging((level, message, containsPii) => Debug.WriteLine($"MSAL: {message}"), LogLevel.Verbose, true, true) .Build(); This method handles user login by either enabling persistent token caching or setting up temporary in-memory caching, depending on the input. It then attempts to silently acquire an access token for Azure SQL Database using cached credentials, falling back to interactive login if no account is found. private async Task<AuthenticationResult> LoginAsync(bool persistCache) { if (persistCache) TokenCacheHelper.EnablePersistence(app.UserTokenCache); else { app.UserTokenCache.SetBeforeAccess(args => { }); app.UserTokenCache.SetAfterAccess(args => { }); } string[] scopes = new[] { "https://database.windows.net//.default" }; var accounts = await app.GetAccountsAsync(); if (accounts == null || !accounts.Any()) return await app.AcquireTokenInteractive(scopes).ExecuteAsync(); var account = accounts.FirstOrDefault(); return await app.AcquireTokenSilent(scopes, account).ExecuteAsync(); } Connecting to SQL Server with Access Token This code connects to an Azure SQL Database using a connection string and an access token obtained through MSAL authentication. It securely opens the database connection by assigning the token to the SqlConnection object, enabling authenticated access without storing credentials in the connection string. This sample uses a self-signed certificate, in production always configure SQL Server protocols with a certificate issued by a trusted Certificate Authority (CA). TrustServerCertificate=True bypasses certificate validation and can allow MITM attacks. For production, use a trusted Certificate Authority and change TrustServerCertificate=True to TrustServerCertificate=False. Configure Client Computer and Application for Encryption - SQL Server | Microsoft Learn string connectionString = $"Server={txtSqlServer.Text};Database=AdventureWorks2019;Encrypt=True;TrustServerCertificate=True;"; var result = await LoginAsync(checkBox1.Checked); using (var conn = new SqlConnection(connectionString)) { conn.AccessToken = result.AccessToken; conn.Open(); // ... use connection ... } Fetching Data into DataGridView This method authenticates the user and connects to an Azure SQL Database using an access token, and runs a SQL query to retrieve the top 1,000 names from the Person table. It loads the results into a DataTable, which can then be used for display or further processing in the application. private async Task<DataTable> FetchDataAsync() { var dataTable = new DataTable(); var result = await LoginAsync(checkBox1.Checked); using (var conn = new SqlConnection(connectionString)) { conn.AccessToken = result.AccessToken; await conn.OpenAsync(); using (var cmd = new SqlCommand("SELECT TOP (1000) [FirstName], [MiddleName], [LastName] FROM [AdventureWorks2019].[Person].[Person]", conn)) using (var reader = await cmd.ExecuteReaderAsync()) { dataTable.Load(reader); } } return dataTable; } Configure Azure Arc SQL Server to use Entra ID authentication Using SQL Server 2022 follow the instructions here to setup the key vault and certificate when configuring. This article can also be used to configure SSMS to use Entra ID authentication. Detailed steps located here: Set up Microsoft Entra authentication for SQL Server - SQL Server | Microsoft Learn Using SQL Server 2025 the setup is much easier as you do not need to configure a Key Vault, or certificates as it is relying on using the managed identity for the authentication. Entra ID App Registration Steps Register a new app in Azure AD Add a redirect URI (http://localhost) Add API permissions for https://database.windows.net/.default On the Entra ID app registration, click on API Permissions. Add the API’s for Microsoft Graph: User.Read.All Application.Read.All Group.Read.All Add a permission for Azure SQL Database. If Azure SQL database is not shown in the list ensure that the Resource Provider is registered for Microsoft.Sql. Choose Delegated permissions and select user_impersonation, Click Add permission for the Azure SQL Database. NOTE: Once the permissions are added ensure that you grant admin consent on the items. Security Considerations Never store client secrets in client apps Use in-memory token cache for higher security, or encrypted disk cache for convenience Use user tokens for auditing and least privilege References Microsoft Docs: Azure AD Authentication for SQL Server MSAL.NET Documentation Arc-enabled SQL Server Documentation Conclusion: By following the steps outlined in this guide, developers can ensure secure and efficient connections between their .NET Windows Forms applications and Arc-enabled SQL Server instances using Entra ID authentication. This approach not only enhances security but also simplifies the management of user credentials and access tokens, providing a robust solution for modern application development. *** Disclaimer *** The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.Issuing Custom Claims Using Directory Extension Attributes in Microsoft Entra ID
Overview In some scenarios, organizations may need to pass custom data about users like internal identifiers or sponsorship info to applications during SSO. Microsoft Entra ID supports this using directory extension attributes, which can be registered and referenced in claims. This blog outlines how to register and use custom directory extension attributes in an Enterprise Application and configure them to issue claims conditionally based on group membership. Step 1: Register Directory Extension Attributes Use Graph Explorer to register two custom attributes, for example sponsorid1 and sponsorid2, in the target application. Send a POST request to: POST https://graph.microsoft.com/v1.0/applications/{AppObjectId}/extensionProperties Request body example: { "name": "sponsorid1", "dataType": "String", "targetObjects": ["User"] } Repeat the process for sponsorid2. After registration, the system will return the full attribute names in this format: extension_<AppClientID>_sponsorid1 extension_<AppClientID>_sponsorid2 Note these exact names for future use. Step 2: Assign Extension Attributes to Users Use Graph Explorer again to PATCH user objects and assign values to these extension attributes. Request URL: PATCH https://graph.microsoft.com/v1.0/users/{UserObjectId} Request body: { "extension_<AppClientID>_sponsorid1": "ABC123" } Repeat this for each user, assigning the corresponding attribute (sponsorid1 or sponsorid2). Step 3: Create Claims in Enterprise Application Navigate to Entra ID > Enterprise Applications > [App Name] > Single Sign-On > Attributes & Claims. 1. Click Add new claim 2. Provide a name (e.g., sponsorClaim1) 3. Under Claim conditions, select Member and choose the group that should receive the claim 4. In the source attribute, use the directory extension attribute name (e.g., extension_<AppClientID>_sponsorid1) Repeat for the second group and attribute. Step 4: Handle Claim Mapping Error If you see the error "Application requires custom signing key to customize claims" You can temporarily bypass this by updating the app registration manifest: "acceptMappedClaims": true This allows claims customization without custom signing keys. Step 5: Test the Configuration Call the application using https://login.microsoftonline.com/(Tenant ID)/oauth2/v2.0/authorize?client_id=(Client ID) &response_type=id_token&redirect_uri=https://jwt.ms&scope=openid&state=12345&nonce=12345 and sign in with users who belong to the defined groups. You should see the expected custom claims (sponsorid1 or sponsorid2) issued in the SAML or OIDC token in https://jwt.ms. Users not in any of the groups will not receive any sponsor claim. Conclusion Directory extension attributes are a powerful way to issue dynamic claims in Microsoft Entra ID. By combining them with conditional claim issuance based on group membership, you can tailor your application's SSO experience to meet specific business logic.Token Protection by using Microsoft Entra ID.
As organizations move to the cloud and adopt SaaS applications, identities are becoming increasingly crucial for accessing resources. Cybercriminals exploit legitimate and authorized identities to steal data and access credentials through methods like phishing, malware, data breaches, brute-force/password spray attacks, and prior compromises. As in past years, password-based attacks on users constitute most identity-related attacks. As MFA blocks most password-based attacks, threat actors are shifting their focus, moving up the cyberattack chain in three ways: 1) attacking infrastructure, 2) bypassing authentication, and 3) exploiting applications. They are leaning more heavily into adversary-in-the-middle (AiTM) phishing attacks and token theft. Over the last year, as Microsoft Digital Defense Report (MDDR 2024) a 146% rise in AiTM phishing attacks. In AiTM attack , the attackers steal tokens instead of passwords. The Frameworks used by attackers go far beyond credential phishing, by inserting malicious infrastructure between the user and the legitimate application the user is trying to access. When the user is phished, the malicious infrastructure captures both the credentials of the user, and the token. By compromising and replaying a token issued to an identity that has already completed multifactor authentication, the threat actor satisfies the validation of MFA and access is granted to organizational resources accordingly. Now it is imperative that tokens must be protected from token theft. Let us understand more on tokens. An Entra identity token is a security token issued by Microsoft Entra ID for authentication and authorization. There are several types: Access Tokens: Grant access to resources on behalf of an authenticated user, containing user and resource information. ID Tokens: Authenticate users, issued in the OpenID Connect flow, containing user identity and authentication details. Refresh Tokens: Obtain new access tokens without re-authentication, usually issued with access tokens and have a longer lifespan. Ensuring Token Security By following best practices, you can significantly enhance the security of your tokens and protect your applications from unauthorized access. Use Secure Transmission: Always transmit tokens over secure channels such as HTTPS to prevent interception by unauthorized parties. Token Binding: Implement Token Protection (formerly known as token binding) to cryptographically tie tokens to client secrets. This prevents token replay attacks from different devices. Conditional Access Policies: Use Conditional Access policies to enforce compliant network checks. This ensures that tokens are only used from trusted networks and devices. Continuous Access Evaluation (CAE): Implement CAE to continuously evaluate the security state of the session. This helps in detecting and revoking tokens if there are changes in the user's security posture, such as network location changes. Short Token Lifetimes: Use short lifetimes for access tokens and refresh tokens to limit the window of opportunity for attackers. Secure Storage: Store tokens securely on the client side, using secure storage mechanisms provided by the operating system, such as Keychain on iOS or Keystore on Android. Regular Audits and Monitoring: Regularly audit token usage and monitor for any unusual activity. This helps in early detection of potential security breaches. Now we will discuss Entra ID new features for Token Protection. Token protection using conditional access : This feature will provide refresh token protection. Compliant network check with Conditional Access: This feature will provide both refresh token and Access token protection. Token protection using conditional access: Token protection (sometimes referred to as token binding in the industry) attempts to reduce attacks using token theft by ensuring a token is usable only from the intended device. When an attacker is able to steal a token, by hijacking or replay, they can impersonate their victim until the token expires or is revoked. Token theft is thought to be a relatively rare event, but the damage from it can be significant. Token protection creates a cryptographically secure tie between the token and the device (client secret) it's issued to. Without the client secret, the bound token is useless. When a user registers a Windows 10 or newer device in Microsoft Entra ID, their primary identity is bound to the device. What this means: A policy can ensure that only bound sign-in session (or refresh) tokens, otherwise known as Primary Refresh Tokens (PRTs) are used by applications when requesting access to a resource. Token protection is currently in public preview Create a Conditional Access policy Users who perform specialized roles like those described in Privileged access security levels are possible targets for this functionality. We recommend piloting with a small subset to begin. The steps that follow help create a Conditional Access policy to require token protection for Exchange Online and SharePoint Online on Windows devices. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator. Browse to Protection > Conditional Access > Policies. Select New policy. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies. Under Assignments, select Users or workload identities. Under Include, select the users or groups who are testing this policy. Under Exclude, select Users and groups and choose your organization's emergency access or break-glass accounts. 6.Under Target resources > Resources (formerly cloud apps) > Include > Select resources Under Select, select the following applications supported by the preview: Office 365 Exchange Online Office 365 SharePoint Online Choose Select. 7. Under Conditions: Under Device platforms: Set Configure to Yes. Include > Select device platforms > Windows. Select Done. Under Client apps: Set Configure to Yes Under Modern authentication clients, only select Mobile apps and desktop clients. Leave other items unchecked. Select Done. 8. Under Access controls > Session, select Require token protection for sign-in sessions and select Select. 9. Confirm your settings and set Enable policy to Report-only. 10.Select Create to create to enable your policy. After administrators confirm the settings using report-only mode, they can move the Enable policy toggle from Report-only to On. Capture logs and analyze Monitoring Conditional Access enforcement of token protection before and after enforcement. Sign-in logs Use Microsoft Entra sign-in log to verify the outcome of a token protection enforcement policy in report only mode or in enabled mode. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator. Browse to Identity > Monitoring & health > Sign-in logs. Select a specific request to determine if the policy is applied or not. Go to the Conditional Access or Report-Only pane depending on its state and select the name of your policy requiring token protection. Under Session Controls check to see if the policy requirements were satisfied or not. You can refer below link to know more about license requirements, prerequisites & limitations. Token protection in Microsoft Entra Conditional Access - Microsoft Entra ID | Microsoft Learn Enable compliant network check with Conditional Access Organizations who use Conditional Access along with the Global Secure Access, can prevent malicious access to Microsoft apps, third-party SaaS apps, and private line-of-business (LoB) apps using multiple conditions to provide defense-in-depth. These conditions might include device compliance, location, and more to provide protection against user identity or token theft. Global Secure Access introduces the concept of a compliant network within Microsoft Entra ID Conditional Access. This compliant network check ensures users connect from a verified network connectivity model for their specific tenant and are compliant with security policies enforced by administrators. The Global Secure Access Client installed on devices or users behind configured remote networks allows administrators to secure resources behind a compliant network with advanced Conditional Access controls. This compliant network feature makes it easier for administrators to manage access policies, without having to maintain a list of egress IP addresses. This removes the requirement to hairpin traffic through organization's VPN. Compliant network check enforcement Compliant network enforcement reduces the risk of token theft/replay attacks. Compliant network enforcement happens at the authentication plane (generally available) and at the data plane (preview). Authentication plane enforcement is performed by Microsoft Entra ID at the time of user authentication. If an adversary has stolen a session token and attempts to replay it from a device that is not connected to your organization’s compliant network (for example, requesting an access token with a stolen refresh token), Entra ID will immediately deny the request and further access will be blocked. Data plane enforcement works with services that support Continuous Access Evaluation (CAE) - currently, only SharePoint & Exchange Online. With apps that support CAE, stolen access tokens that are replayed outside your tenant’s compliant network will be rejected by the application in near-real time. Without CAE, a stolen access token will last up to its full lifetime (default 60-90 minutes). This compliant network check is specific to each tenant. Using this check, you can ensure that other organizations using Microsoft's Global Secure Access services can't access your resources. For example: Contoso can protect their services like Exchange Online and SharePoint Online behind their compliant network check to ensure only Contoso users can access these resources. If another organization like Fabrikam was using a compliant network check, they wouldn't pass Contoso's compliant network check. The compliant network is different than IPv4, IPv6, or geographic locations you might configure in Microsoft Entra. Administrators are not required to review and maintain compliant network IP addresses/ranges, strengthening the security posture and minimizing the ongoing administrative overhead. Enable Global Secure Access signaling for Conditional Access To enable the required setting to allow the compliant network check, an administrator must take the following steps. Sign in to the Microsoft Entra admin center as a Global Secure Access Administrator. Browse to Global Secure Access > Settings > Session management > Adaptive access. Select the toggle to Enable CA Signaling for Entra ID (covering all cloud apps). This will automatically enable CAE signaling for Office 365 (preview). Browse to Protection > Conditional Access > Named locations. a. Confirm you have a location called All Compliant Network locationswith location type Network Access. Organizations can optionally mark this location as trusted. You can refer below link to know more about license requirements, prerequisites & limitations Protect your resources behind the compliant network The compliant network Conditional Access policy can be used to protect your Microsoft and third-party applications. A typical policy will have a 'Block' grant for all network locations except Compliant Network. The following example demonstrates the steps to configure this type of policy: Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator. Browse to Protection > Conditional Access. Select Create new policy. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies. Under Assignments, select Users or workload identities. Under Include, select All users. Under Exclude, select Users and groupsand choose your organization's emergency access or break-glass accounts. 6. Under Target resources > Include and select All resources (formerly 'All cloud apps'). If your organization is enrolling devices into Microsoft Intune, it is recommended to exclude the applications Microsoft Intune Enrollmentand Microsoft Intune from your Conditional Access policy to avoid a circular dependency. 7. Under Network. Set Configureto Yes. Under Include, select Any location. Under Exclude, select the All Compliant Network locationslocation. 8. Under Access controls: Grant, select Block Access, and select Select. 9. Confirm your settings and set Enable policy to On. 10. Select the Create button to create to enable your policy. User exclusions Conditional Access policies are powerful tools, we recommend excluding the following accounts from your policies: Emergency access or break-glass accounts to prevent lockout due to policy misconfiguration. In the unlikely scenario all administrators are locked out, your emergency-access administrative account can be used to log in and take steps to recover access. More information can be found in the article, Manage emergency access accounts in Microsoft Entra ID. Service accounts and Service principals, such as the Microsoft Entra Connect Sync Account. Service accounts are non-interactive accounts that aren't tied to any particular user. They're normally used by back-end services allowing programmatic access to applications but are also used to sign in to systems for administrative purposes. Calls made by service principals won't be blocked by Conditional Access policies scoped to users. Use Conditional Access for workload identities to define policies targeting service principals. If your organization has these accounts in use in scripts or code, consider replacing them with managed identities. Try your compliant network policy On an end-user device with the Global Secure Access client installed and running, browse to https://outlook.office.com/mail/ or https://yourcompanyname.sharepoint.com/, you have access to resources. Pause the Global Secure Access client by right-clicking the application in the Windows tray and selecting Pause. Browse to https://outlook.office.com/mail/ or https://yourcompanyname.sharepoint.com/, you're blocked from accessing resources with an error message that says You cannot access this right now. You can refer below link to know more about license requirements, prerequisites & limitations Enable compliant network check with Conditional Access - Global Secure Access | Microsoft LearnPasswordless Authentication with FIDO2 Security Key for Remote Desktop Connection
Passwordless Authentication with FIDO2 Security Key for Remote Desktop Connection Hello Everyone, in this blog, we will explore how to use a FIDO2 security key to access a device using Remote Desktop Connection (RDP)—a Zero Trust approach where passwordless authentication is enforced. Recently, a customer asked me whether they could secure their device and enforce passwordless authentication for RDP access. While some FIDO2 security keys can also be used as smart cards with Certificate-Based Authentication (CBA), I will cover that topic in my next blog. In this post, let's focus on how we can use Windows 10/11, the RDPAAD (Remote Desktop Protocol Azure AD Protocol), and WebAuthn to connect to Entra ID-joined or Hybrid-joined devices using a FIDO2 security key. If a user has never used or registered a FIDO2 security key, they should register it by visiting My Sign-Ins, clicking on Security Info, and selecting Add sign-in method. Once the FIDO2 security key is registered, complete the sign-in process and ensure the user can successfully authenticate to web applications using the security key. Configuring RDP for Entra ID-Joined Devices: For Entra ID-joined devices, follow these steps to enable RDP access using a FIDO2 security key: Ensure the user is a member of the local Remote Desktop Users group on the remote device. o Open PowerShell as Administrator and load the Microsoft Graph PowerShell module to connect to Entra ID (if needed). o Run the following command to add the user to the Remote Desktop Users group: o net localgroup "Remote Desktop Users" /add "AzureAD\user200@farooquetech.in" We can validate the configuration by opening Computer Management and checking the Local Users and Groups settings: Open Computer Management (compmgmt.msc). Navigate to Local Users and Groups → Groups. Locate and open the Remote Desktop Users group. Check if the Entra ID user we added appears in the list. This confirms that the user has been successfully added and can sign-in to remote machine using RDP. At this point, we can open Remote Desktop Connection (mstsc.exe) and attempt to connect to the remote device. Open Remote Desktop Connection (mstsc.exe). Click on the Advanced tab. Under User Authentication, ensure we select "Use a web account to sign in to the remote computer." This ensures that the RDP session leverages passwordless authentication with FIDO2 and WebAuthn for secure access. Enter the NetBIOS name of the remote computer in Remote Desktop Connection (mstsc.exe) and click Connect. On the sign-in page, enter the Entra ID account for which FIDO2 Security Key authentication is enabled. When prompted to choose a passwordless authentication method, select Security Key. Insert your FIDO2 security key, follow the prompts, and complete the authentication process. This ensures a secure, passwordless RDP connection to the remote device. Put the PIN and also touch your finger on Security Key to complete authentication. A consent is prompt to allow RDP Connection, select Yes. Post Authentication, we will see the desktop successfully loads. Remote Desktop Connection Access to Hybrid Entra ID-Joined Devices: Now, let's discuss how to establish RDP access for Hybrid Entra ID-joined devices. The process for Hybrid-joined devices differs slightly because these devices are joined to both Active Directory (AD) and Entra ID. This means authentication must be validated in both directories. To achieve this, we need to register an Active Directory Read-Only Domain Controller (RODC) object in Entra ID. This RODC object helps issue a partial Kerberos Ticket Granting Ticket (TGT) to the user after authentication with Entra ID. Note: This RODC object is not linked to any on-premises AD domain controller—it is simply an empty object in Entra ID used to enable Kerberos authentication. Enabling Entra ID Kerberos Authentication: To enable Entra ID Kerberos authentication, follow these steps: Open PowerShell as Administrator. Install the AzureADKerberos module (if not already installed): Execute below powershell commands Import-module “Import-module "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADKerberos\AzureAdKerberos.psd1" $domain = $env:USERDNSDOMAIN $userPrincipalName = admin@mngenvmcapXXX.onmicrosoft.com $domainCred = Get-Credential (Enter the Active Directory credentials) Once the command executes successfully, we can verify that the AzureADKerberos account has been created in Active Directory. Open Active Directory Users and Computer and under Domain Controller, check AzureADKerberos RODC object is created. This completes the AzureADKerberos configuration, enabling the use of FIDO2 Security Keys for authentication. Now, to establish an RDP connection, follow the same steps outlined earlier for Entra ID-joined devices. Enforcing Phishing-Resistant Passwordless Authentication for RDP: To ensure that Remote Desktop Protocol (RDP) always uses phishing-resistant passwordless authentication, we can enforce this through Conditional Access Policies in Entra ID. Sign in to the Entra ID portal. Go to Security → Conditional Access and create a new policy. Under Assignments, select the users or groups that require secure RDP access. In the Cloud apps or actions section, select “Microsoft Remote Desktop” with Application ID “a4a365df-50f1-4397-bc59-1a1564b8bb9c”. Under Grant Controls, choose Require authentication strength. Select Phishing-resistant authentication, which includes FIDO2 Security Keys Save and enable the policy. Note: For Hybrid Entra Joined machine, please ensure we do not use domain admin or any other AD high privileged account to logon else partial TGT will not be issued by Entra ID. I hope you found this blog helpful! In my next blog, I will cover how FIDO2 Security Keys can also be used for on-premises Active Directory domain-joined servers. Stay tuned!
