Wednesday, 10 April 2019

Deploying CMG with Enhanced HTTP (my experience)

I've configured a number of Cloud Management Gateways in the past, both for customers and in lab environments. In each case I've added a Management Point and configured it to use HTTPS. I've had to do that to manage Windows 7 clients over the Internet using traditional PKI. Recently I rebuilt my ConfigMgr lab to prepare demos for MMS 2019. As I'll just be using Windows 10 it has given me the opportunity to try Enhanced HTTP for the first time. I had a few problems to figure out along the way (with the help of Nick Hogarth, thanks Nick) but, now that it is configured correctly, everything works really well.

So what is Enhanced HTTP all about?

Traditionally we've used PKI to secure communication in ConfigMgr environments. Microsoft still recommends using HTTPS communication for all Configuration Manager communication. However they recognize that it can be challenging for some customers due to the overhead of managing PKI certificates. By using Azure AD integration we can simplify the process using Enhanced HTTP. In this scenario Azure AD-joined devices can communicate with a management point configured for HTTP. The site server generates a custom certificate for the management point allowing it to communicate via a secure channel. You can read about it here

The ConfigMgr admin doesn't need to do any IIS configuration as this is done in the background. We'll see that shortly.

Enhanced HTTP implementation steps

There are a number of steps which I implemented as follows.

Management Point configured for HTTP client communication


Enable the site option to Use Configuration Manager-generated certificates for HTTP site systems.


The SMS Role SSL Certificate was automatically configured and bound to port 443.


Onboard the site to Azure AD for cloud management


Using the Azure Services wizard.

Configure Azure AD User Discovery


Configure Hybrid AD Join

I was using domain joined devices for testing so I needed to configure Hybrid AD Join. Hybrid AD Join is configured using Azure AD Connect. A Service Connection Point is created during the process.



"Configure device options" was selected.



"Configure Hybrid Azure AD Join" was selected.



The SCP was created.

No further action should have been required because, once Hybrid Azure AD Join is enabled, devices will automatically join to Azure AD by default from Windows 10 Version 1607.

What issues did I experience?

I experienced a couple of issues during the process. In each case it's because I had forgotten to do something.

Firstly my test client could not be detected on the Internet. There were several errors in the CcmMessaging and LocationServices log files.




[CCMHTTP] ERROR: URL=http://GERRYHAMPSON.EMSLAB.IE/CCM_Proxy_MutualAuth/72057594037927939/ccm_system/request, Port=0, Options=1248, Code=87, Text=<null>



Successfully queued event on HTTP/HTTPS failure for server 'GERRYHAMPSON.EMSLAB.IE'.

Post to http://GERRYHAMPSON.EMSLAB.IE/CCM_Proxy_MutualAuth/72057594037927939/ccm_system/request failed with 0x87d00231.




CCMHTTP] ERROR: URL=https://GERRYHAMPSON.EMSLAB.IE/CCM_Proxy_MutualAuth/72057594037927939/SMS_MP/.sms_aut?SITESIGNCERT, Port=0, Options=1248, Code=0, Text=CCM_E_NO_CLIENT_PKI_CERT

Raising event:
instance of CCM_CcmHttp_Status
{
 ClientID = "GUID:76F79FF6-FA18-4E15-AA2F-9A4E71711ACC";
 DateTime = "20190410064418.902000+000";
 HostName = "GERRYHAMPSON.EMSLAB.IE";
 HRESULT = "0x87d00454";
 ProcessID = 3104;
 StatusCode = 0;
 ThreadID = 5368;
};



Also the CMG Analyser failed (it was OK when run against a certificate but not against an Azure AD User).



Failed to get ConfigMgr token with Azure AD token. Status code is '403' and status description is 'CMGConnector_Un-authorizedrequest'.
A possible reason for this failure is the CMG connection point failed to forward the message to the management point. The management point returned the following error: 'Un-authorizedrequest'. Check the specified Azure AD user is successfully discovered.

Troubleshooting


I had to figure out what was wrong and this is where Nick helped me. First I looked at the CMG Analyzer error. It looked pretty clear. "Check the specified Azure AD user is successfully discovered".



Also I could see errors in the CCM_STS.log file on the site server.

AAD user with ID 26800541-daf1-4334-aca0-c1a7d5d25a72 and SID S-1-5-21-3695679697-2106157007-715799775-1106 is not completely discovered

I knew that Azure AD Discovery was enabled but I still couldn't see any users. After I rebuilt the site I had forgotten to enable AD User Discovery. This is also a requirement.



I did that and could successfully run the analyser.

I also had an issue with the test device. It should have automatically joined Azure AD but it didn't.



See the output of the dsregcmd /status command. AzureADJoined: NO



The output also gave more information: The device object by the given ID is not found.

I couldn't understand that. I had configured Azure AD Join in Azure AD Connect which should have synchronized all the computer objects to Azure AD.



I had a look at the Azure AD Connect configuration again and realized that I had forgotten to select the Workstations OU to synchronise. I didn't need to before. I was only interested in users at the time.



After synchronization the device joined to Azure AD.


No more errors in the LocationServices.log file.....


...and in the ConfigMgr console the device was Online over the internet.


It could also be seen as a Hybrid Azure AD joined device in Azure AD.

I hope this helps someone else to configure the Enhanced HTTP solution. Until next time......






3 comments:

  1. Hi Gerry, thanks for this.
    So if we want to configure a CMG where legacy OS like W7 and 8.1 need to communicate with, the old way of setting up the Root CA certificates and Subordinate CA certificates and get a certificate by a public provider for the DNS alias for the cloudapp.net name.
    But then there is the limitation of max 2 Root CA certificates and 4 Subordinate CA certificates. as described by Peter Egerton here > https://morethanpatches.com/2018/10/05/configuration-manager-cloud-management-gateway-certificate-limitation/

    ReplyDelete
    Replies
    1. Yes, that's right. Windows 7 and 8.1 communication should still be secured via traditional PKI as you say. I'm aware of the limitation although I haven't experienced it personally. I've only ever needed 2 Root CA certs.

      Delete
  2. Thanks for the guide. I'm getting a message that one or more certificates int the certificate change are missing. To resolve this issue, make sure that all the intermediate certificates are installed. and it references KB954755. I thought the point if EHTTP was that I didn't need certs and SCCM would create its own?

    ReplyDelete