The Future of Identity: Self-Service Account Recovery (Preview) in Microsoft Entra
In the modern enterprise, the "Help Desk" is paradoxically both a vital resource and a massive security liability. As organizations move toward phishing-resistant, passwordless environments using passkeys and FIDO2 tokens, a critical question remains: What happens when a user loses their only authentication device? Historically, this required a phone call to a support agent. However, in an era of sophisticated social engineering and AI-generated deepfakes, a human agent is often the easiest point of entry for an attacker. Microsoft Entra’s new Self-Service Account Recovery solves this by replacing manual verification with high-assurance, automated identity proofing. The Fatal Flaw in Traditional Recovery Most organizations currently rely on one of two methods for recovery, both of which have significant drawbacks: Self-Service Password Reset (SSPR): Often relies on "weak" factors like SMS codes or security questions. These are easily intercepted or guessed and don't help a user who is trying to move away from passwords entirely. The Help Desk: Requires an agent to "vouch" for a user. Attackers can impersonate employees, use voice-cloning technology, or provide leaked personal information to trick an agent into issuing a Temporary Access Pass (TAP). The new Entra flow removes the human element from the validation process, ensuring that the person regaining access is exactly who they claim to be. How the New Recovery Flow Works: The recovery process is built on the concept of "identity proofing," utilizing government-issued documents and biometric liveness checks. Integration with Verification Partners Microsoft doesn’t store your passport or driver's license. Instead, Entra integrates with specialized Third-Party Identity Verification providers (such as True Credential, IDEMIA, AU10TIX). These services are experts in forensic document analysis. The Verification Process When a user begins a recovery, they are redirected to the partner service. The process typically involves: Document Capture: The user takes a photo of a government ID (Passport, Driver’s License, etc.). Forensic Analysis: The service checks for security features like holograms, fonts, and watermarks to ensure the ID is genuine. Liveness Check: The user takes a "selfie" or video. The system uses "Face Check" technology projecting specific light patterns or colors on the user’s face to ensure it is a live person and not a photo, video, or deepfake. Issuance of a Verified ID Once the third party confirms the user's identity, Microsoft Entra issues Verified ID. This is a decentralized, digital credential that sits in the user's Microsoft Authenticator app. It serves as digital proof of their identity that Entra can trust. The Final Handshake: Face Check To bridge the gap between the digital credential and the person at the keyboard, Entra performs a Face Check. It compares the live user's face against the photo contained within the Verified ID. If they match, Entra considers the identity "proven." Bootstrapping the New Device Once verified, Entra automatically issues a Temporary Access Pass (TAP). This allows the user to log in and immediately register their new device, passkey, or Authenticator app, effectively "bootstrapping" their new secure environment without ever speaking to a human. Strategic Advantages for IT Leaders Zero Trust Maturity: This process fulfills the Zero Trust requirement of "explicit verification" even during the recovery phase. Scalability: By automating the most time-consuming part of help desk tickets identity verification IT teams can focus on more complex tasks. Phishing Resistance: Because the recovery is tied to physical ID and biometrics, there is no "code" for an attacker to phish. Global Compliance: Leveraging government-issued IDs allows organizations to meet high-bar regulatory requirements for identity assurance (such as NIST IAL2). Deployment and Prerequisites To implement this, administrators need to ensure a few things are in place: Verified ID Setup: You must configure Microsoft Entra Verified ID within your tenant. Matching Logic: Entra uses attributes like First Name and Last Name to match the Verified ID to the user account. Ensuring your HR data is clean and synchronized is essential. License & Costs: While the recovery flow is a feature of Entra, the verification partners and the Face Check service (typically a per-check fee) must be provisioned through the Microsoft Security Store. Conclusion The transition to a passwordless world is incomplete if the "back door" (recovery) remains open and insecure. By integrating government-grade identity verification directly into the login flow, Microsoft Entra provides the final piece of the puzzle: a recovery method that is as secure as the primary login itself.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.Entra Group Source of Authority CONVERSION: Enabling Cloud-First Identity Management
As organizations modernize their identity infrastructure, Microsoft Entra’s Group Source of Authority (SOA) Conversion feature enables a granular migration of group management from on-premises AD to Microsoft Entra ID without disabling sync or rearchitecting the entire directory. What Is Group Source of Authority? Group SOA defines where a group object is mastered either in on-prem AD or in Entra ID. With SOA conversion, administrators can selectively convert AD-synced groups into cloud-native groups, making them editable and governable directly in Entra ID. Permissions Required To perform SOA conversion, the following Microsoft Entra roles and Graph API permissions are required: Hybrid Administrator: Required to call Microsoft Graph APIs to read and update SOA of groups. Application Administrator or Cloud Application Administrator: Required to grant user consent to the app or Graph Explorer. Graph API Permission Scope: Group-OnPremisesSyncBehavior.ReadWrite.All must be granted to the app calling the onPremisesSyncBehavior endpoint. Prerequisites Before initiating SOA conversion, ensure the following: Licensing Microsoft Entra Free or Basic license is sufficient. Sync Clients Microsoft Entra Connect Sync: Minimum version 2.5.76.0 Microsoft Entra Cloud Sync: Minimum version 1.1.1370.0 Group Eligibility Groups must not be mail-enabled or tied to Exchange on-premises (DLs or MESGs). If provisioning back to AD is planned, change group scope to Universal. How to Convert Group SOA from AD to Entra Here’s a simplified step-by-step guide: Identify Target Groups Use Entra Admin Center or Graph Explorer to list synced groups. Confirm they are not Exchange-dependent. Grant Permissions Use Graph Explorer or your app registration to grant Group-OnPremisesSyncBehavior.ReadWrite.All. Execute SOA Conversion If we see Group1, which is in scope of conversion is synchronized from on-prem. Execute the below from Graph Explorer to convert “Group1” to cloud managed PATCH https://graph.microsoft.com/beta/groups/{group-id}/OnPremisesSyncbehavior { "isCloudManaged": true } We can verify the change by executing below query on Graph API Explorer This marks the group as cloud-managed. AD sync will stop honoring changes to this group. Validate Conversion Confirm blockOnPremisesSync = true in the Entra Admin Center. Use audit logs to verify the change. Apply Governance Apply lifecycle policies, access reviews, and provisioning rules using Entra ID Governance. Use Cases: Migrating from On-Prem to Cloud Use Case 1: Retiring Legacy AD Groups Scenario: A customer has migrated all mailboxes to Exchange Online and no longer needs certain AD groups. Solution: Convert those groups to cloud-native Entra ID groups and delete them from AD, reducing footprint and simplifying governance. Use Case 2: Governing On-Prem Apps from the Cloud Scenario: A customer uses AD security groups to secure on-prem apps (e.g., Kerberos-based apps). Solution: Convert the group SOA to Entra ID, apply governance policies, and use Group Provision to AD to sync cloud-managed groups back to AD. Use Case 3: Migrating DLs and MESGs to Cloud Scenario: A customer wants to migrate all distribution lists and mail-enabled security groups to the cloud. Solution: Convert SOA to Entra ID, recreate mail-enabled groups in Exchange Online, and decommission AD-based mail groups. Use Case 4: Enabling Access Reviews Scenario: A federal customer wants to run access reviews on group memberships but the groups are AD-synced. Solution: Convert SOA to Entra ID, enabling full access review capabilities and lifecycle workflows. Use Case 5: Hybrid Identity Cleanup Scenario: A customer is migrating from Entra Connect Sync to Cloud Sync and wants to clean up group sprawl. Solution: Use SOA conversion to move group management to the cloud, then decommission legacy sync rules and OUs. Strategic Impact Group SOA Conversion is more than a technical enhancement, it’s a strategic enabler for identity modernization. It supports: AD DS minimization: Shrinking on-prem footprint. Cloud-first governance: Centralized access control and lifecycle management. Phased migration: Avoiding disruption while modernizing.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.Passwordless 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!
