Cloud Management Gateway Choices

Cloud Management Gateway Choices

In most ways, a Cloud Management Gateway (CMG) in Microsoft Endpoint Configuration Manager (ConfigMgr) greatly simplifies any organization’s path to managing their Internet-connected Windows systems. Namely, you don’t have to worry about adding any on-premises infrastructure. You also don’t have to talk to the network or security folks (although you still probably should even if they aren’t your best friends).

One way that a CMG is more complicated though is in the multiple possible choices that you can use to fulfill the prerequisites. If you’re not paying attention to the details in the official documentation, it’s pretty easy to confuse the requirements, mistakenly conflate them, or miss an important condition.

The Choices

There are three sets or categories of choices detailed below with some possible interdependencies based on the choices. These choices are specific to system management and machine policies only.

Client Authentication and Authorization

There are three choices here for systems connecting from the Internet. As implied by the name, this provides authentication or authorization of the client systems by the CMG and the site. These are more or less documented at Certificates for the cloud management gateway – – Client authentication certificate.

  1. Unique, PKI-issued client authentication certificate on each system.
  2. Azure Active Directory (AAD) or Hybrid Azure Active Directory (HAAD) domain-joined systems.
  3. A ConfigMgr issued token (this is brand new in ConfigMgr 2002 and requires the 2002 client agent; see Token-based authentication for cloud management gateway).

A client agent only chooses one method at a time, but different clients can use different methods. If a specific client happens to fulfill multiple of the above requirements, the agent will prefer them in the order listed.

CMG Authentication

This enables authentication of the CMG by the clients and secures the communication channel between the two using HTTPS. This is done using a PKI-issued, server authentication certificate from one of two sources:

  1. A public certificate authority (CA).
  2. An internal CA.

There is no technical difference between these two choices; the only practical difference is that your clients will automatically trust a certificate issued from a public CA (assuming you use a reputable public CA that is).

Management Point Authentication of Clients

There are two choices here; each has different implications though. The choices here also facilitate secure communication between the Management Point (MP) and the CMG service in Azure (although each accomplishes this in a slightly different manner).

  1. An HTTPS MP with a PKI-issued, server authentication certificate from an internal CA.
  2. An HTTP MP configured with Enhanced HTTP (HTTP).

User policy is slightly different and not specifically included in the details presented above. For user policy requirements on CMG connected systems, AAD authentication of the user must occur which requires the device to be HAAD or AAD domain-joined. See Deploy user-available applications on Azure AD-joined devices for additional requirements for available, user-targeted deployments.

Interdependencies

There are some interdependencies for the above sets of choices so it’s not quite as simple as choosing one from each. The following table depicts these interdependencies.

MP AuthClient AuthCMG Auth
HTTPS MPAnyBoth
eHTTPAAD/HAAD domain-join
ConfigMgr Token
Both
CMG Auth Interdependancies

The above table is a simplified, CMG-specific version of the table at Communications between endpoints in Configuration Manager — Client to management point communication.

Frequently Asked Questions

Q. Does using eHTTP mean we don’t have to do anything on the clients?
A. No. At least not until you get your clients up to 2002 in which case they will be automatically issued a token. Until you get your clients to 2002, they will still need to be AAD/HAAD joined.

Q. Does using eHTTP mean we don’t need a trusted certificate on the CMG?
A. No. You must have a server authentication certificate for the CMG and it must be trusted by all systems involved. Using a certificate from a public CA is generally the easy button solution to this.

Q. How can you make clients trust a CMG certificate issued from an internal-PKI if they cannot connect to the internal network?
A. This is a question outside the scope of ConfigMgr, but one possibility is to use Intune. ConfigMgr + Intune = Better Together.

Q. What if my PKI is only publishing the CRL to Active Directory.
A. Stop using that PKI; it was poorly designed. Use one of the other two methods: AAD/HAAD domain-joined or token.

Q. What if my PKI is not publishing the CRL to the Internet.
A. There are multiple possible paths here and most are PKI dependent. The easiest is to disable CRL checking in ConfigMgr; check with your security folks if this is acceptable though.

Q. Should I switch away from using internally-issued certificates to AAD/HAAD joined or tokens?
A. Not necessarily. In the grand scheme of the Microsoft ecosystem, AAD/HAAD domain-joining your devices is a good thing though and is a requirement for a lot of other functionality including Hello for Business, Conditional Access, and Co-management.

Q. Is one of these methods more secure than the others?
A. That’s a question for your security folks. Using PKI-certs is generally considered more secure for most things, but if your PKI itself is poorly designed or is insecure, then so will ConfigMgr’s use of it. Microsoft has designed each method to be secure and each should be considered secure. Security isn’t an absolute though and each choice should be evaluated based on your organizational standards and policies.

Q: Does the CMG connection point require the client auth cert? 1Contributed by David Paunovic
A. That depends. If the MP is configured for HTTPS and the clients are using a PKI issued client auth cert, then yes. If the MP is configured for eHTTP or the clients are AAD/HAAD joined or tokens, then no.

Q. What if my devices can’t currently connect to my ConfigMgr site but everything is already configured; i.e., the CMG is up and operational, the MP is properly configured, and the clients have a PKI client authentication cert or are AAD/HAAD joined? How do I tell the clients to start using the CMG?
A. If you have a way to modify the registry, add the following values to HKLM\Software\Microsoft\CCM in the registry and restart the client agent:

  1. CMGFQDNs (string): FQDN of the CMG
  2. DisAllowCMG (dword): 0

Review the locationservices.log for details after setting these values.

Additional Referencesc

Footnotes   [ + ]

1. Contributed by David Paunovic

4 Comments

Cancel

  1. Hi ¡¡¡

    nice post, I’m trying to set up a CMG using an internal PKI.

    I issued the certificate, and when setting up the service on MEMCM, I upload also the CA root.

    all is done and testings are right on connection analyzer, I’m able to connnect to the server via RDP …

    But clients failed to connect with a certificate error …

    [CCMHTTP] ERROR INFO: StatusCode=401 StatusText=CMGService_Invalid_Client_Certificate

    Do you know waht could it be ?

    Thank you

    • Hi Carlos,

      The issue is there in your error: CMGService_Invalid_Client_Certificate

      This could be for one of many reasons including the CRL being inaccessible, the PKI that issued the cert not being trusted, the certs being expired, etc. Without direct examination, that’s the most that can be said.

  2. Thank you for the clear post. We have a CMG enabled and our workstatons are Hybrid AD joined.
    How are your Client Settings configured? In our environment, the clients only use the CMG when it is allowed in the Default Client Settings. When we define it there, it works. But that is not our way forward, as we have many systems that should not access the CMG.
    We have a Custom Client Setting for allowing the CMG which is deployed on our workstations, but it is not applying the Cloud Services setting correctly. The DisAllowCMG stays stuck on 1. (Resultant Client Settings says it is allowed, however, when I check with PolicySpy I can see the settings for Cloud Services is not being applied). Other settings in the workstations policy just work.
    Any ideas?