Getty Images
What admins need to know about CMG client authentication
A System Center cloud management gateway keeps your organization's devices in compliance and running as they should, but which authentication option would work best for you?
While many workers have transitioned to a remote work routine, IT's job hasn't wavered: keep company devices maintained no matter where they are.
The coronavirus pandemic sent untold numbers of employees to work from home, making it more difficult to ensure work laptops stay compliant and uphold a security baseline. To help with this endeavor, you can use the Cloud Management Gateway (CMG) feature in System Center Configuration Manager (SCCM). A common SCCM issue is if the client's VPN connection goes down or is not being used, then the client shows as "unknown" in the SCCM console. Using a CMG will resolve this problem, but you will have to decide which of the three client authentication options will work best based on your specific needs and setup.
How do clients communicate with the CMG?
Because the purpose of a CMG is to connect internet devices to SCCM, you must secure the client communication with the service. Internet clients do not have contact with the on-premises management point in SCCM. Client connections via VPN count as an intranet connection rather than an internet connection.
Traditionally, you would use certificates delivered from the PKI. However, SCCM administrators have two additional authentication choices: through Azure Active Directory (AD) or token-based authentication. You are not limited to one authentication choice; each client can use a different authentication method.
What you need to know about CMG Azure AD authentication
Azure AD client authentication works for both Azure AD joined and hybrid-joined devices. This is Microsoft's recommendation when you use a CMG and need to authenticate the clients.
Requirements for Azure AD authentication are:
- devices that run Windows 10;
- devices joined to Azure AD or hybrid joined;
- SCCM configures the client settings;
- .NET Framework 4.5 is installed on the SCCM management point; and
- for hybrid identities, enable user discovery methods in SCCM.
What you need to know about CMG PKI authentication
To secure client authentication through certificates delivered through an internal PKI is another choice for CMG client authentication.
This scenario fits if:
- you already have a PKI infrastructure to distribute certificates to your devices;
- you do not require user identity support -- only devices are supported; and
- your clients commonly connect to the intranet via the office or VPN.
What you need to know about CMG token-based authentication
In this method, client authentication is secured via authentication tokens, delivered from SCCM through the intranet or the internet.
Requirements for token-based authentication are:
- SCCM 2002 or later;
- SCCM clients must be on the same SCCM version as the primary site for full support;
- an active Azure subscription;
- global admin rights in Azure;
- a server authentication certificate; and
- a unique DNS name for the CMG.
Why should you use token-based authentication?
Microsoft introduced token-based authentication for the CMG with SCCM 2002.
Token-based authentication does not rely on certificates or a connection to Azure AD. Therefore, it is a suitable client authentication method when you cannot meet these prerequisites in other authentication options.
Some scenarios that token-based authentication solves are:
- clients on the internet seldom connect to the local intranet;
- clients cannot join Azure AD; or
- clients have no way to receive certificates.
The benefits of token-based client authentication are:
- it removes the requirement of a client authentication certificate;
- co-management is not needed for the CMG setup; and
- the device does not need to join Azure Active Directory.
Clients register for an authentication token with either internal network registration or bulk registration over the internet.
The client authentication token renews every month and stays valid for 90 days. There is no requirement to connect to the internal network to renew this token.
How token registration works
Internal network registration is the default behavior for token-based authentication and does not require any configuration work from administrators.
Token registration occurs through the internal network from the on-premises SCCM management point when a client connects to the internal network and verifies that the device uses a self-signed certificate.
For internet-only clients, you can use a bulk registration token. With this method, the client never needs to connect to the intranet. This option is tailored for certain scenarios, such as mergers and acquisitions.
This is a separate token than what SCCM delivers. The bulk registration token's purpose is multifold: it makes the first communication between the client and the CMG over the internet and authenticates the client with the CMG via the self-signed authentication certificate. Once that occurs, the CMG service sends the device a unique client authentication token, which is used for any further communication.
The bulk registration token's validity is short. It is not stored on the site or client. You cannot renew bulk registration tokens. You can monitor the bulk registration tokens and remove them as required directly from the SCCM console.
You can bulk register devices with the BulkRegistrationTokenTool.exe tool located in the \bin\x64 folder of the SCCM primary site server installation.
