Uso de Azure Automation para procesar datos de Exchange Online con PowerShell
Runbook útil en algunas circunstancias
Actualización: Esta ratícula ahora está un poco desactualizada. Azure Automation ya no admite cuentas RunAs y el módulo PowerShell de administración de Exchange Online ahora admite identidades administradas.
Los artículos de Practical365.com suelen incluir código de PowerShell para ilustrar los principios de trabajo con datos de Microsoft 365 para automatizar operaciones administrativas comunes. A veces, los lectores preguntan si es posible usar el código con los runbooks de Azure Automation. Dada la respuesta de un consultor clásico, mi respuesta es "depende". Entre las dependencias se encuentran lo que hace el código, los módulos de PowerShell involucrados y si un script es interactivo o no. Sean McAvinue cubre los conceptos básicos en su artículo sobre la implementación de un descargo de responsabilidad programado en las reglas de transporte de Exchange Online, pero quería trabajar en el proceso y documentar cómo crear una cuenta de automatización de Azure y algunos runbooks. Esto es lo que descubrí.
Actualización: consulte este artículo para obtener más información sobre el uso de Exchange Online con Azure Automation e identidades administradas.
El papel de las cuentas de Azure Automation
Azure Automation es la capacidad de ejecutar el trabajo mediante máquinas virtuales. Para usar Azure Automation, debe tener una cuenta de Azure Automation asociada con una suscripción de Azure (para pagar por los recursos que consume). A su vez, la cuenta de automatización admite una cuenta Azure RunAs, que se utiliza para la autenticación y obtener acceso a los recursos necesarios para realizar el trabajo, como ejecutar un script de PowerShell en un runbook. Para que todo funcione, yo:
- Ha iniciado sesión en Azure Portal con una cuenta que tiene el rol de propietario de Azure para que la suscripción la use en la cuenta de automatización.
- Creó una nueva cuenta de automatización. Debe especificar la suscripción de Azure en este punto.
- Creó una cuenta RunAs. Esto da como resultado la creación de una aplicación y una entidad de servicio en Azure AD, que sirve como base para la autenticación y los permisos. Azure crea un certificado X.509 (un activo de certificación en la cuenta) que la entidad de servicio puede usar para la autenticación durante un año (el certificado se puede renovar fácilmente). En la actualidad, Exchange Online no admite identidades administradas de Azure, por lo que utilizar una cuenta RunAs es una buena opción. Finalmente, un recurso de conexión llamado AzureRunAsConnection pasa a estar disponible. Veremos cómo se utiliza este activo más adelante.
Después de crear la cuenta RunAs, registre la información proporcionada por Azure para el identificador de la aplicación y el identificador del objeto principal de servicio. Necesitaremos estos detalles más adelante para asignar permisos a través de PowerShell.
Lea acerca de cómo usar un runbook con Microsoft Graph SDK para PowerShell.
Uso de Exchange Online PowerShell en Azure Automation
Exchange Online tiene el soporte más completo para PowerShell de cualquier carga de trabajo de Microsoft 365. Además de los buzones de correo y otros aspectos de la administración del correo electrónico, el módulo abarca grupos de Microsoft 365 y, si conecta otra sesión al punto final de cumplimiento, incluye cmdlets para administrar el gobierno de la información y otras soluciones de cumplimiento. Por lo tanto, tiene sentido comenzar cualquier exploración de Azure Automation para Microsoft con Exchange Online.
Si ha utilizado PowerShell para ejecutar consultas de Microsoft Graph, sabe que necesita registrar una aplicación para tener los permisos necesarios para acceder a los datos del usuario y otros datos. En la mayoría de las situaciones, las aplicaciones necesitan utilizar permisos de aplicación para realizar tareas como leer perfiles de usuario, información de grupo, etc. Los administradores deben otorgar consentimiento para que las aplicaciones utilicen los permisos de las aplicaciones.
De la misma manera, antes de que una cuenta RunAs pueda usar cmdlets en el módulo de administración de Exchange Online, un administrador debe otorgar consentimiento para el acceso de administración a Exchange Online. Puede hacerlo a través de la sección Aplicaciones registradas del centro de administración de Azure AD en tres pasos:
- Seleccione la aplicación creada para la cuenta RunAs (su nombre será la cuenta de automatización más una cadena aleatoria como ExoAutomationAccount_Y6LgjDYIfPnxmFzrqdbaClsnTD/gN4BNnVMywiju5hk=)
- Asigne el permiso ExchangeManageAsApp desde la API de Office 365 Exchange Online.
- Otorgar consentimiento para la organización.
La Figura 1 muestra que el permiso ExchangeManageAsApp se otorga con consentimiento.
También debe agregar la entidad de servicio de la cuenta RunAs a la función de administrador de Exchange. Puede hacerlo en la sección Roles y administradores del centro de administración de Azure AD (Figura 2).
Importar el módulo de administración en línea de Exchange
La entidad de servicio de la cuenta RunAs ahora tiene los permisos adecuados para actuar como administrador de Exchange Online. El siguiente paso es permitir que la cuenta de automatización utilice los cmdlets de Exchange. Recuerde que Azure Automation no está vinculado a máquinas específicas, por lo que debe importar el módulo de administración de Exchange Online para que esté disponible como recurso compartido para la cuenta de automatización. Cuando Azure Automation ejecuta un runbook que llama a cmdlets de Exchange, carga el módulo automáticamente.
Primero, busque Módulos en la sección de recursos compartidos (muchos módulos ya están precargados, pero Exchange no es uno). Luego explore la galería de módulos para encontrar el módulo de administración de Exchange Online (Figura 3). Seleccione el módulo, elija la versión 5.1 para la versión del tiempo de ejecución de PowerShell y luego importe el módulo. Esto tardará unos minutos en completarse. Puede actualizar la vista de módulos para saber cuándo finaliza la importación.
Otros módulos de Microsoft 365 también están disponibles en la galería, incluidos Azure AD, Teams y SharePoint Online. Muchas tareas requieren cmdlets de varios módulos, por lo que, según lo que desee hacer, es posible que deba importar otros módulos.
Crear y probar un Runbook
Los runbooks son lo que utiliza Azure Automation para realizar el trabajo. En este caso, podría pensar en un runbook como un script de PowerShell completo listo para ejecutarse en un entorno limitado. Crea nuevos runbooks en la sección Automatización de procesos para la cuenta de automatización. Azure carga varios runbooks de tutoriales en la cuenta para ayudar a las personas a comenzar con la técnica.
Para probar las cosas, tomé un script que escanea el registro de auditoría para informar los eventos de eliminación del grupo y copié el código en un nuevo runbook de PowerShell. Antes del código copiado, inserté algunas líneas para crear una sesión en la conexión de automatización (AzureRunAsConnection) y conectarme a Exchange Online y autenticarme usando la huella digital del certificado creada para la cuenta usando la sesión con la conexión de automatización.
$Session = Get-AutomationConnection –Name AzureRunAsConnection
$Tenant = 'office365itpros.onmicrosoft.com'
Connect-ExchangeOnline –CertificateThumbprint $Session.CertificateThumbprint –AppId $Session.ApplicationID –ShowBanner:$false –Organization $Tenant
Recuerde, nuestra cuenta de automatización tiene permiso para administrar Exchange como una aplicación y la entidad de servicio es miembro del grupo de funciones de administrador de Exchange, por lo que una vez que el runbook se autentica, puede ejecutar cualquier cmdlet de administración de Exchange.
Si alguna vez ha utilizado PowerShell ISE o el editor de Cloud Shell para trabajar con código de PowerShell, el editor de runbook le resultará familiar (Figura 4). Transferir código del uso interactivo a la automatización requiere la eliminación de cualquier cmdlet de interacción del usuario (como Read-Host), mientras que Write-Output reemplaza a Write-Host. Recuerde, el código se ejecuta en una zona de pruebas sin cabeza, por lo que no tiene sentido incluir interacciones de usuarios. Cuando esté listo, guarde el código y haga clic en el icono del panel de prueba.
El panel de prueba le permite ejecutar el runbook y comprobar que su código funciona. Haga clic en iniciar para comenzar. Azure Automation pone en cola el runbook y cuando un recurso (una máquina de espacio aislado) está disponible, el código se ejecuta. No verá nada hasta que ocurra un error o finalice el script, momento en el que el panel Prueba muestra cualquier resultado (Figura 5).
Si ejecuta un script varias veces durante un período breve, Exchange Online podría limitar su conexión. Cuando esto sucede, llega el momento de tomar una taza de café. El mecanismo de aceleración dejará de funcionar después de unos minutos y podrás volver a intentarlo. Como alternativa, incluya el cmdlet Disconnect-ExchangeOnline en su secuencia de comandos para cerrar la sesión.
Una vez que esté seguro de que el código funciona, puede publicar el runbook (haga clic en el ícono Publicar cuando edite el código, como se muestra en la Figura 4). Luego tendrá una versión borrador del runbook para un mayor desarrollo y una versión publicada que se puede ejecutar de diferentes maneras. Por ejemplo, puede programar Azure Automation para que ejecute la ejecución una vez en una fecha y hora determinadas o que se ejecute a intervalos.
Autenticación basada en certificados para seguridad y cumplimiento
La descripción hasta ahora cubre los cmdlets en el módulo de administración principal de Exchange Online. El módulo también incluye los cmdlets de seguridad y cumplimiento, que se pueden utilizar después de ejecutar el cmdlet Connect-IPPSSession. Actualmente, estos cmdlets no admiten la autenticación basada en certificados, pero pronto lo harán. Según la notificación MC316448 del centro de mensajes de Microsoft 365 (21 de enero de 2022), la capacidad debería estar disponible en todas partes a principios de marzo.
Por ahora, si desea utilizar los cmdlets de seguridad y cumplimiento, puede agregar una credencial de nombre de usuario y contraseña a la cuenta de automatización. La cuenta no puede utilizar la autenticación multifactor (MFA) y debe ser un administrador de Exchange. La falta de MFA hace que este sea un método poco deseable, pero sirve para demostrar que Azure Automation admite diferentes tipos de credenciales. He usado este método con otros módulos que no admiten la autenticación basada en certificados, como el módulo de administración de SharePoint Online.
Este código accede a un nombre de usuario y contraseña almacenados como una credencial en la cuenta de automatización y denominado O365Password y utiliza la credencial para conectarse al punto final de seguridad y cumplimiento:
$O365Cred = Get-AutomationPSCredential -Name "O365Password"
Connect-IPPSSession -Credential $O365Cred
Automatización con API Graph
Por supuesto, los cmdlets de Exchange Online no cubren todos los datos a los que le gustaría acceder, pero existe una buena posibilidad de que una API de Microsoft Graph sí lo haga. Como ejemplo, tomé un script utilizado para informar información de inicio de sesión para entidades de servicio y lo importé a un runbook. Normalmente, cuando escribe una secuencia de comandos para interactuar con consultas de Graph API, hay un preámbulo para identificar una aplicación registrada, un inquilino y un secreto de aplicación (o certificado) que se utiliza para autenticar y devolver un token de acceso. Cuando usa un runbook, usamos la cuenta de automatización en lugar de una aplicación registrada y la huella digital del certificado en lugar de un secreto de aplicación. Por lo tanto, reemplazamos el preámbulo normal con un código para conectarnos así:
# Set up a connection
$Connection = Get-AutomationConnection -Name AzureRunAsConnection
# Get certificate from the automation account
$Certificate = Get-AutomationCertificate -Name AzureRunAsCertificate
# Get an access token using the Get-MsalToken cmdlet from the MSAL.PS Module
$GraphConnection = Get-MsalToken -ClientCertificate $Certificate -ClientId $Connection.ApplicationID -TenantId $Connection.TenantID
# Populate the headers for our Graph queries
$Header = @{Authorization = "Bearer $($GraphConnection.AccessToken)"}
Este código utiliza un módulo llamado MSAL.PS (Biblioteca de autenticación de Microsoft) para obtener un token de acceso. Puedes leer más sobre el módulo aquí.
Recuerde que la entidad de servicio de la cuenta RunAs necesita permisos para acceder a los datos. En este caso, un administrador debe otorgarle consentimiento para los permisos de aplicación Directory.Read.All y AuditLog.Read.All. El token de acceso confirma que los permisos están disponibles, por lo que podemos ejecutar:
$Uri = "https://graph.microsoft.com/beta/auditLogs/signIns?&`$filter=createdDateTime ge " + $StartDate + " and createdDateTime le " + $EndDate + " and signInEventTypes/any(z:z eq 'servicePrincipal')"
[array]$SpSignInData = Invoke-RestMethod -Method GET -Uri $Uri -ContentType "application/json" -Headers $Header
Después de eso, es cuestión de procesar lo que devuelva la consulta Graph e informarlo. La Figura 6 muestra cómo aparecen los datos en el panel Prueba.
Automatización para la empresa
Mi perspectiva es que el mejor uso de los runbooks de Azure Automation es procesar grandes cantidades de datos en trabajos que probablemente lleven períodos prolongados, como tomar extractos diarios de datos del registro de auditoría de Office 365 y escribirlos en un repositorio externo para su retención a largo plazo. . En esencia, se trata de una jugada empresarial.
Otros procedimientos administrativos ad hoc, como comprobar qué grupos de Microsoft 365 no tienen propietarios o qué equipos carecen de etiquetas de confidencialidad, se ejecutan mejor de forma interactiva, a menos que una organización realice estas comprobaciones periódicamente. En ese caso, un runbook es una buena opción.
Las cosas para recordar son:
- Necesita una suscripción a Azure. No gastarás mucho a menos que tus cantidades de datos sean grandes, pero aún así debes tener una suscripción. Logré gastar cinco centavos en runbooks desarrollados durante la redacción de este artículo.
- No se produce ninguna interacción del usuario en los scripts. Por ejemplo, no puede pedirle a un usuario que confirme que se debe realizar una operación.
- Los runbooks se ejecutan en máquinas sandbox. Si desea guardar los resultados del procesamiento como un archivo, debe hacerlo en una ubicación de red. De lo contrario, puede enviar un correo electrónico o publicar un mensaje en un canal de Teams.
Al igual que con cualquier otra tecnología, la genialidad radica en aprovechar las fortalezas de Azure Automation y al mismo tiempo minimizar sus desventajas. Como cualquier herramienta, una vez que sepa cómo usarlas para realizar un trabajo real, probablemente encontrará utilidad para uno o dos runbooks. Exchange Online y otros módulos de Microsoft 365 PowerShell son accesibles y utilizables en runbooks, al igual que las consultas de la API de Microsoft Graph, por lo que existe un gran potencial. Un poco de práctica y prueba y error pronto revelarán si los runbooks de Azure Automation son lo suficientemente potentes como para convertirse en una herramienta crítica en su conjunto de herramientas de administración de inquilinos.