Baja automatizada de portátiles con Microsoft Intune

Resumen

La baja de una persona empleada es tanto un evento de identidad como un problema de control del endpoint. Deshabilitar una cuenta no elimina los datos ya almacenados en un portátil, y enviar una acción de Intune no demuestra que un dispositivo sin conexión la haya recibido o completado. Un diseño defendible coordina ambos planos de control y registra el estado de cada uno.

Una arquitectura práctica de Microsoft comienza con un evento de salida autoritativo de RR. HH., utiliza Microsoft Entra Lifecycle Workflows para las tareas de identidad compatibles, llama a una Azure Logic App mediante una extensión de tarea personalizada para orquestar el dispositivo e invoca la acción remota adecuada de Intune a través de Microsoft Graph. El diseño debe cerrar el acceso de forma segura, detenerse ante una selección ambigua del dispositivo y mantener abierta una excepción hasta verificar el resultado del endpoint.

Lo que la arquitectura debe representar correctamente

• La contención de identidad no destruye todos los tokens al instante. Deshabilita primero la cuenta y revoca los tokens de actualización y de sesión del navegador. Los tokens de acceso existentes pueden seguir siendo válidos hasta que el servicio los reevalúe o caduquen; la evaluación continua de acceso solo reduce esa ventana en aplicaciones y condiciones compatibles.
• Lifecycle Workflows no ejecuta todas las acciones de Intune de forma nativa. Usa las tareas de salida integradas para las operaciones de identidad compatibles. Para buscar el dispositivo, aplicar lógica de aprobación y ejecutar acciones de Intune, llama a una Azure Logic App mediante una extensión de tarea personalizada de Lifecycle Workflows u otro servicio de orquestación controlado.
• Una respuesta correcta de Graph no demuestra que el endpoint haya terminado. La acción remota puede aceptarse mientras el portátil está apagado o desconectado. Registra por separado la aceptación, entrega pendiente, sincronización del dispositivo, estado de la acción y resultado verificado del cliente.
• El borrado remoto no es un certificado universal de borrado criptográfico. Intune Borrar elimina datos y ajustes restableciendo el dispositivo, pero el comportamiento del almacenamiento varía según la plataforma y la configuración. Mantén un estándar separado de saneamiento de soportes para eliminación, retenciones legales, hardware dañado y requisitos que exijan destrucción verificada.
• Una política de cumplimiento no es un motor de borrado sin conexión. Intune puede marcar como no conforme un dispositivo desactualizado o inseguro, y el acceso condicional puede bloquear recursos protegidos cuando se evalúe ese estado. Las acciones de cumplimiento no hacen que un portátil Windows desconectado de Internet ejecute un borrado; la rotación de claves de BitLocker es una acción remota independiente, no una consecuencia automática de un periodo de gracia.

Arquitectura de baja automatizada

• 1. Recibir un evento de salida autoritativo. Usa el aprovisionamiento impulsado por RR. HH. u otra fuente aprobada para proporcionar el identificador de la persona, hora efectiva de salida, clase de terminación, responsable, estado de retención legal e identificadores de activos conocidos. Normaliza zonas horarias y procesa de forma idempotente los eventos repetidos.
• 2. Contener la identidad. A la hora efectiva, deshabilita la cuenta de Microsoft Entra, revoca tokens de actualización y de sesión del navegador, elimina las asignaciones compatibles de grupos, equipos, paquetes de acceso y licencias directas según la política, y conserva el acceso necesario para retención legal o traspaso al responsable. Eliminar una pertenencia a grupo puede cambiar el ámbito del acceso condicional, pero no elimina sus políticas.
• 3. Resolver el dispositivo administrado correcto. Asocia los registros de persona y activo con el ID managedDevice de Intune. No borres todos los dispositivos vinculados a un usuario: contempla dispositivos compartidos, varios portátiles asignados, registros obsoletos, inscripción BYOD, equipos de préstamo y dispositivos ya transferidos a otro custodio.
• 4. Aplicar una decisión basada en riesgo. Usa la propiedad, custodia física, intención de reutilización, retención legal, estado de cifrado, última sincronización y riesgo de la salida para elegir entre Retirar, Borrar, Restablecimiento de Autopilot, cuarentena o revisión manual. Exige aprobación para coincidencias ambiguas y acciones destructivas fuera de una política preaprobada.
• 5. Enviar con mínimo privilegio. Haz que la carga de trabajo de orquestación llame a Microsoft Graph con el permiso de operaciones privilegiadas de Intune necesario para la acción seleccionada. Protege la identidad de la carga, limita quién puede modificar el flujo, valida cada identificador y evita guardar credenciales amplias de Graph en scripts o tickets.
• 6. Verificar y cerrar. Correlaciona el evento de RR. HH., ejecución del flujo, tareas de identidad, decisión del dispositivo, solicitud de Graph, estado de la acción de Intune, última sincronización, resultado del cliente y devolución física del activo. Cierra el caso solo cuando se confirme el resultado requerido o un responsable nominal acepte el riesgo residual.

