CMG token based authentication with ConfigMgr 2002

A few years ago we were first introduced to the Cloud Management Gateway. It was a revolutionary new feature allowing us to manage all supported ConfigMgr clients over the internet. At that time the solution required that you configure a PKI solution so that the clients could communicate with the management point over https. Microsoft recognised that this was challenging for some organizations so, from version 1806, Azure AD joined Windows 10 devices could communicate with the management point over http (as long as we enabled enhanced http).

However that still didn't suit all organizations. Some organizations weren't ready for PKI or Azure AD join implementations and still needed to manage Windows 7 devices. ConfigMgr 2002 was generally released last week and includes a real game-changer. We can now used token-based authentication for communication between internet clients and the management point over http. The amazing thing here is that we don't have to do anything additional on the management point or client. All this works out of the box when you upgrade the ConfigMgr site to version 2002. Remember you MUST actually upgrade the clients to 2002 as well.

There are two scenarios and we'll look at both.

• clients that can register on the internal network
• clients that are always internet-based

Internal network

This is easy. It just works out of the box. When you upgrade a client to 2002 it will immediately register with the management point.

In the ClientIDManagerStartup.log file you will see the client receiving it's self-prove token from the management point.

This is a ConfigMgr 2002 client on the intranet. You will see that it is not configured for PKI (otherwise you would see Client certificate: PKI). It uses a self-signed client certificate (and the self-prove token behind the scenes).

The client is not Azure AD joined.

Now the client roams to the internet. It pairs it's self-signed certificate with the management point-issued self-prove token to communicate with the CMG.

The client is now aware of the CMG.

In the CcmMessaging.log file we can see the client receiving a CCM token which allows the communication to continue.

In the ConfigMgr console we can now see that the client is being managed over the internet.

An important thing to note is that the client renews the token once a month and it is valid for 90 days.

Internet-based

What can we do with clients that are already internet-based? We won't be able to automatically upgrade the client to 2002 and the client won't be able to register with the management point immediately and get the self-prove token. In this case we can use the bulk registration token.

Navigate (as administrator) to the \bin\x64 folder of the ConfigMgr installation directory on the site server.

Run the tool by executing: 

BulkRegistrationTool.exe /new

The token is generated. Remember this token has a short-validity period so you should use it straight away.

Copy the token.

Now install the ConfigMgr client on the internet-based device using the additional /regtoken parameter. I've done it manually by copying the installation files to the device and executing this command:

ccmsetup.exe /mp:https://GerryHCMG.emslab.ie/CCM_Proxy_MutualAuth/72186325152220500 CCMHOSTNAME=GerryHCMG.emslab.ie/CCM_Proxy_MutualAuth/72186325152220500 SMSSiteCode=GER SMSMP=https://MEM.hampson.local /regtoken:eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1XUldSbUtVQlZjNlJDSGpCTjQyZnhvZUdEMCJ9.eyJTQ0NNVG9rZW5DYXRlZ29yeSI6IlNDQ01QcmVBdXRoVG9rZW4iLCJBdXRob3JpdHkiOiJTQ0NNIiwiTGljZW5zZSI6IlNDQ00iLCJUeXBlIjoiQnVsa1JlZ2lzdHJhdGlvbiIsIlRlbmFudElkIjoiN0IwQzM4MDYtRDI4Qy00QTQ1LUFEQjItRkI5Rjk0QTQ2MkY4IiwiVW5pcXVlSWQiOiJlYTJmYzUxMC1hM2JlLTRjZWYtOTBiMC0yYTA1MTVjNGU0MGMiLCJpc3MiOiJ1cm46c2NjbTpvYXV0aDI6N2IwYzM4MDYtZDI4Yy00YTQ1LWFkYjItZmI5Zjk0YTQ2MmY4IiwiYXVkIjoidXJuOnNjY206c2VydmljZSIsImV4cCI6MTU4OTcwMTUxOCwibmJmIjoxNTg5NDQyMzE4fQ.Y-6s6_h18cnIZP8OPqdjpxQHUhg_4srICehX5xOfym5AcyQRC3wlN89PAByFD2gfp6QvV7gXX9H7oG198UGHhUuJrthAipSo4KNCSr8t7TcZwjR9awt720tErf9aiflBKnFibAYAGU9xBS3UYTetQ6XYpdh0XsCedsbh0-6ilj6KmP1qWBFIYNkBaL3oP_HJhX02de0wqeh-fWiTtdvbKnOxDrGetoCKsEVp3sJumprzWHZ6ZpRD3powG3AUOOSbAW96c_driDvzwC6x6hoWOo4GPEs-BaoJUdRzi1htY9IJB2X_drIQqLH8X0Ps6B5H5-KGH3gB0tJA45WwERuLxA

