Expired Cloud Management Gateway server authentication certificate

Let’s start this new year with a short blog post about the Cloud Management Gateway (CMG). More specifically, about replacing an (expired) server authentication certificate on the CMG. The server authentication certificate is a required certificate for the CMG. That certificate is used to build the secure channel that is used with the created HTTPS service. The HTTPS service is were the internet-based clients connect. This certificate should come from a public provider, or from a public key infrastructure (PKI). In this post I’ll have a quick look at how to prevent the expiration of the server authentication certificate and how to replace the server authentication certificate.

Certificate expiration

The most important thing to note is – like with everything else – that prevention is better than cure. In this case: make sure that the certificate is replaced before it expires. Of course it still happens that – for whatever reason – the certificate is forgotten. In that case the Configuration Manager site will keep on working, but the clients that are managed over the Internet via the CMG, will loose their connection with the Configuration Manager site. The clients will show behavior in the CcmMessaging log that includes the messages shown below.

It includes the messages WINHTTP_CALLBACK_STATUS_SECURE_FAILURE and WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID, which both imply that something is wrong with the server certificate (see also the docs for some more details).

As mentioned, prevention is better than cure. At this moment Configuration Manager will not provide any alerts about the expiration of the CMG server authentication certificate. That doesn’t mean that there are no methods available for verifying the expiration of the certificate. When working with a solid third-party certificate provider, warnings will arrive months, weeks and days ahead of the expiration date. Ignoring those messages is nearly impossible (unless managed by a different team). When not willing to rely on a third-party, looking in the Azure portal is a very good alternative. Navigate to the cloud service of the CMG and select Certificates. That section will provide an overview of the certificates that belong to the cloud service. An example is shown below.

Of course this can also be automated by looking at PowerShell and/or the Azure Management API. That API contains the certificate URI for a resource group, which can be used for automation purposes.

Replace the certificate

The actual replacement of the (expired) CMG server authentication certificate should be pretty straight forward and can be achieved by following the next three steps.

  1. Open the Microsoft Endpoint Configuration Manager administration console and navigate to Administration > Overview > Cloud Services Cloud Management Gateway
  2. Select {YourCMG} and click Properties in the Home tab to open the {YourCMG} Properties dialog box
  3. In the {YourCMG} Properties dialog box, navigate to the Settings tab, browse to (and select) the new certificate and click OK

Note: In my case I noticed that it wasn’t as straight forward as I thought. The deployment in Azure would fail with the message that the certificate with the new thumbprint was not found. I could address this challenge by manually uploading the certificate with the cloud service in Azure and again performing the mentioned steps. Performing those steps again will make sure that the correct actions are performed with the new certificate.

After a successful deployment of the cloud service the, earlier mentioned, Certificates section of the cloud services will show the new certificate and, in my case, show the old and expired certificate.

Also, it’s good to know that when the CMG server authentication certificate was actually expired, the clients will automatically start communicating again once the certificate is replaced.

More information

For more information about the certificates for the CMG, please refer to the documentation Certificates for the cloud management gateway.

Enabling the ConfigMgr administration service through the cloud management gateway

This week is all about the administration service in Configuration Manager. More specifically, about enabling the Configuration Manager administration service via the cloud management gateway (CMG) to make it available over the Internet. The administration service provides API interoperability access to WMI over HTTPS via the SMS Provider. This REST API can be used in place of a custom web service to access information of the Configuration Manager site. Some really good information and starting points about this subject can be found at this blog post by Adam Gross. In this post I’ll skip the basics and specifically look at making the administration service available over the Internet. I want to provide in my own style what the configuration requirements are and why they are needed. I’ll start this post by showing the required configurations in Configuration Manager and in Azure AD and I’ll end this post by retrieving the most common parameters for scripting.

Before starting with the actual configurations, I want to post a little thank you message: Thank you Sandy for answering my (dumb) questions while I should simply read better.

Configuring the SMS Provider properties

The administration service is available with the installation of the SMS Provider. Every site system with an SMS Provider has the administration service. Before being able to enable the SMS Provider over the CMG, the following prerequisites should be in-place:

  • The server that hosts the SMS Provider role requires .NET 4.5.2 or later
  • Enable the SMS Provider to use a certificate, by either using Enhanced HTTP or by manually binding a PKI-based certificate on the server that hosts the SMS Provider role
  • A running CMG (as I’m not going through that installation)