Elegir la acción de Intune según el resultado

Ejemplo reforzado de envío con PowerShell

El siguiente ejemplo de referencia acepta deliberadamente un único ID managedDevice de Intune aprobado y un número de serie esperado. No descubre dispositivos por UPN ni restablece todos los equipos asociados a una persona que ha salido. Resuelve y aprueba el activo antes en el flujo, confirma que el dispositivo recuperado es apto para Restablecimiento de Autopilot y verifica la disponibilidad del Entorno de recuperación de Windows en tus controles de despliegue.

Para facilitar la lectura, el ejemplo obtiene un secreto de cliente de una variable de entorno del proceso. En producción, prefiere una identidad administrada o credencial de certificado e inyecta secretos desde un almacén aprobado, no desde el historial de comandos, código fuente, registros o tickets. La aplicación necesita DeviceManagementManagedDevices.Read.All para leer el destino y DeviceManagementManagedDevices.PrivilegedOperations.All para enviar la acción de borrado.

• Protecciones para acciones destructivas. SupportsShouldProcess y ConfirmImpact High proporcionan -WhatIf y confirmación interactiva. Un flujo desatendido solo debe pasar -Confirm:$false después de que sus propias puertas de política y aprobación hayan seleccionado el ID managedDevice y número de serie exactos.
• Acción actual de Graph. La documentación actual de Microsoft para Restablecimiento de Autopilot remite a POST /deviceManagement/managedDevices/{managedDeviceId}/wipe. El ejemplo conserva los datos de inscripción y elimina los datos del usuario; valida este comportamiento en un anillo no productivo con las versiones de Windows e Intune que operas.
• El envío no es la finalización. Una solicitud correcta solo genera un registro Dispatched. El flujo envolvente debe seguir el estado de la acción de Intune, sincronización del dispositivo, finalización del cliente y custodia física antes de cerrar el caso.

<#
.SYNOPSIS
    Dispatches an approved Windows Autopilot-style reset through Microsoft Graph.
.DESCRIPTION
    Validates one Intune managed-device ID against an expected serial number,
    then calls the documented managedDevice wipe action while retaining enrollment.
.NOTES
    Required application permissions:
    DeviceManagementManagedDevices.Read.All
    DeviceManagementManagedDevices.PrivilegedOperations.All
#>

[CmdletBinding(SupportsShouldProcess = $true, ConfirmImpact = 'High')]
param (
    [Parameter(Mandatory = $true)]
    [guid]$TenantId,

    [Parameter(Mandatory = $true)]
    [guid]$ClientId,

    [Parameter(Mandatory = $true)]
    [guid]$ManagedDeviceId,

    [Parameter(Mandatory = $true)]
    [ValidateNotNullOrEmpty()]
    [string]$ExpectedSerialNumber
)

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'