As before you will see the client getting it's CCM token from the CMG in the ClientIDManagerStartup.log file.

The client is installed.

In the ConfigMgr console we can see that the device is managed by the CMG over the internet.

There are obviously a few challenges in this scenario:

How does the remote user get the ConfigMgr 2002 client installation files?

I plan to use this scenario in production and I intend to copy the files and installation instructions to OneDrive to make available to users.

How can the user install the client if they are not a local administrator?

This one is more challenging. The users will need some assistance with elevated rights, possibly using screen-sharing software. This also highlights a great use case for a solution like Local Administrator Password Solution (LAPS).

I think this feature will be extremely useful so I hope this walkthrough was helpful.

Until next time......

CMG Name Resolution Failure

This was an issue I encountered recently. I had added a CMG but there were errors in the CMG Connection Analyzer.

I always advise my customers to secure the CMG using a public SSL certificate. This involves using an externally routable domain and creating a CNAME record to direct requests to the CMG (ghcmg.emslab.ie -> ghcmg.cloudapp.net for example, all the screenshots below are examples, not from the customer). 

I had already configured the CNAME record with the domain hosting company and it could resolve externally. This is what it should look like. The DNS name should resolve but it doesn't matter that there is no ping response. That is normal.

However the CMG Connection Analyzer still failed with the error:

"Failed to connect to the CMG service. Unexpected response status code is NameResolutionError. For more information, see SmsAdminUI.log".

I carried out some troubleshooting and saw that the CNAME resolution did not work from the Primary Site server. At that point I realized that the customer was using split DNS. In a split DNS infrastructure, you create two zones for the same domain, one to be used by the internal network, the other used by the external network – typically users on the Internet. Split DNS directs internal hosts to an internal domain name server for name resolution and external hosts are directed to an external domain name server for name resolution.

The solution was to also add the CNAME record to the internal DNS zone.

Right click the zone and choose New Alias (CNAME).

Enter the details for the alias.

All was good for the CMG.

Until next time....

CMG - the subscription is not registered to use namespace 'Microsoft.Storage'

This was a new issue for me to fix when deploying a CMG last week. 

The first attempt failed - "Failed to provision cloud service".

The CloudMgr.log file was full of information and told me what I needed to know.

"The subscription is not registered to use namespace 'Microsoft.Storage'".

I could see the same in the Azure Activity log.

This was a little unusual for me as I hadn't come across this problem before. I know that I have to register the Classic.Compute resource provider (this one has it's own issues in that it's not exposed in a CSP subscription) but I've never seen a problem with the Microsoft.Storage resource provider.

As usual I found that it was specifically called out in the official docs.

"The Microsoft.ClassicCompute & Microsoft.Storage resource providers must be registered within the Azure subscription".

I registered the Microsoft.Storage resource provider.....

....and was able to deploy the CMG.

I hope this helps you. Until next time......

Take care when choosing CMG service name

I bumped into this challenge last week and, although it's easy to solve, it can be a nuisance and can cause delays to your CMG project.

I always advise my customers to secure the CMG using a public SSL certificate and, of course, one of the first questions is what name will be used on the certificate. It doesn't really matter what name you choose as long as it's unique in Azure, or so I thought. That's only part of the requirement. 

I encountered this error message when configuring the CMG where the customer had used a dash (or hyphen) in the name. It looks like that is not supported. The service name should be between 3 and 24 characters in length and should only have letters or numbers. 

I decided to do a little digging and of course I found this in the official docs

"If you will also enable the CMG for content, confirm that the CMG service name is also a unique Azure storage account name. If the CMG cloud service name is unique, but the storage account name isn't, Configuration Manager fails to provision the service in Azure. Repeat the above process in the Azure portal with the following changes:

• Search for Storage account
• Test your name in the Storage account name field

The DNS name prefix, for example GraniteFalls, should be 3 to 24 characters long, and only use alphanumeric characters. Don't use special characters, like a dash (-)".

I had a look.

Yes the cloud service can contain a dash.

But no special characters are allowed for the storage account. I'll know for the next time :)

It was easy to recover from this and we requested a new certificate. It delayed the project a bit but the CMG is now safely deployed.

I hope this helps. Until next time.....