Búsqueda de sitios web

Uso de una identidad administrada de Azure con Microsoft 365 PowerShell

Las identidades administradas de Azure funcionan para algunos, pero no para todos, los módulos de Microsoft 365

Actualizado el 15 de julio de 2023

El uso de runbooks de Azure Automation es una excelente manera de ejecutar scripts de PowerShell de forma programada periódicamente. En artículos anteriores, exploré el uso de runbooks para procesar datos de Exchange Online, el envío de un correo electrónico de bienvenida a nuevos empleados con el SDK de Microsoft Graph PowerShell y la creación de archivos en SharePoint Online. Todos son buenos ejemplos de cómo aprovechar Azure Automation. En este artículo, exploro el uso de una identidad administrada para la autenticación en runbooks de Azure Automation.

Una identidad administrada es una identidad administrada y asignada por el sistema que se puede utilizar para acceder a recursos. Hay dos tipos de identidades administradas disponibles: sistema y usuario. En este artículo, cubro las identidades administradas por el sistema en lugar de las identidades administradas por el usuario. Las identidades administradas por el sistema están vinculadas a un recurso como una cuenta de automatización. Como veremos más adelante, poder asignar permisos de Graph API y roles administrativos de Azure AD a la entidad de servicio de una cuenta de automatización es una parte fundamental de la implementación.

Microsoft documenta el conjunto de servicios de Azure que pueden autenticar identidades administradas, pero falta documentación para los módulos de Microsoft 365 PowerShell. Mi valoración es:

  • Microsoft Graph PowerShell SDK (cuentas y grupos de Azure AD): funciona.
  • Equipos de Microsoft: funciona.
  • Administración de Exchange Online: aún no es compatible con el módulo de administración de Exchange Online (V2). Puede conectar el módulo Exchange V1 anterior y usarlo con una identidad administrada. Cubriremos eso en otro artículo.
  • SharePoint Online: hay ejemplos del uso de SharePoint Online PowerShell con una identidad administrada (aquí hay uno y un segundo ejemplo). El módulo SharePoint PnP admite un conjunto limitado de funciones con identidades administradas. Analizar los detalles del uso de SharePoint Online con una identidad administrada queda fuera del alcance de este artículo. Como veremos más adelante, para escribir un mensaje en un canal de Teams, utilizo el módulo SharePoint PnP.

La impresión general es que Microsoft diseñó Azure Automation y administró identidades para manejar los recursos de Azure y no ha prestado mucha atención a que Azure Automation funcione tan bien con los recursos de Microsoft 365. Aun así, la vida (y la TI) es un viaje, así que exploremos las posibilidades.

Crear una cuenta de automatización de Azure

Para comenzar, necesita una cuenta de Azure Automation asociada con una suscripción de Azure. Algunos recomiendan que uses una cuenta separada para las identidades administradas, pero puedes usar una cuenta existente si lo deseas. En este artículo analizo cómo crear una cuenta de Azure Automation; la gran diferencia es que las cuentas RunAs no son necesarias para las identidades administradas.

Permisos y funciones para identidades administradas

La documentación de Microsoft explica cómo funciona una identidad administrada asignada por el sistema. El mismo artículo también cubre cómo crear una identidad administrada. Para este artículo, utilizo una cuenta de automatización llamada ManagedIdentitiesAutomation. Esta cuenta almacena los recursos que usaremos en el ejemplo, principalmente los módulos de PowerShell. Antes de comenzar, asegúrese de cargar los módulos Graph que contienen los cmdlets utilizados en el runbook (como Microsoft.Graph.Authentication y Microsoft.Graph.Teams) como recursos para la cuenta de automatización.

Cuando crea una identidad administrada, Azure AD crea un objeto principal de servicio para la identidad administrada. Esto es fundamental porque la entidad de servicio es "una forma conveniente de asignar permisos". En otras palabras, al igual que las entidades de servicio de otras aplicaciones empresariales y registradas de Azure AD, puede asignar permisos y roles administrativos a la entidad de servicio de una identidad administrada para que esos derechos estén disponibles para la identidad administrada.

Para ver detalles de los roles y permisos disponibles para la entidad de servicio, acceda al centro de administración de Azure AD, seleccione Aplicaciones empresariales y filtre por Identidades administradas. Cuando encuentre la identidad administrada que creó en Azure Automation, podrá ver los permisos asignados a su entidad de servicio (Figura 1).

