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.Unlocking AI-Driven Data Access: Azure Database for MySQL Support via the Azure MCP Server
Step into a new era of data-driven intelligence with the fusion of Azure MCP Server and Azure Database for MySQL, where your MySQL data is no longer just stored, but instantly conversational, intelligent and action-ready. By harnessing the open-standard Model Context Protocol (MCP), your AI agents can now query, analyze and automate in natural language, accessing tables, surfacing insights and acting on your MySQL-driven business logic as easily as chatting with a colleague. It’s like giving your data a voice and your applications a brain, all within Azure’s trusted cloud platform. We are excited to announce that we have added support for Azure Database for MySQL in Azure MCP Server. The Azure MCP Server leverages the Model Context Protocol (MCP) to allow AI agents to seamlessly interact with various Azure services to perform context-aware operations such as querying databases and managing cloud resources. Building on this foundation, the Azure MCP Server now offers a set of tools that AI agents and apps can invoke to interact with Azure Database for MySQL - enabling them to list and query databases, retrieve schema details of tables, and access server configurations and parameters. These capabilities are delivered through the same standardized interface used for other Azure services, making it easier to the adopt the MCP standard for leveraging AI to work with your business data and operations across the Azure ecosystem. Before we delve into these new tools and explore how to get started with them, let’s take a moment to refresh our understanding of MCP and the Azure MCP Server - what they are, how they work, and why they matter. MCP architecture and key components The Model Context Protocol (MCP) is an emerging open protocol designed to integrate AI models with external data sources and services in a scalable, standardized, and secure manner. MCP dictates a client-server architecture with four key components: MCP Host, MCP Client, MCP Server and external data sources, services and APIs that provide the data context required to enhance AI models. To explain briefly, an MCP Host (AI apps and agents) includes an MCP client component that connects to one or more MCP Servers. These servers are lightweight programs that securely interface with external data sources, services and APIs and exposes them to MCP clients in the form of standardized capabilities called tools, resources and prompts. Learn more: MCP Documentation What is Azure MCP Server? Azure offers a multitude of cloud services that help developers build robust applications and AI solutions to address business needs. The Azure MCP Server aims to expose these powerful services for agentic usage, allowing AI systems to perform operations that are context-aware of your Azure resources and your business data within them, while ensuring adherence to the Model Context Protocol. It supports a wide range of Azure services and tools including Azure AI Search, Azure Cosmos DB, Azure Storage, Azure Monitor, Azure CLI and Developer CLI extensions. This means that you can empower AI agents, apps and tools to: Explore your Azure resources, such as listing and retrieving details on your Azure subscriptions, resource groups, services, databases, and tables. Search, query and analyze your data and logs. Execute CLI and Azure Developer CLI commands directly, and more! Learn more: Azure MCP Server GitHub Repository Introducing new Azure MCP Server tools to interact with Azure Database for MySQL The Azure MCP Server now includes the following tools that allow AI agents to interact with Azure Database for MySQL and your valuable business data residing in these servers, in accordance with the MCP standard: Tool Description Example Prompts azmcp_mysql_server_list List all MySQL servers in a subscription & resource group "List MySQL servers in resource group 'prod-rg'." "Show MySQL servers in region 'eastus'." azmcp_mysql_server_config_get Retrieve the configuration of a MySQL server "What is the backup retention period for server 'my-mysql-server'?" "Show storage allocation for server 'my-mysql-server'." azmcp_mysql_server_param_get Retrieve a specific parameter of a MySQL server "Is slow_query_log enabled on server my-mysql-server?" "Get innodb_buffer_pool_size for server my-mysql-server." azmcp_mysql_server_param_set Set a specific parameter of a MySQL server to a specific value "Set max_connections to 500 on server my-mysql-server." "Set wait_timeout to 300 on server my-mysql-server." azmcp_mysql_table_list List all tables in a MySQL database "List tables starting with 'tmp_' in database 'appdb'." "How many tables are in database 'analytics'?" azmcp_mysql_table_schema_get Get the schema of a specific table in a MySQL database "Show indexes for table 'transactions' in database 'billing'." "What is the primary key for table 'users' in database 'auth'?" azmcp_mysql_database_query Executes a SELECT query on a MySQL Database. The query must start with SELECT and cannot contain any destructive SQL operations for security reasons. “How many orders were placed in the last 30 days in the salesdb.orders table?” “Show the number of new users signed up in the last week in appdb.users grouped by day.” These interactions are secured using Microsoft Entra authentication, which enables seamless, identity-based access to Azure Database for MySQL - eliminating the need for password storage and enhancing overall security. How are these new tools in the Azure MCP Server different from the standalone MCP Server for Azure Database for MySQL? We have integrated the key capabilities of the Azure Database for MySQL MCP server into the Azure MCP Server, making it easier to connect your agentic apps not only to Azure Database for MySQL but also to other Azure services through one unified and secure interface! How to get started Installing and running the Azure MCP Server is quick and easy! Use GitHub Copilot in Visual Studio Code to gain meaningful insights from your business data in Azure Database for MySQL. Pre-requisites Install Visual Studio Code. Install GitHub Copilot and GitHub Copilot Chat extensions. An Azure Database for MySQL with Microsoft Entra authentication enabled. Ensure that the MCP Server is installed on a system with network connectivity and credentials to connect to Azure Database for MySQL. Installation and Testing Please use this guide for installation: Azure MCP Server Installation Guide Try the following prompts with your Azure Database for MySQL: Azure Database for MySQL tools for Azure MCP Server Try it out and share your feedback! Start using Azure MCP Server with the MySQL tools today and let our cloud services become your AI agent’s most powerful ally. We’re counting on your feedback - every comment, suggestion, or bug-report helps us build better tools together. Stay tuned: more features and capabilities are on the horizon! Feel free to comment below or write to us with your feedback and queries at AskAzureDBforMySQL@service.microsoft.com.