$clientSecret = $env:GIDEON_GRAPH_CLIENT_SECRET
if ([string]::IsNullOrWhiteSpace($clientSecret)) {
    throw 'GIDEON_GRAPH_CLIENT_SECRET must be injected by an approved secret store.'
}

$tokenResponse = $null
$headers = $null

try {
    $tokenUri = "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token"
    $tokenBody = @{
        client_id     = $ClientId
        client_secret = $clientSecret
        scope         = 'https://graph.microsoft.com/.default'
        grant_type    = 'client_credentials'
    }

    $tokenResponse = Invoke-RestMethod -Uri $tokenUri -Method Post -Body $tokenBody
    if ([string]::IsNullOrWhiteSpace($tokenResponse.access_token)) {
        throw 'Microsoft identity platform returned no access token.'
    }

    $headers = @{
        Authorization = "Bearer $($tokenResponse.access_token)"
        'Content-Type' = 'application/json'
    }

    $deviceUri = "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/$($ManagedDeviceId)?`$select=id,deviceName,serialNumber,operatingSystem,lastSyncDateTime,managementAgent"
    $device = Invoke-RestMethod -Uri $deviceUri -Method Get -Headers $headers

    if ($device.operatingSystem -ne 'Windows') {
        throw "Managed device '$ManagedDeviceId' is not a Windows device."
    }

    if (-not [string]::Equals(
        $device.serialNumber,
        $ExpectedSerialNumber,
        [System.StringComparison]::OrdinalIgnoreCase
    )) {
        throw "Serial mismatch for managed device '$ManagedDeviceId'."
    }

    $operation = 'Remove user data while retaining Intune enrollment'
    $target = "$($device.deviceName) [$($device.serialNumber)]"
    if (-not $PSCmdlet.ShouldProcess($target, $operation)) {
        return [pscustomobject]@{
            Status = 'Skipped'
            ManagedDeviceId = $device.id
            DeviceName = $device.deviceName
            SerialNumber = $device.serialNumber
        }
    }

    $resetUri = "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/$($device.id)/wipe"
    $payload = @{
        keepEnrollmentData = $true
        keepUserData = $false
    } | ConvertTo-Json

    Invoke-RestMethod -Uri $resetUri -Method Post -Headers $headers -Body $payload

    [pscustomobject]@{
        Status = 'Dispatched'
        ManagedDeviceId = $device.id
        DeviceName = $device.deviceName
        SerialNumber = $device.serialNumber
        LastSyncDateTime = $device.lastSyncDateTime
        DispatchedAtUtc = (Get-Date).ToUniversalTime().ToString('o')
    }
}
finally {
    $clientSecret = $null
    $tokenResponse = $null
    $headers = $null
}

Diseñar para portátiles sin conexión

Las acciones remotas de Intune requieren que el dispositivo se conecte a Internet y se sincronice. Por tanto, un portátil apagado sigue siendo un riesgo pendiente incluso después de deshabilitar su identidad. El flujo debe mostrar ese estado en lugar de declarar terminada la baja.

Aplica defensa en profundidad durante la espera: cifrado completo de disco, acceso del usuario deshabilitado, acceso condicional ligado al cumplimiento actual del dispositivo, rutas de credenciales locales breves y bien gobernadas, controles de detección del endpoint y procedimientos de recuperación física. Ninguno de estos controles demuestra que una acción remota en cola se haya ejecutado.

• Definir umbrales de escalado. Escala según el riesgo de la salida, propiedad, custodia y tiempo desde la última sincronización. Un portátil corporativo desaparecido tras una salida involuntaria no debe compartir el mismo plazo que un dispositivo confirmado en el área de devoluciones de TI.
• Mantener la acción pendiente. Consulta o suscríbete al estado disponible de la acción y del dispositivo en Intune, registra cada reintento de forma segura y evita sustituir una orden destructiva por otra acción pendiente incompatible.
• Coordinar la recuperación física. Vincula el flujo de seguridad con la gestión de activos, envíos, confirmación del responsable y procedimientos para dispositivos perdidos, de modo que la contención técnica y la custodia física converjan en un caso.