Muchos permisos se enumeran en la Figura 1. Esto se debe a que utilicé la misma cuenta para diferentes pruebas. Para determinar qué permisos necesita para los cmdlets que usan Graph API, puede seguir los consejos de este artículo. Volveremos a la gestión de permisos en breve.

Ejemplo de trabajo

Un ejemplo práctico es una excelente manera de explorar las posibilidades de cualquier tecnología. En mi caso, decidí mover un script que escribí para completar la membresía de un canal compartido en un equipo a Azure Automation. El script busca nuevas cuentas de Azure AD y las agrega al canal compartido para asegurarse de que todos los miembros de la organización puedan acceder al canal. Mover el script a Azure Automation me permitió programarlo para que se ejecutara periódicamente para detectar y agregar cuentas nuevas.

El script utiliza los módulos Microsoft Teams y Microsoft Graph PowerShell SDK. Como beneficio adicional, actualicé el script para publicar los resultados de su procesamiento en el canal compartido para que todos pudieran ver los detalles de los nuevos miembros. Llegaremos a esa parte pronto.

Conexión, autenticación y permisos

El script debe conectarse a los puntos finales de Microsoft Graph y Microsoft Teams. La forma más sencilla de obtener un token de acceso es ejecutar el cmdlet Connect-AzAccount. Puede ejecutar el cmdlet Connect-MicrosoftTeams con un parámetro Identity para usar una identidad administrada, lo que lleva a:

# Connect to Microsoft Graph in Azure Automation
Connect-AzAccount -Identity
$AccessToken = Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com"
# Connect to the Graph SDK with the acquired access token
Connect-Graph -AccessToken $AccessToken.Token -Scopes AppRoleAssignment.ReadWrite.All
#Define the desired graph endpoint
Select-MgProfile  Beta
# Connect to Teams
Connect-MicrosoftTeams -Identity

Microsoft Graph PowerShell SDK V2.0 (o posterior) admite identidades administradas, por lo que puede reemplazar la conexión con:

Connect-MgGraph -Identity -Scopes AppRoleAssignment.ReadWrite.All

Recuerde que la V2 del SDK divide los cmdlets en módulos de producción y beta. Si su código usa cmdlets beta, recuerde importar los módulos beta necesarios (como Microsoft.Graph.Beta.Users) a la cuenta de Azure Automation. El cmdlet Select-MgProfile no está en el SDK V2 y debe eliminarse de los runbooks.

Comprobando permisos

Ahora nos hemos conectado a Graph y Teams, pero el token de acceso generado por Azure AD no nos permitirá hacer mucho a menos que la identidad administrada tenga permisos para ejecutar cmdlets o solicitudes de Graph. Antes de continuar, tuve que:

  • Agregue la función de administración de Teams a la entidad de servicio de la identidad administrada.
  • Asigne los permisos de Graph API necesarios para las tareas realizadas en el script a la entidad de servicio.

Al observar el conjunto de permisos asignados a la identidad administrada en la Figura 1, no ve opciones para agregar o eliminar permisos (no se muestra la pantalla completa, pero no hay opciones disponibles). El centro de administración de Azure AD dice: "La capacidad de dar consentimiento a esta aplicación está deshabilitada porque la aplicación no requiere consentimiento". En términos prácticos, esto significa que toda la gestión de permisos debe realizarse a través de PowerShell.

Después de asegurarme de que la cuenta utilizada tenga los permisos Directory.ReadWrite.All y Application.ReadWrite.All (para actualizar Azure AD y los detalles de la aplicación), así es como asigné la función de administración de Teams a la entidad de servicio:

# Fetch details of the Teams management app
$TeamsApp = Get-MgServicePrincipal -Filter "AppId eq '48ac35b8-9aa8-4d74-927d-1f4a14a0b239'"  
$AppPermission = $TeamsApp.AppRoles | Where-Object {$_.DisplayName -eq "Application_access"} # Create the payload for the assignment
$AppRoleAssignment = @{
    "PrincipalId" = $ManagedIdentity.Id
    "ResourceId" = $TeamsApp.Id
    "AppRoleId" = $AppPermission.Id }