When those prerequisites are in-place, the SMS Provider can be configured to allow CMG traffic for the administration service by following the next three steps.

  1. Open the Configuration Manager administration console and navigate to Administration > Overview > Site Configuration > Servers and Site System Roles
  2. Select the server that hosts the SMS Provider role, select the SMS Provider role and click Properties in the Site Role tab to open the Provider role properties dialog box
  3. On the Provider role properties dialog box, select Allow Configuration Manage cloud management gateway traffic for administration service and click OK

Register a new app with Azure AD

For accessing the administration service via the CMG, two apps must be created within Azure AD, 1) a Web app (also known as a Server app within Configuration Manager) that is used for making the administration service available and 2) a Native app (also known as a Client app within Configuration Manager) that is used for obtaining an access token for the user. That access token can be sent in a request to the Web app, which authorises the user and returns the administration service.

During the creation of the cloud services within Configuration Manager a Web app and a Native are already created. I need to (and can) access the administration service via that created Web app, but I don’t want to reuse the existing Native app as I need to make some adjustments and I don’t want to interfere with existing functionalities. The following steps walk through the registration and configuration of a new Native app with the required configurations to obtain and access token for the user and be able to sent that token in a request to the Web app.

  1. Open the Azure portal and navigate to Azure Active Directory  > App registrations to open the App registrations blade
  2. On the App registrations blade, click New registration to open the Register an application blade
  3. On the Register an application blade, provide the following information (as also shown below) and click Register
  • Name: Provide a valid name for the Web app (in this post: ConfigMgrAdminService)
  • Supported account types: Select Accounts in this organisational directory only ({yourTenant} only – Single tenant)
  • Redirect URI (optional): Select Public client/native (mobile & desktop) and provide https://login.microsoftonline.com/common/oauth2/nativeclient as Redirect URI

Note: The mentioned redirect URI, is the latest recommended value for desktop applications running on Windows (see also: https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-desktop-app-registration).

  1. After the registration of the app, navigate to Authentication to open the Authentication blade
  2. On the Authentication blade, navigate to the Default client type section and select Yes with Required for the use of the following flows where a redirect URI is not used (as shown below) and click Save
  1. Navigate to API permissions to open the API permissions blade
  2. On the API permissions blade, click Add a permission to open the Request API permissions blade
  3. On the Request API permissions blade, select APIs my organisation uses and select the Web app – the standard name of that app is ConfigMgrService (as shown below) – that was initially created during the setup of the cloud services to open the specific API permissions blade
  1. On the specific API permissions blade, select Delegated permissions, select user_impersonation and click Add permissions (as shown below) to return to the API permissions blade
  1. On the API permissions blade, select Grant admin consent for {yourTenant} (as shown below

Retrieve the parameters to start with PowerShell

After configuring the SMS Provider properties, registering and configuring the Native app, the administration service is available via the CMG. The next step is to actually externally connect with the administration service. However, this might be an open door, but before doing that it’s good to understand that the user that is authentication and connecting with the administration service must have sufficient permissions within Configuration Manager.

At this moment I won’t provide an example, that might be something for a future post, but for now I’ll refer to this great post by Zeng Yinghua (also known as Sandy) and this repository about the Microsoft Graph (as the idea for retrieving a token is the same). The main challenge in any of those scripts is getting the token. To successfully achieve that, the following information is often required.

  1. Application (client) ID of the Native app that is named ConfigMgrAdminService in this post. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrAdminService > Overview (shown in the figure below with number 1).
  2. Tenant ID of the Native app that is named ConfigMgrAdminService in this post. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrAdminService > Overview (shown in the figure below with number 2).
  3. Redirect URI of the Native app that is named ConfigMgrAdminService in this post. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrAdminService > Overview (shown in the figure below with number 3) or copying the information that was provided in step 3 during the registration of Native app in Azure AD.
  1. Application ID URI of the Web app that is named by default ConfigMgrService. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrService > Overview (shown in the figure below with number 4)
  1. External URL of the administration service. That information can be the easiest retrieved in SQL by using the query below on the ConfigMgr database
select ExternalEndpointName, ExternalUrl from vProxy_Routings
where ExternalEndpointName = 'AdminService'

More information

For more information about Configuration Manager administration service, please refer to the documentation about the SMS Provider.