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!