Evidencia útil para auditoría

• Evidencia del disparador. Fuente autoritativa, identificador del evento, hora efectiva, hora de recepción, versión del flujo y clave de idempotencia.
• Evidencia de identidad. Resultado de deshabilitar la cuenta, revocación de sesiones, cambios de derechos, excepciones y marca de tiempo de cada tarea.
• Evidencia de decisión. ID del dispositivo resuelto, número de serie, propiedad, custodia, última sincronización, acción elegida, versión de la política, aprobador cuando proceda y alternativas rechazadas.
• Evidencia del endpoint. Correlación de la solicitud de Graph, estado de la acción de Intune, evidencia de entrega o sincronización, resultado del cliente, estado de devolución física e historial de escalado.
• Retención e integridad. Envía los registros a una plataforma de auditoría o seguridad con retención controlada, controles de acceso y tratamiento que permita detectar manipulaciones. Los registros de servicio de Microsoft son evidencia valiosa, pero llamar inmutables por defecto a todos los registros de baja exagera sus garantías.

Lista de comprobación de implementación

• Define rutas para salidas voluntarias e involuntarias, contratistas, dispositivos perdidos, retención legal, dispositivos compartidos y fallecimientos antes de activar automatización destructiva.
• Separa la hora efectiva de salida de la hora de recepción del evento, normaliza zonas horarias y prueba transiciones de horario de verano.
• Usa identificadores estables de objetos de Microsoft Entra e Intune, no nombres visibles, correos o nombres de dispositivo, como claves para acciones destructivas.
• Procesa eventos de forma idempotente e impide que duplicados o eventos fuera de orden envíen acciones incompatibles.
• Exige aprobación manual cuando la propiedad, custodia, retención legal o identidad del dispositivo sean ambiguas.
• Prueba equipos apagados, modo avión, registros obsoletos, varios dispositivos, dispositivos compartidos y equipos ya retirados en un anillo no productivo.
• Mide por separado el tiempo de contención de identidad, entrega al dispositivo, finalización, antigüedad de excepciones, prevención de acciones sobre el dispositivo equivocado y devolución física.

Recursos relacionados

• Usa el modelo completo del ciclo de vida en gestión de endpoints sin intervención para equipos de seguridad.
• Define el mínimo preventivo de controles de Windows con la línea base de seguridad de Windows Autopilot para equipos medianos.
• Planifica visibilidad más profunda sin conexión y controles locales aprobados con arquitectura MDM más agente nativo.
• Descubre Gideon Endpoint Management y sus rutas de evaluación para ciclo de vida, postura y remediación.

Referencias principales

• Microsoft describe las tareas de identidad integradas y la extensibilidad con Logic Apps en Planificación de una implementación de Lifecycle Workflows.
• Microsoft documenta el límite de la extensión personalizada en Extensiones de tareas personalizadas de Lifecycle Workflows.
• Microsoft define conectividad, prioridad y estado de acciones remotas en Acciones de dispositivo en Microsoft Intune.
• Microsoft documenta la eliminación de datos corporativos y la siguiente sincronización en Acción remota de dispositivo: Retirar.
• Microsoft documenta el restablecimiento y sus opciones específicas por plataforma en Acción de dispositivo: Borrar.
• Microsoft documenta la reutilización y la configuración conservada en Acción de dispositivo: Restablecimiento de Autopilot.
• Microsoft explica por qué la aplicación de tokens de acceso varía según el servicio en Evaluación continua de acceso en Microsoft Entra.

Cómo usar este recurso

Convierte cada fase de la arquitectura en un control con responsable y nivel de servicio medible. Pilota primero con salidas sintéticas y dispositivos de prueba, demuestra que las coincidencias ambiguas se detienen de forma segura y define el éxito como contención de identidad verificada más un resultado confirmado del endpoint o una excepción aceptada formalmente.