Cerrar
InicioAzureMicrosoft Intune: Administración del Grupo Local de Administradores

Microsoft Intune: Administración del Grupo Local de Administradores

Una de las principales preocupaciones que tenemos como administradores de infraestructuras, es la de gestionar cuantos administradores hay en la organización. Desde los súper administradores (Administradores de Dominio (ADDS), Administradores Globales (Azure) hasta los administradores locales de los equipos de nuestros usuarios. No importa si el equipo está a un dominio ADDS o AzureAD, siempre debemos evitar que los usuarios finales nunca sean administradores, ni locales ni por supuesto a otro nivel (ADDS o AzureAD). Para ello, siempre hemos tenido varias formas de mantener controlados los grupos de seguridad de los Administradores en un entorno ADDS con diferentes GPO:

Al final, lo que buscamos es evitar que nadie que no tenga que ser administrador lo sea por “equivocación”. Para esto, las GPO son una excelente opción para que nadie añada manualmente usuarios y/o grupos de usuarios a los grupos de administradores en  nuestra infraestructura. Hasta aquí, todo sencillo, pero ahora con la llegada de la unión de nuestros equipos a AzureAD (Azure ADJoin: + info What is an Azure AD joined device? | Microsoft Docs) debemos hacer lo mismo, mantener el control sobre las membresías de los usuarios en los grupos con derechos administrativos.

Antes de continuar, os voy a mostrar en una infografía como podemos controlar los miembros del grupo de administradores locales de Windows 10 con Intune:

El objetivo es gestionar que usuarios y/o grupos son miembros del grupo de Administradores Locales de nuestros Windows 10, evitando que, tengamos administradores no controlados en nuestra infraestructura. Debemos saber, sino lo sabemos ya, es que cuando un usuario une su equipo al dominio de AzureAD, por defecto se convierte en administrador local. Las única forma de evitarlo son [+ info Administración de los administradores locales en dispositivos unidos a Azure AD | Microsoft Docs]:

  • Windows Autopilot: nos ofrece una opción para evitar que el usuario principal que realiza la unión se convierta en un administrador local.
  • Inscripción masiva: una unión a Azure AD que se realiza en el contexto de una inscripción masiva tiene lugar en el contexto de un usuario creado automáticamente. Los usuarios que inician sesión después de que se hayan unido un dispositivo no se agregan al grupo de administradores

Igualmente, aunque el usuario no sea miembro del grupo de administradores locales, debemos (o deberíamos) administrar la gestión de los administradores locales. Por defecto, cuando se une un equipo al dominio de AzureAD, si accedemos al grupo de administradores locales, veremos dos SID de dos grupos de AzureAD:

Ambos SID se corresponden con el rol de Administrador Global y el de Administradores de Dispositivos de AzureAD, los cuales se añaden por defecto además del usuarios que une el equipo al dominio (a excepción de que sigamos los procesos de Windows AutoPilot e Inscripción masiva).  Dicho esto, es posible que, tengamos la necesidad de añadir o quitar usuarios y/o grupos del grupo de administradores locales de nuestros equipos unidos al dominio y eso es justo lo que os voy a mostrar.

Objetivo: dejar la cuenta de administrador predeterminada y un grupo de seguridad de AzureAD creado por nosotros como miembros del grupo de administradores locales.

Lo primero que haré será crear un grupo de Seguridad en AzureAD, el cual utilizaré para que sus miembros sean administradores locales en los equipos unidos el dominio de AzureAD. El proceso es sencillo,  simplemente nos creamos un grupo de seguridad y escribimos un nombre descriptivo, el resto de opciones en la creación del grupo ahora no son relevantes:

Antes de continuar, vamos copiar el ID de objeto del grupo creado, lo vamos a necesitar más adelante.

Ahora que ya tenemos nuestro grupos, veamos, como configuraremos un perfil para Windows 10 y elegiremos la plantilla Personalizada (Custom en inglés):

Definimos un nombre y descripción de la configuración que vamos a realizar:

Lo que haremos, será utilizar políticas CSP para gestionar la membresía del grupo de administradores locales. Hasta la versión  20H2 de Windows se utilizaba la política RestrictedGroups, pero desde dicha versión de Windows debemos utilizar la política LocalUsersAndGroups. La configuración es muy sencilla:

  • Name: escribiremos un nombre para identificar la sección de configurar
  • Description: podemos escribir una descripción si queremos
  • OMA-URI: definiremos la ruta de acceso a la configuración específica para la configuración de la política  LocalUsersAndGroups. La ruta OMA-URI que tenemos especificar es la siguiente: ./Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure
  • Data type: elegimos String
  • Value: aquí debemos especificar el código XML conformado siguiendo las siguiente estructura:

<GroupConfiguration>
<accessgroup desc = “”>
<group action = “”/>
<add member = “”/>
<remove member = “”/>
</accessgroup>
</GroupConfiguration>

La siguiente descripción de cada sección es sacada literalmente de la web de Microsoft [+info CSP de directiva: LocalUsersAndGroups – Windows Client Management | Microsoft Docs]:

  • <accessgroup desc>: especifica el nombre o SID del grupo local que se debe configurar. Si especifica un SID, se usa la API LookupAccountSid para traducir el SID a un nombre de grupo válido. Si especifica un nombre, se usa la API LookupAccountName para buscar el grupo y validar el nombre. Si se produce un error en la búsqueda de nombre/SID, se omite el grupo y se procesa el siguiente grupo del archivo XML. Si hay varios errores, el último error se devuelve al final del procesamiento de directivas.
  • <group action>: especifica la acción que se debe realizar en el grupo local, que puede ser Update y Restrict, representada por usted y R:
    • Update. Esta acción debe usarse para mantener intacta la pertenencia al grupo actual y agregar o quitar miembros del grupo específico.
    • Restringir. Esta acción debe usarse para reemplazar la pertenencia actual con los grupos recién especificados. Esta acción proporciona la misma funcionalidad que la configuración de directiva RestrictedGroups/ConfigureGroupMembership.
  • <add member>: especifica el SID o el nombre del miembro que se debe configurar, si especificamos un grupo debemos escribir el SID presente en el securityIdentifier (ahora vemos como conseguirlo)
  • <remove member>: especifica el SID o el nombre del miembro que se quitará del grupo especificado.

Más o menos entendiendo la estructura del XML, aquí os muestro mi configuración [Reemplaza los miembros del grupo de Administradores locales con mi usuario del dominio y el grupo creado anteriormente]:

<GroupConfiguration>
<accessgroup desc = “Administradores”>
<group action = “R” />
<add member = “AzureAD\sbuitrago@dominio.com”/>
<add member = “S-1-12-1-3182539530-1203982254-3660385170-4178335708″/>
</accessgroup>
</GroupConfiguration>

Antes de continuar con la configuración, voy a mostraros como podéis obtener el SID del grupo que queráis añadir buscando dentro del atributo securityIdentifier. Para ello, debemos hacerlo mediante Microsoft Graph accediendo a la siguiente URL: https://developer.microsoft.com/en-us/graph/graph-explorer y en ejecutando la siguiente consulta https://graph.microsoft.com/v1.0/groups/<ObjectID del Grupo Creado>. Para ello, lo primero será iniciar sesión en https://developer.microsoft.com/en-us/graph/graph-explorer:

Una vez iniciada la sesión con una cuenta de Global Admin (la primera vez por lo menos) o rol equivalente para poder conceder los derechos suficientes a Microsoft Graph en nuestro AzureAD:

Si ahora lanzamos la consulta (Getv.10https://graph.microsoft.com/v1.0/groups/GroupID (aquí tenemos que pegar el GroupID del grupo que hemos copiado antes)) y nos da el error que os muestro, debéis pulsar en Modify permissions (preview)

Pulsa en el botón Consent en el permiso Group.Reall.All

Volvemos a aceptar la solicitud de permisos

Ahora si nuevamente pulsamos en Run query con las mismas opciones de antes:

  • Get
  • v1.0
  • https://graph.microsoft.com/v1.0/groups/GroupID

Ya tenemos el SID en el atributo securityIdentifier, el cual copiaremos para luego insertarlo en el XML

Con el SID del grupo obtenido del atributo securityIdentifier, ya podemos volver al Microsoft Endpoint Manager admin center y pegar el XML ya con los usuarios y/o grupos que queremos añadir el grupo de administradores locales:

<GroupConfiguration>
<accessgroup desc = “Administradores”>
<group action = “R” />
<add member = “AzureAD\sbuitrago@dominio.com”/>
<add member = “S-1-12-1-3182539530-1203982254-3660385170-4178335708“/>
</accessgroup>
</GroupConfiguration>

Debéis escribir el nombre del grupo en el mismo idioma de vuestro Windows: Adminitradores, Administrators, etc…

Si  ya lo tenemos pegado en la consola de Intune, pulsamos en Save:

Como este perfil de configuración solo la queremos para administrar las membresías del grupo de administradores locales, no añadiremos nada más. Pulsamos en Next

Importante, aplicarlo solo a grupos de dispositivos a los que queráis aplicar esta configuración. Si podéis primero en un grupo de pruebas, luego ya lo podéis liberar al resto de equipos:

Si ya está todo revisado, pulsamos en Create y con eso hemos finalizado el proceso de administración del grupo de administradores locales.

En cuestión de minutos/horas (sino forzamos la sincronización) se aplicará a los equipos a los cuales le hemos aplicada dicha configuración.

Si ahora nos vamos al Visor de Eventos [Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin] de alguno de los equipos a los cuales le hemos aplicado la configuración, podemos ver el resultado.  Como podéis apreciar tenemos un error en al configuración, esto es porque no hemos añadido a la cuenta de Administrador local

MSFT lo deja bien claro en la siguiente nota:

Al usar la opción de reemplazo “R” para configurar el grupo integrado “Administradores”, es necesario especificar siempre el administrador como miembro y cualquier otro miembro personalizado. Esto se debe a que el administrador integrado siempre debe ser miembro del grupo de administradores.

Dicho esto, la configuración del XML debería ser la siguiente:

<GroupConfiguration>
<accessgroup desc = “Administradores”>
<group action = “R” />
<add member = “Administrador“/>
<add member = “AzureAD\sbuitrago@femxa.com”/>
<add member = “S-1-12-1-3182539530-1203982254-3660385170-4178335708″/>
</accessgroup>
</GroupConfiguration>

Una vez modificado el XML en la perfil de configuración de Intune, volvemos a forzar la sincronización para evitar esperas. Volvemos a revisar el Visor de Eventos [Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin] y ahora no tenemos errores de configuración:

Si revisamos el grupo de Administradores Locales del equipo, vemos que ya solo tenemos los usuarios y grupos que hemos configurado en el XML:

Los grupos añadidos de forma predeterminada [Administradores Globales y Administradores de Dispositivos de AzureAD] no tenemos forma de volver a añadirlos

Por último, voy a volver a modificar el fichero XML para dejar solo la cuenta de Administrador (escribirla en el idioma de vuestro Windows) y el grupo de Seguridad que habíamos creado para tal fin:

<GroupConfiguration>
<accessgroup desc = “Administradores”>
<group action = “R” />
<add member = “Administrador“/>
<add member = “S-1-12-1-3182539530-1203982254-3660385170-4178335708“/>
</accessgroup>
</GroupConfiguration>

Nuevamente revisamos el Visor de Eventos [Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin] y debería haberse aplicado sin errores:

Revisamos nuevamente el grupo de Administradores locales y  .. ya está solo la cuenta de Administrador y el SID del grupo que habíamos creado anteriormente. 

Yo he utilizado la cuenta de Administrador creada por defecto, pero podríamos añadir cualquier otra cuenta local que quisiéramos que fuese miembro del grupo de Administradores.

Espero que os sea de utilidad, en próximos artículos iremos viendo más opciones sobre la gestión de cuentas locales!!

Azure Virtual Deskto
Microsoft Intune: De
6 COMENTARIOS
  • Stiven Gómez / 22 enero, 2023

    Hola Santiago,

    En primer lugar, darte la enhorabuena por el contenido que publicas, es oro toda la información que podemos encontrar.

    Investigando este tema de los administradores locales, observo esta opción mucho más simplificada y que a lo mejor pueda valer para actualizar esta sección.

    Ingresando al portal de Azure AD (Dispositivos -> Configuración del dispositivo -> Al final de la página “Administrar Administradores locales adicionales en dispositivos unidos a Azure AD”.
    (https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/DevicesMenuBlade/DeviceSettings/menuId/)

    Podemos agregar los usuarios fácilmente.

    Un saludo.

  • Luis Maurtua / 8 junio, 2023

    Hola, primero que nada agradecido con tu explicación, estoy ejecutando tus pasos adaptado a mi entornos pero me devuelve el siguiente error lo he investigado pero no logro dar con el problema.

    resultado:(0x800705B9) Windows no puede analizar datos XML solicitados.

    Tienes alguna idea por donde pueden ir los tiros?

  • Luis Maurtua / 8 junio, 2023

    Nada soy un subn…. solo era tema de parametrización de Intune han agregado el string XML y esta poniendo string solamente y no le gustaba, ya se lo trago gracias por tu post fenomenal.

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This