# Assign the role to the service principal for the managed identity.
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentity.Id -BodyParameter $AppRoleAssignment

Y después de eso, seguí asignando los permisos Graph necesarios a la entidad de servicio. Así es como agregué el permiso necesario para agregar un nuevo miembro a un canal:

$GraphApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'" # Microsoft Graph
$Role = $GraphApp.AppRoles | Where-Object {$_.Value -eq  'ChannelMember.ReadWrite.All'}
$AppRoleAssignment = @{
    "PrincipalId" = $ManagedIdentity.Id
    "ResourceId" = $GraphApp.Id
    "AppRoleId" = $Role.Id }
# Assign the Graph permission
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentity.Id -BodyParameter $AppRoleAssignment

Si comete un error y asigna un permiso que no es necesario, puede eliminarlo buscando el identificador para la asignación del permiso en el conjunto que posee la entidad principal de servicio y ejecutando Remove-MgServicePrincipalAppRoleAssignment. cmdlet. Esto es lo que hice para eliminar el permiso TeamWork.Migrate.All.

[Array]$SPPermissions = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentity.Id
$Role = $GraphApp.AppRoles | Where-Object {$_.Value -eq "TeamWork.Migrate.All"}
$Assignment = $SpPermissions | Where-Object {$_.AppRoleId -eq $Role.Id}
Remove-MgServicePrincipalAppRoleAssignment -AppRoleAssignmentId $Assignment.Id -ServicePrincipalId $ManagedIdentity.Id

Es posible que en este momento se te pasen por la cabeza dos cosas. En primer lugar, ¿están todos estos pasos documentados por Microsoft? Y en segundo lugar, ¿por qué es tan complejo el proceso de gestión de permisos para una identidad gestionada? Mi opinión es que el ámbito carece de documentación coherente. Microsoft cubre los conceptos básicos en diferentes lugares, pero no parece haber logrado reunir todo para hacer que la administración de permisos para una identidad administrada sea una operación sencilla. En cambio, Microsoft deja que otros conviertan la teoría en práctica.

En cualquier caso, después de agregar los roles y permisos necesarios a la identidad administrada, cuando el script se autentica, el token de acceso generado por Azure AD incluye todos los permisos y el script puede realizar un trabajo real (Figura 2).

Publicar en equipos

Como se mencionó anteriormente, quería que el script mostrara detalles de los nuevos miembros en un canal. Se presentaron dos cuestiones:

  1. Estamos publicando en un canal compartido. El acceso al canal está limitado a la membresía del canal. La identidad administrada no es miembro del canal y no parece haber una manera de hacerse pasar por un miembro del canal.
  2. Los canales compartidos no admiten conectores, por lo que no es posible utilizar el conector de webhook entrante para publicar un mensaje (a menos que decida publicar en otro canal del equipo anfitrión).

Utilicé Azure KeyVault para almacenar las credenciales del usuario y otra información necesaria para conectarme a PnP. Almacenar esta información en Azure Key Vault facilita cambiar la cuenta utilizada para publicar mensajes o el canal de destino. Para publicar el mensaje, utilicé prácticamente el mismo código que se explica en este artículo para crear una parte del cuerpo HTML que contiene detalles de los nuevos miembros del canal (Figura 3).

Después de que todo funcionó, publiqué el runbook y lo agregué a una programación para que Azure Automation ejecutara el script todas las semanas. El guión ha funcionado bastante felizmente durante un par de semanas, así que lo llamo un éxito. Puede descargar el script completo desde GitHub.

Aprendizajes y conclusión

Incluso con algunas asperezas, la combinación de las API de Microsoft Graph, Azure Automation e identidades administradas es una buena manera de descargar el procesamiento de scripts que consumen muchos recursos, como aquellos que escanean a todos los miembros de los inquilinos para generar informes. Las cosas serían aún mejores si todos los módulos principales de PowerShell utilizados para la administración de Microsoft 365 admitieran identidades administradas de manera más completa y elegante que lo hacen hoy. Eso podría llegar con el tiempo.

Gestión de riesgos de ciberseguridad para Active Directory

Descubra cómo prevenir y recuperarse de ataques AD a través de estas soluciones de gestión de riesgos de ciberseguridad.

Artículos relacionados