In this comprehensive guide, we delve into the Cloud Management Gateway (CMG) within Microsoft Configuration Manager (ConfigMgr). Our goal is to empower ConfigMgr administrators by providing insights and practical instructions for understanding and configuring CMG effectively. CMG acts as a gateway for internet clients to communicate with on-premises Configuration Manager infrastructure.
The series is a collaborative effort between Herbert Fuchs, a Cloud Solution Architect, and Beatriz Moran Serrano, an experienced Escalation Engineer.
Before we embark, here's a quick reminder: the CMG operates as Software as a Service (SaaS), leveraging Platform as a Service (PaaS) components. It's crucial to note that any modifications to this service outside the ConfigMgr API are not supported.
CMG FAQ - Configuration Manager | Microsoft Learn
This feature and its requirements are extensively documented and can be found here:
Cloud management gateway overview - Configuration Manager | Microsoft Learn
Entra Application Registration
Before setting up a CMG, it's imperative to configure an Azure service for cloud management:
During this process, you'll need to configure two Azure Application Registrations. You can opt to create these through the user interface or have an Azure administrator set them up beforehand by providing them the necessary details at Manually register Microsoft Entra apps - Configuration Manager | Microsoft Learn.
In either scenario, possessing the privileges of a Global Administrator is essential for creation, which is a one-time requirement at the time the application registrations are created. Over the years, I've encountered amusing scenarios like Teams calls routed through multiple servers just to access the ConfigMgr server, highlighting the importance of proper administrative access. If you've experienced similar challenges, I recommend exploring Privileged Identity Management (PIM).
What is Privileged Identity Management? - Microsoft Entra ID Governance | Microsoft Learn
The WebApp Application Configuration
Regardless of the method chosen, you'll end up with two Application Registrations: one for the web app and another for the client app.
The WebApp application is an integral part of the CMG setup. It comes equipped with a Client Secret, Application ID URI, and strict restrictions against public client flows. This information is securely stored within the ConfigMgr Database, including the secret. To view these details stored in the ConfigMgr database, use the following example SQL query:
SELECT * FROM AAD_Tenant_Ex tenant
INNER JOIN AAD_Application_Ex app ON tenant.ID = app.TenantDB_ID AND app.IsClientApp = 0
INNER JOIN AAD_CloudServiceApplicationRelations asso ON asso.AADApplicationID = app.ID
INNER JOIN Azure_CloudService service ON service.ID = asso.ID
WHERE service.ServiceType = 3
These configurations facilitate authentication to Azure and enable automated processes such as the CMG ARM Template deployment. The acquisition of the authorization token follows the OAuth 2.0 authorization code flow model. See Microsoft identity platform and OAuth 2.0 authorization code flow - Microsoft identity platform | Mi... for a deeper look at OAuth in Azure.
With only one API permission configured, namely Directory.Read.All, the WebApp is granted access to read user, group, and device resources within Azure. This permission can only be granted by a Global Administrator. See Microsoft Graph permissions reference - Microsoft Graph | Microsoft Learn for complete deletes on Graph permissions.
Additionally, the WebApp exposes the API to a custom scope to restrict access to data and functionality protected by the API. Creating a scope here only grants delegated permissions, particularly for the Client-App.
Client App Functionality
The client app serves as the service principal facilitating communication with the server app. While the server app exposes the API, the client app enables seamless interaction with the exposed API. It holds permission to access the API exposed by the server app.
For security reasons, the server app cannot be implemented on clients. Instead, clients utilize the client app without storing any secrets, allowing them to request access to Entra ID and delegate permissions from the server app. When the ConfigMgr client initiates a request to Azure for a token, it utilizes the Native App ID alongside the server app URI.
[Example: Getting AAD (device) token with: ClientId = a0cf002e-40bf-4327-9caf-b59cc916ba6e, ResourceUrl = api://a8d6314d-b475-4f0b-a5da-2a768405e86a/955bc496-6637-4de9-8777-9689914b23e1, AccountId = https://login.microsoftonline.com/, Null parent window handle = true]
This process is only triggered if the device is in an Entra or Entra hybrid joined state. In cases where HTTPS-Only mode is enabled, authentication is facilitated through the client certificate. However, it's crucial to note the limitations of this setup; for instance, deploying applications to users is feasible without a hybrid or modern device identity configuration.
Also, it is important to note that the credentials provided for the app registration information create an association to your Entra ID Tenant.
The Cloud Management Installation
We've completed the initial prerequisites with the app registrations in Entra. However, to utilize and install the Cloud Management Gateway, we also require an Azure Subscription. Configuring Resource Providers is crucial for enabling this feature as called out at Configure Microsoft Entra ID for CMG - Configuration Manager | Microsoft Learn these include the following:
- Microsoft.KeyVault
- Microsoft.Storage
- Microsoft.Network
- Microsoft.Compute
When initiating the Installation wizard for the Cloud Management Gateway using the ConfigMgr console, you'll encounter a list of configured Azure Active Directory Tenants and their associated WebApps. To select a Subscription, you must provide User Credentials with Owner Privileges at the Subscription Level. This role is essential as it's the only one capable of assigning RBAC Permissions. This privilege is only necessary once. As soon the Installation of the Cloud Management Gateway is successful you can remove this privilege. See Azure built-in roles - Azure RBAC | Microsoft Learn for more info.
Attention: Our Support Teams also faced situations, because of Azure-Policy-Restrictions where it was necessary to assign the classic Co-Administrator. However, keep in mind that classic resources and administrators will retire soon as called out at Azure classic subscription administrators | Microsoft Learn.
Within the wizard, you also specify the new or existing Azure Resource Group in which the Cloud Management Gateway will be configured. On this Resource Group, the wizard sets the Contributor Permission for a pre-configured Web Application.
It's important to note that when using a Subscription with numerous Resource Groups, the Wizard might not display all Resource Groups in the drop-down list. In such cases, you have two options: create a new Resource Group via the User Interface Wizard or utilize Configuration Manager cmdlets to set up the CMG. The following example PowerShell snippet is for this latter option:
$PW = ConvertTo-SecureString -AsPlainText 'PFX-Password' -Force
New-CMCloudManagementGateway -GroupName 'FOXWORKS-CMG' -ServerAppClientId 'xxxxxxx-89aa-4e89-bc3b-21390772d7e9' -ServiceCertPath "C:\Certs\CMG\CMG.pfx" -ServiceCertPassword $PW -SubscriptionId 'xxxxxx-b5e2-485a-ab19-edfd79b58fe1' -VMSSVMSize StandardB2S -VMInstanceCount 1 -EnableCloudDPFunction $True -CheckClientCertRevocation $false -Region WestEurope
Our next key element in the wizard is the certificate bound to the WebServers in the Virtual Machine Scale Set (VMSS) which a CMG is built from. This is crucial for the Service name and Deployment name.
It's recommended to use a public certificate. The Deployment name is always linked to an Azure region. Since you cannot issue a certificate for a cloudapp.azure.com domain, configuring your DNS Servers (internal and external) to redirect a request for the Service name to the Deployment name. While a public certificate incurs additional cost, it eliminates concerns and issues with certificate trust as this is already available by default on Windows Systems for certificates issued from public authorities. For customers who previously used a public certificate for their Classic CMG, migrating to a VMSS simplifies the process. Otherwise, setting up an additional CMG and connector is required, followed by monitoring, and reporting to ensure all clients receive updated policies.
This blog post enhances understanding of CMG, helping ConfigMgr Admins address Azure and Security Teams’ queries about App Registrations. Continue learning in Part 2 of the series.
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.