1. Definición, En Qué Consiste Cloud Management Gateway
Cloud Management Gateway (En adelante, CMG), proporciona una manera sencilla de administrar clientes de Configuration Manager en Internet. Al implementar CMG como Cloud Service en Azure, es posible administrar los clientes de ConfigMgr (SCCM) tradicionales que se conectan a través de internet, sin tener una infraestructura local adicional expuesta a Internet.
1.1 Escenarios Posibles
Escenario 1: El más común actualmente, es un escenario en el que se lleva a cabo la administración de clientes tradicionales de Windows con la identidad unida a un dominio de AD on Prem, con equipos W 8.1 ó W10 (Son los únicos SO a nivel de SO Cliente compatibles ahora mismo con CMG). Se usan Certificados PKI para proteger el canal de comunicación. Se utilizan las siguientes features: Actualizaciones de Software y Endpoint Protection, Estado de Cliente SCCM e Inventario, Configuración de Compliance Settings (Cumplimiento), Distribución de SW para el dispositivo, Secuencia de tareas de In Place Upgrade de W10 (Para saltar de una versión a otra superior).
Escenario 2: Administración de clientes tradicionales de W10 con Identidad moderna, tanto híbridos como unidos a Azure AD. Los clientes usan Azure AD para la autenticación , en lugar de utilizar certificados PKI. Lo que facilita bastante la configuración y el mantenimiento respecto a utilizar los certificados PKI. Las features que se pueden utilizar con este tipo de clientes, son las mismas, más una añadida, La posibilidad de distribuir software no solo para el equipo sino también, para el usuario.
1.2 Casos de Uso Específicos
Se suele utilizar CMG en los siguientes casos de uso:
- Para Administrar Dispositivos en Itinerancia (Por ejemplo, Portátiles, Surface, etc…)
- Para Administrar Dispositivos en ubicaciones remotas donde resulta más económico y más eficaz frente a la administración a través de WAN / VPN.
- Para Administrar Clientes en WorkGroup.
** A partir de la versión 2002 de SCCM, se admite la autenticación basada en tokens, lo cual ayuda a la administración de clientes en grupo de trabajo remotos. Para más información al respecto de esta característica, puedes visitar nuestro post al respecto, donde entenderás cómo funciona Token Based Authentication Para CMG.
1.3 Componentes de CMG y Servicios Que Prestan
En CMG, intervienen los siguientes componentes:
- Servicio en la Nube de CMG (Azure): En Azure autentica y reenvía las solicitudes de cliente de SCCM al punto de Conexión de CMG.
- Rol de Punto de Conexión de CMG: Permite una conexión coherente y de alto rendimiento desde la red local, hacia el servicio CMG en Azure. Publica la configuración de CMG y reenvía las solicitudes de cliente desde CMG a los roles locales en función de las asignaciones de direcciones URL.
- Rol de Punto de Conexión de Servicio (Service Connection Point): Ejecuta el componente del administrador del servicio en la nube, que es el que controla todas las tareas de implementación de CMG, adicionalmente, supervisa y notifica la información de estado y el registro del servicio de Azure AD. (Ha de estar en modo “Online”).
- Rol de Management Point: Atiende las solicitudes de clientes SCCM como hace habitualmente.
- Rol de SUP: Atiende las solicitudes de clientes SCCM como hace habitualmente.
- Clientes Basados en Internet: Se conectan a CMG para tener acceso a los componentes locales de SCCM.
- Servicio Web HTTPS basado en Certificados: CMG utiliza este servicio para proteger la comunicación de red con los clientes.
- Distribution Point en la Nube (Cloud DP): No es indispensable, pero si recomendable su implementación, dado que una Instancia de CMG también es capaz de servir contenido a los clientes. Esta funcionalidad reduce los certificados necesarios frente a los requeridos con el método anterior de implementación de un DP en la Nube.
1.4 Requisitos Para la Implementación de CMG
Para que CMG funcione correctamente y sea posible implementarlo, son necesarios los siguientes requisitos que se citan a continuación:
- Suscripción de Azure para Hospedar CMG.
- La Cuenta de Usuario ha de ser Administrador total o al menos de infraestructura en SCCM.
- Un Administrador de Azure ha de participar en la creación inicial de determinados componentes. Para la Instancia de CMG, mínimo administrador de suscripciones y para integrar el sitio con Azure AD, deberá ser Administrador Global.
- Un Servidor Local Windows para hospedar el rol de punto de conexión de CMG.
- El Service Connection Point o Punto de Conexión de Servicio ha de estar configurado en modo “En línea / Online”
- Integración con Azure AD con el fin de implementar el servicio CMG con Azure Resource Manager.
- Certificado de Autenticación de Servidor para CMG.
- Certificado Raíz o CA Root.
- Certificado PKI para distribuir a los clientes (Se puede hacer con HTTP mejorado según el método de autenticación de los clientes, pero es recomendable HTTPS).
- Uso de IPv4 en los Clientes.
2. Diseñando la Jerarquía Para CMG
Se debe crear la instancia de CMG en el sitio de nivel superior de la jerarquía (Top Level Site Server). Si es un sitio de administración central (CAS), se deberían crear puntos de conexión de CMG en los Sitios Primarios que dependan del CAS. El componente del administrador de servicios en la nube está en el punto de conexión de servicio, que también está en el sitio de administración central. Este diseño puede compartir el servicio en varios sitios primarios, si fuese necesario.
Se pueden crear varios servicios CMG en Azure y varios puntos de conexión de CMG. La existencia de varios puntos de conexión de CMG proporciona equilibrio de carga para el tráfico de cliente desde CMG a los roles locales.
A partir de la versión 1902 de SCCM, se puede asociar una instancia de CMG con un grupo de límites. Esta configuración permite a los clientes predeterminar o recurrir a dicha instancia de CMG para la comunicación con el cliente de acuerdo con las relaciones de grupo de límites o también llamados Boundary Groups.
2.1 Ejemplo de Uso en Primary Site Independiente Standalone
Supongamos que su empresa, tiene un Primary Site Standalone en su sede central de Madrid (España).:
- Sería necesario crear una instancia de CMG en Azure (West-Europe) para reducir la latencia de red al máximo posible.
- Sería necesario crear dos puntos de conexión de CMG, ambos vinculados al Servicio CMG único, con el fin de balancear la carga.
De esta manera, cuando los clientes se conecten desde internet, se comunicarán con CMG en la región de West Europe, CMG reenviará esta comunicación a través de los dos puntos de conexión de CMG creados.
2.2 Ejemplo de Uso en una Jerarquía con CAS
Supongamos que su empresa tiene un CAS en su sede de Madrid, un Primary Site en su sede de Valladolid y otro Primary Site en su Sede de Sevilla.
- En el CAS se debería crear una instancia de CMG en Azure West Europe y escalar el número de máquinas virtuales en función de la estimación de la carga de trabajo respecto al número de clientes que vaya a existir en itinerancia en toda la jerarquía de su empresa.
- En cada una de las otras dos sedes, Valladolid y Sevilla, se debería de configurar un punto de conexión de CMG vinculado a la instancia de CMG creada en Azure West Europe.
De esta manera, cuando los clientes se conecten desde internet, se comunicarán con CMG en la región de West Europe, CMG reenviará esta comunicación al punto de conexión de CMG del sitio primario que tenga asignado cada cliente.
2.3 Limitaciones de CMG
- Sólo será compatible con los siguientes SO Cliente: Windows 10 y Windows 8.1.
- Sólo será compatible con los siguientes SO Servidor: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 y Windows Server 2012. (En diferentes Versiones, para más información, revisar Doc. Oficial: https://docs.microsoft.com/es-es/configmgr/core/plan-design/configs/supported-operating-systems-for-clients-and-devices).
- No es compatible con aquellos clientes que sólo se comunican mediante IPV6.
- Los SUP que utilicen un equilibrador de carga de red (NLB), no funcionan con CMG.
Sólo son compatibles las siguientes features o características de SCCM con CMG:
No siendo compatible con estas features o características, que se muestran a continuación:
2.4 Puertos Necesarios Para CMG
Para CMG será necesario tener conectividad en los siguientes puertos, con los orígenes y destinos indicados en la siguiente tabla:
| Cliente | Protocolo | Puerto | Server | Descripción |
| Punto de conexión de servicio | HTTPS | 443 | Azure | Implementación de CMG |
| Punto de conexión de CMG | TCP-TLS | 10140-10155 | Servicio de CMG | Protocolo preferido para crear el canal de CMG |
| Punto de conexión de CMG | HTTPS | 443 | Servicio de CMG | Protocolo de reserva para crear el canal de CMG para una sola instancia de máquina virtual |
| Punto de conexión de CMG | HTTPS | 10124-10139 | Servicio de CMG | Protocolo de reserva para crear el canal de CMG para dos o más instancias de máquina virtual |
| Cliente | HTTPS | 443 | CMG | Comunicación de cliente general |
| Punto de conexión de CMG | HTTPS o HTTP | 443 o 80 | Punto de administración | Para el tráfico local, el puerto depende de la configuración del punto de administración |
| Punto de conexión de CMG | HTTPS o HTTP | 443 o 80 | Punto de actualización de software | Para el tráfico local, el puerto depende de la configuración del punto de actualización de software |
3. Configuración Paso a Paso de CMG
A continuación, se detalla la guía de configuración paso a paso de CMG.
En el caso del laboratorio utilizado para la generación de esta guía de configuración, el entorno consta de los siguientes elementos:
– 1 DC WS 2019 con Roles ADDS, DNS, DHCP, Certificates Services.
– 1 Primary Site Stand Alone con SCCM 1910 Instalado.
– 1 Site System Server destinado exclusivamente al tráfico que provenga del CMG y los clientes que estén en itinerancia. Con los Roles MP y SUP.
– 1 Cliente W10
3.1 Configurando el Resource Group en Azure, Comprobando Alias Disponible
Será necesario crear en primer lugar el RG donde queramos ubicar los recursos del CMG en Azure, posteriormente, deberemos comprobar si el alias único deseado está disponible ya que ha de ser único a nivel global:
Entramos a Portal.Azure.com, iniciamos sesión en la suscripción donde queramos implementar el Resource Group para CMG, Buscamos «Resource Groups» en el buscador y creamos uno nuevo:
Comenzamos el Asistente, haciendo click en «Add»
Creamos el Resource Group con el Nombre deseado y seleccionamos la suscripción donde lo queremos crear, así como la región que corresponda según ubicación:
Una vez creado, comprobaremos si nuestro servicio puede ser creado, el nombre ha de ser único, ya que utiliza el dominio cloudapp.net, que es propiedad de Microsoft, para ello, desde nuestro RG creado anteriormente, hacemos click en «Add»:
Posteriormente, buscamos «Cloud Service» y hacemos click en «Create»:
Comprobamos si está libre el Alias Único que deseemos utilizar:
Una vez comprobemos que está libre (Aparecerá un “✅” junto al nombre), comenzaremos con la creación de las plantillas necesarias para generar posteriormente los certificados que necesitamos para la implantación.
3.2 Configurando Certificados Necesarios
En nuestro caso, hemos elegido el modelo de Certificados PKI y comunicación HTTPS con el MP al no tener equipos Full AAD Joined (Unión a Azure AD), sino que están unidos a un AD on Prem y existe un AD Connect para sincronizar las identidades on Prem con Azure AD. (Suele ser el escenario más habitual actualmente, aunque lo ideal, sería tener equipos unidos directamente a Azure AD).
Para llevar a cabo nuestra implantación, será necesario configurar diferentes plantillas y solicitar y exportar distintos tipos de certificado, a continuación, se detallan los pasos a seguir:
- Nos vamos al DC que tiene el rol instalado de Active Directory Certificate Services y abrimos la consola “Certification Authority” (certsrv.msc):
- Acto Seguido, Seleccionamos en la columna de la Izquierda “Certificate Templates”, hacemos click derecho sobre ella y seleccionamos “Manage”:
- Seleccionamos en la columna de la derecha la Template con Nombre “Web Server” y hacemos click sobre “Duplicate Template”:
- Dejamos la pestaña “Compatibility” según aparece, asegurándonos que en “Certification Authority” figure “Windows Server 2003”:
- Acto seguido, modificamos la pestaña “General”, introduciendo el Template Display Name que queramos otrogar a la Plantilla a Generar y establecemos el periodo de validez que deseemos:
- En la pestaña “Request Handling”, marcamos el check “Allow Private Key To Be Exported”, con el fin de que nos permita poder exportar la clave privada posteriormente:
- En la pestaña “Security”, nos aseguramos de desmarcar la opción de “Enroll” para el Grupo de Seguridad “Enterprise Admins”:
- Agregamos en la misma pestaña, un grupo de seguridad que previamente hemos debido de crear, cuyos miembros sean los servidores de sitio que queramos que puedan obtener este certificado posteriormente (Site Servers) y le otorgamos permisos de “Read” y “Enroll”:
- Volvemos a la consola “Certification Authority” y sobre la carpeta “Certificate Templates” de la columna de la izquierda, volvemos a hacer click derecho y seleccionamos “New” y posteriormente “Certificate Template to Issue”:
- En la ventana que nos aparecerá a continuación “Enable Certificate Templates”, seleccionaremos la plantilla que hemos creado anteriormente. A partir de este momento ya estará disponible para ser solicitada desde cualquiera de los servidores de sitio que hayamos metido en el grupo de seguridad en el paso número 8.
- Acto seguido, deberemos solicitar el certificado generado anteriormente desde el Primary Site, para ello, abriremos una consola MMC, haremos click en “File”, “Add / Remove Snap-in…” y elegiremos “Certificates”, para seleccionar por último, “Computer Account”:
- Seleccionamos “Local Computer”:
- Una vez Abierto y cargado el complemento de Certificados, Sobre la ruta “Personal, Certificates”, haremos click derecho y elegiremos “All Tasks” y “Request New Certificate”, posteriormente tras avanzar durante el wizard, elegiremos la plantilla que generamos anteriormente y haremos click sobre el warning que nos aparece en la parte inferior de la misma:
- A continuación, escribiremos el FQDN de nuestro cmg seleccionando en la parte superior en “Type”, el valor “Common Name” (CN) y en la parte inferior, el valor “DNS”:
- Al hacer click en Add, veremos como el solo nos lo traduce al formato apropiado:
- Por último, haremos click en “Apply” y después en “Enroll” y nos deberá aparecer una ventana similar a la siguiente:
- A continuación, deberemos exportar el certificado anteriormente generado SIN CLAVE PRIVADA EXPORTADA, es decir, en formato .CER, para ello, desde la consola, nuevamente hacemos click derecho sobre el certificado y seleccionamos “Export”:
- Seleccionamos el formato tal como aparece en la siguiente imagen:
- Seleccionamos un almacén local donde guardar los certificados y lo exportaremos correctamente finalizando el wizard de exportación.
- A continuación, deberemos realizar la misma operación de exportación del certificado anteriormente generado, pero esta vez, CON CLAVE PRIVADA EXPORTADA Y EN FORMATO .PFX, CON TIPO DE ENCRIPTACIÓN “AES256-SHA256”:
- Ahora que ya tenemos ambos certificados exportados, nos faltaría crear el certificado del cliente, necesario como comentábamos en puntos anteriores para que los clientes se puedan validar, así como para el punto de conexión de Cloud Management Gateway, para comenzar, nos iremos a la administración de Templates de certificados de la Certification Authority y generaremos una de tipo “Workstation Authentication”:
- En la Casilla de Template Display Name, escribiremos el nombre que le queramos dar a nuestra template, por ejemplo, “SCCM Client Certificate”, le asignamos una duración de entre 2 y 5 años (Orientativo) y acto seguido, nos vamos a la pestaña “Security” y asignamos al grupo “Domain Computers” permisos de Read, Enroll y Autoenroll, por último, al igual que en pasos anteriores, tendremos que realizar el paso correspondiente para publicarla:
- Con este paso, hemos terminado con la generación de certificados para CMG ✅.
3.3 Creando GPO Para Inscripción Automática de Certificado de Cliente
La manera más rápida existente para implementar el certificado de cliente en todas las máquinas del dominio, es a través de una GPO de inscripción automática. Para ello, a continuación, se detallan los pasos a seguir para conseguirlo:
- Iniciamos el Group Policy Management Editor, Inicio / Administrative Tools / Group Policy Management:
- A continuación, generamos una nueva GPO, la nombramos como deseemos (Por ejemplo, SCCM_Cert_Autoenroll_ClientCert) y hacemos click derecho sobre la misma y la editamos, nos vamos a: Computer Configuration / Windows Settings / Security Settings / Public Key Policies :
- Hacemos click derecho en: Certificate Services Client – Auto-Enrollment, luego hacemos click en Properties, posteriormente configuramos la setting de la GPO como figura en la imagen adjunta a continuación:
- Tras Aplicar los cambios y aceptar la modificación de la GPO, la asignaremos a la OU donde queramos que aplique. Acto seguido, si hacemos un GPUPDATE / Force en una estación de trabajo donde aplique la GPO generada anteriormente, deberíamos ver en el almacén de certificados “Personal” de la cuenta de equipo local, el certificado de máquina generado.
3.4 Subiendo Certificados a Nuestra Suscripción de Azure
Como parte del proceso de configuración / implantación de CMG mediante PKI, tendremos que subir a nuestra suscripción de Azure al menos dos certificados en formato .CER:
- Certificado Raíz de Nuestra CA Root (Si interviniese alguna entidad certificadora intermedia, también sería necesario subir el de la CA Intermedia)
- Certificado de Web Server Generado Anteriormente Para Nuestro CMG.
Para realizar estos pasos, accedemos al portal de Azure y nos logamos con nuestro usuario con los permisos requeridos (Explicados en Puntos Anteriores), acto seguido hacemos click en nuestra suscripción, posteriormente nos vamos a la pestaña de “Management Certificates” y haciendo click en Upload, subimos ambos certificados:
Una vez subidos aparecerán como figura en la imagen adjunta anterior y habremos terminado con esta tarea.
3.5 Activando Resource Providers, (Necesario Solo Suscripciones Nuevas)
De un tiempo hacia la fecha, en las suscripciones nuevas que se crean en Azure, no vienen registrados por defecto algunos Resource Providers. Concretamente me he encontrado con dos RP que no estaban registrados por defecto: Microsoft.ClassicCompute y Microsoft.Storage. Lo que provoca un error en el log durante la implementación de CMG, que es similar a este: “Resource Manager – Failed to list keys for storage <name of cmg> with status code: NotFound” Para Solucionar este problema, basta con registrarlos manualmente desde el portal de Azure, accediendo a nuestra suscripción / Resource Providers y registrarlos nosotros, previa búsqueda de los mismos y haciendo click en “Register”:
3.6 Configurando Azure Services desde SCCM
Llegados a este punto, ahora que tenemos todos los certificados necesarios preparados, exportados y subidos a Azure, comenzaremos a configurar los Azure Services necesarios para que CMG funcione correctamente, concretamente en este paso, se realizan dos tareas en paralelo, por un lado, se crean dos aplicaciones en Azure (Los nombre son orientativos):
- ConfigMgr Server Application (Web App).
- ConfigMgr Client Application (Native Client App).
Por otra parte, (Opcional), se configura Azure Active Directory User Discovery, con el fin de sincronizar las identidades que estén en la nube y poder utilizar CMG, siempre que se cumplan los requisitos explicados en puntos anteriores, en el contexto no solo de dispositivo o máquina, sino también en el contexto de usuario.
A continuación, se detalla paso a paso el procedimiento a seguir para llevar a cabo esta tarea:
- Nos dirigimos a la consola de Administración de SCCM a Administration / Cloud Services / Azure Services, hacemos click derecho sobre “Azure Services” y seleccionamos “Configure Azure Services”:
- Escribimos un nombre y una descripción y seleccionamos “Cloud Management”:
- En la siguiente pantalla del wizard, seleccionamos “Browse” sobre Web App y hacemos click en “Create”, acto seguido, deberemos introducir el nombre de nuestra aplicación, por ejemplo: “ConfigMgr Server Application”:
- Hacemos lo propio con la aplicación de Cliente y continuamos el wizard, cuando lleguemos a la siguiente pantalla, nos solicitará habilitar o no Azure Active directory User Discovery, según queramos proceder, procedemos:
- Una vez finalizado el wizard de configuración, nuestros servicios estarán configurados y nos aparecerán en la consola de administración de SCCM:
3.7 Creando Nuestro CMG desde SCCM
Tras tener los servicios configurados correctamente, continuaremos creando nuestro CMG en Azure desde SCCM, para ello, debemos seguir los pasos que se detallan a continuación:
- Desde la consola de administración de SCCM, nos iremos a Administration / Cloud Services / Cloud Management Gateway y haremos click en “Create Cloud Management Gateway”, acto seguido haremos login con nuestra cuenta con permisos de Admin de la Suscripción y elegiremos el ID de las suscripción elegida para desplegar CMG:
- En la siguiente ventana del wizard, procederemos a subir en el primer apartado, el certificado con clave privada exporable que generamos para el CMG (.PFX).
- En el segundo apartado, nos mostrará una vez elegido el certificado, el nombre que tendrá el servicio, justo debajo, el deployment name con el sufijo DNS .cloudapp.net.
- En el campo descripción, escribiremos una descripción para identificar este CMG.
- En el campo región, muy importante, elegir la que corresponda a la zona que englobe a la ubicación física de la empresa, si es España, por ejemplo, seleccionaremos “West Europe”.
- Seleccionamos en el campo Resource Group, uno existente o creamos uno nuevo donde generar nuestro CMG en Azure.
- En el campo VM Instance, seleccionaremos en principio 1, con vistas a poder ampliarlo posteriormente si fuese necesario en función de las necesidades de La Empresa.
- Por último, en el campo certificates uploaded to the cloud service, seleccionaremos el CA Root de nuestra PKI en formato .CER. y desmarcaremos “Verify Client Certificate Revocation” salvo que tengamos nuestra CRL publicada hacia internet.
Una vez completados todos los pasos, finalizamos el wizard y nuestro CMG quedará desplegado cuando aparezca en la barra inferior, en “Status”, la palabra “Ready” y en “Status Description” la frase “Provisioning Completed”, esto querrá decir que el aprovisionamiento de nuestro CMG habrá finalizado:
3.8 Agregando el Rol de CMG Connection Point
A continuación, será necesario agregar en nuestro Primary Site, el Rol de CMG Connection Point, que como comentamos, es el encargado de comunicarse con el CMG en la nube. Para ello, deberemos seguir los siguientes pasos:
- Agregamos el Rol desde la Consola de SCCM, nos vamos a Administration / Site Configuration / Servers and Site System Roles:
- En la siguiente pantalla del wizard, veremos que nos rellenará automáticamente, en el caso de que solo exista un CMG en nuestro entorno, el nombre de este. Con este paso, damos por finalizada la configuración del Rol en el Primary Site.
4. Configurando Primary Site, MP e IIS
Para finalizar la implantación de nuestro CMG, será necesario hacer algunos cambios en la configuración del Primary Site, en el MP elegido en exclusiva para manejar las conexiones que provengan de clientes de internet a través del CMG y en el IIS de este para poder establecer comunicación correctamente en todos los puntos de la infraestructura y del servicio involucrados:
4.1 Configurando Primary Site Para Autenticación de Cliente Mediante PKI
Como estamos utilizando un escenario en el que vamos a emplear HTTPS en el MP dedicado para el tráfico proveniente de los clientes en internet a través del CMG, necesitamos habilitar nuestro Primary Site para que use el certificado PKI del cliente cuando esté disponible para la autenticación de este. A continuación se detallan los pasos a seguir para llevar a cabo esta tarea:
- Desde la consola de SCCM, nos vamos a Administration / Site Configuration / Sites y hacemos click derecho sobre nuestro primary site, posteriormente seleccionamos “Properties”:
- Marcamos las opciones seleccionadas en la imagen adjunta y por último, seleccionamos el Root CA Certificate que generamos anteriormente y aplicamos los cambios. Con esta tarea quedaría configurado nuestro Primary Site correctamente.
4.2 Configurando MP Dedicado Para HTTPS
Aquí deberemos configurar dos parámetros, por un lado, permitir el tráfico proveniente del CMG en el MP dedicado elegido y por otro, solicitar desde la consola MMC en este, un certificado de tipo Web Server Authentication:
- Desde la consola de SCCM, nos vamos a las propiedades del MP elegido y marcamos las siguientes casillas de verificación:
- Indicamos Allow Internet Only Connections en la lista desplegable.
- Solicitamos el certificado desde la consola MMC siguiendo los pasos descritos en puntos anteriores. Deberemos indicar el FQDN del MP elegido al solicitar el certificado tanto en CN como en DNS (Wizard desde Consola MMC).
4.3 Configurando IIS del MP Dedicado HTTPS
Finalmente, para completar y dejar plenamente funcional nuestro CMG, será necesario editar los bindings del sitio web predeterminado de IIS para que utilice HTTPS e indicarle el certificado a utilizar, que será el que hemos solicitado en el punto anterior:
- Click derecho sobre Default Web Site, Edit Bindings.
- Seleccionamos el puerto 443 y el certificado solicitado en el punto 4.1:
5. Configurando Client Settings Para CMG
Para finalizar, será necesario generar y desplegar a los equipos de nuestro entorno, las Client Settings para permitir el tráfico a través del CMG, a continuación, se muestra un ejemplo:
6. Validación de la Implantación de CMG
Como en todo procedimiento, faltaría validar que todo está funcionando correctamente, para ello, desplegaremos las Client Settings a una colección que contenga un piloto de equipos seleccionado cuidadosamente, posteriormente, validaremos que todo funciona según lo esperado, comprobando que el cliente está conectado a través de nuestro CMG:
- Validación desde el Lado Cliente:
Desde el Panel de Control de uno de los equipos elegidos para el piloto de CMG, nos vamos a las propiedades de Configuration Manager y comprobamos en la pestaña “Red” o “Network” que esté conectado al FQDN de nuestro CMG.
- Validación desde el lado Servidor:
Por último, ejecutaremos el Connection Analyzer desde la consola de SCCM, haciendo click sobre nuestro CMG, posteriormente, probaremos tanto con un usuario de Azure AD, como con el certificado de un cliente que previamente exportemos, que todos los checks nos aparecen en verde con un ✅. Una vez confirmado, podremos dar por finalizada la implantación.
2 comentarios en «Guía Definitiva Para Configurar Cloud Management Gateway Paso a Paso (CMG)»
Hola,
Gracias por explicarlo muy bien!
Quería decirte que seguí todo esos pasos pero mi clientes no logran conectarse a mi CMG.
Como podría que un cliente se pueda conectar a mi PKI?
Hola Edgardo,
Revisaste Logs?
Te recomiendo que empieces por revisar estos que figuran en la doc. Oficial, a priori pueden ser muchas cosas, has desplegado al cliente el certificado PKI? has comprobado que estén bien generados los certificados?
Ya nos vas contando, muchas suerte!
Un Saludo.