BitLocker con Intune y Active Directory: cómo cifrar los equipos de la empresa sin perder ninguna clave de recuperación

BitLocker cifra el disco de cada portátil, pero en una empresa lo difícil no es cifrar: es saber, el día que un equipo pide la clave de recuperación, dónde quedó guardada. Esta guía explica cómo gestionar BitLocker con Intune, que deja la clave de BitLocker en Entra ID, y BitLocker en Active Directory, donde la guarda la directiva de grupo; cómo activar BitLocker por GPO sin dejar equipos sin clave; cómo verla con BitLocker Recovery Password Viewer, y cómo revisar después que ningún equipo se quedó sin ella.

Sirve a dos lectores. Si dirige la empresa o el área y no es de sistemas, lea la tabla del primer apartado y el de las cuatro decisiones: con ellos sabe qué tiene que estar resuelto antes de cifrar y qué preguntarle a quien administra sus equipos. Si es técnico, el resto le da los ajustes con sus nombres, las órdenes para revisar todo el parque y las trampas que encontramos en la documentación de Microsoft, que en varios puntos se contradice. Para el manejo de un equipo con la consola, que aquí no se repite, está la guía de BitLocker con PowerShell.

Los nombres de las directivas de grupo se leyeron en español de la plantilla que trae Windows 11, los mensajes de los eventos salen del propio sistema y las órdenes se validaron con Windows PowerShell 5.1 y PowerShell 7.6.9. Lo que hace BitLocker dentro de Intune y de Microsoft Entra ID se cuenta según la documentación de Microsoft, porque no lo ejecutamos sobre ninguna organización real, y el artículo lo dice en cada caso.

BitLocker con Intune o en Active Directory: cuál le toca

La respuesta depende de cómo está unido cada equipo, no de la preferencia de nadie. Según la guía de configuración de BitLocker, la clave va a un sitio u otro así:

Cómo está el equipo	Quién lo administra	Dónde queda la clave
Unido a Microsoft Entra ID (solo nube)	Intune	En Microsoft Entra ID
Unido a Microsoft Entra híbrido (dominio y nube)	Directivas de grupo, Intune o las dos	En Active Directory y en Microsoft Entra ID
Unido a un dominio de Active Directory	Directivas de grupo	En Active Directory, si la directiva lo pide
Sin unir, con una cuenta de trabajo agregada	Nadie de forma central	Microsoft no documenta copia automática para este caso
Personal, con cuenta Microsoft	El usuario	En la cuenta Microsoft del usuario

La cuarta fila es más común de lo que parece. El portátil de nuestras pruebas, por ejemplo, tenía la cuenta de trabajo agregada en Windows, y dsregcmd /status lo mostraba solo registrado: AzureAdJoined : NO, DomainJoined : NO y WorkplaceJoined : YES. Agregar la cuenta del trabajo no es unir el equipo, y la copia automática de la clave que documenta Microsoft es para los equipos unidos o híbridos.

En resumen: si la empresa trabaja con Microsoft 365 y portátiles que no pasan por un servidor propio, le toca BitLocker con Intune. Si tiene un dominio de Active Directory, le toca la directiva de grupo, y si tiene las dos cosas, la clave queda en ambos sitios.

Las cuatro decisiones antes de cifrar el primer equipo

Cifrar es la parte fácil. Estas cuatro preguntas deciden si el cifrado protege los datos o los deja encerrados para siempre:

1. Dónde queda la clave. Tiene que estar en un sitio central antes de cifrar, no después. Microsoft lo dice en las preguntas frecuentes de BitLocker: si el disco se cifró antes de aplicar la directiva, la clave no se copia sola al aplicarla.
2. Quién puede verla. Una clave de recuperación abre el disco. En Microsoft Entra ID la pueden leer siete roles, dos de ellos de solo lectura, y de fábrica cada persona puede ver la de sus propios equipos.
3. Qué pasa cuando se usa. Si un técnico dicta la clave por teléfono, esa clave ya no es secreta. En los equipos unidos a Microsoft Entra ID, o híbridos, BitLocker con Intune puede cambiarla sola después de usarla; en un equipo que solo está en el dominio, esa rotación no existe.
4. Qué pasa al retirar un equipo. Borrar el equipo de la consola equivocada borra también su clave o deja el disco sin protección. Lo contamos en el escenario 4.

Si su equipo de TI tiene una respuesta clara para las cuatro, el resto es configuración.

BitLocker con Intune

Cuando se usa BitLocker con Intune, una directiva cifra los equipos y copia cada clave en Microsoft Entra ID. La guía de cifrado con Intune distingue dos modos: el estándar, en el que el usuario puede ver avisos y elegir, y el silencioso, en el que el equipo se cifra sin preguntar y sin que el usuario sea administrador. En una empresa casi siempre conviene el silencioso, porque no depende de que cada persona acepte un aviso.

Requisitos del cifrado silencioso de BitLocker con Intune

Según esa misma página, un equipo solo se cifra en silencio si cumple todo esto:

Requisito	Detalle
Windows	10 versión 1803 o posterior, o 11, si el usuario es administrador; 1809 o posterior si es usuario estándar
Unión	Unido a Microsoft Entra ID o unido a Microsoft Entra híbrido
TPM	Versión 1.2 o posterior
Firmware	UEFI nativo, con arranque seguro activado
Recuperación	Entorno de recuperación de Windows (WinRE) configurado y disponible
Inicio	Sin PIN ni llave USB al arrancar, porque los dos piden intervención del usuario

Con cifrado silencioso, Windows elige el tipo de cifrado según el equipo: solo el espacio usado en los equipos con espera moderna, la de los portátiles que siguen conectados en reposo, y el disco completo en los demás. Para saber cuál tiene un equipo, Microsoft indica powercfg /a.

Un aviso de la misma página que conviene leer antes de desplegar: la línea base de seguridad de Microsoft Defender puede activar el PIN o la llave de inicio con el TPM, y eso bloquea el cifrado silencioso. Si la organización ya aplica líneas base, hay que revisarlas antes.

La directiva de BitLocker en Intune, paso a paso

Para crear la directiva de BitLocker en el centro de administración de Microsoft Intune, Microsoft da esta ruta en inglés; la consola puede mostrarla traducida:

1. Endpoint security, Disk encryption, Create Policy.
2. Plataforma Windows y perfil BitLocker.
3. En la configuración, los ajustes de la tabla siguiente.
4. Asignar la directiva a un grupo de equipos. Mejor primero a un grupo piloto.

Los ajustes de BitLocker con Intune que guardan la clave

Estos son los ajustes de BitLocker que hacen falta para el cifrado silencioso y para que la clave quede en Microsoft Entra ID, con su nombre en Intune y lo que hacen:

Ajuste en Intune	Valor	Para qué
Require Device Encryption	Enabled	Pide cifrar el equipo
Allow Warning For Other Disk Encryption	Disabled	No muestra el aviso de otro cifrado: es lo que hace el cifrado silencioso
Allow Standard User Encryption	Enabled	Permite cifrar aunque quien haya iniciado sesión sea usuario estándar
Require additional authentication at startup	Enabled, con el PIN y la llave de inicio en «Do not allow»	Deja el TPM solo, sin pedir nada al arrancar
Save BitLocker recovery information to Microsoft Entra ID	Enabled	Copia la clave en Microsoft Entra ID
Store recovery information in Microsoft Entra ID before enabling BitLocker	Required	No cifra hasta que la copia funciona
Configure Recovery Password Rotation	Encendida para los equipos unidos a Microsoft Entra ID, o para los unidos y los híbridos	Cambia la clave después de usarla

El segundo ajuste lleva su propia advertencia de Microsoft: con el aviso desactivado, BitLocker cifra aunque haya otro programa de cifrado en el equipo, y eso puede acabar en pérdida de datos o en un equipo que no arranca. Si la empresa usó otro cifrado alguna vez, primero hay que encontrar esos equipos y retirarlo.

Los dos ajustes de la clave son los que de verdad protegen a la empresa. El primero copia la clave; el segundo impide cifrar si la copia falla, de modo que nunca queda un disco cifrado sin su clave en la nube.

Ver la clave de BitLocker en Intune y el informe de cifrado

Cada clave se ve en la ficha del equipo: Devices, All devices, el equipo, Recovery keys y Show Recovery Key. La ficha muestra el identificador de la clave, la clave de 48 dígitos y el tipo de unidad, y cada vez que alguien pulsa ese botón queda una entrada en el registro de auditoría de Microsoft Entra ID, en la categoría KeyManagement. Si la clave no está en Microsoft Entra ID, Intune responde No BitLocker key found for this device.

Para ver todo el parque está el informe de cifrado, que dice de cada equipo si está listo para cifrarse, si el disco del sistema está cifrado y por qué no, cuando falla. Tres detalles de la página del informe que evitan conclusiones falsas:

• El estado puede tardar hasta 24 horas en reflejar un cambio, entre lo que tarda el cifrado y lo que tarda el equipo en informar.
• Solo mira el disco del sistema. Un disco de datos sin cifrar no cambia el estado del equipo.
• Uno de los motivos que puede mostrar es «Recovery key backup failed», la copia de la clave falló. Microsoft recomienda revisar el registro de eventos del equipo y, si hace falta, copiar la clave a mano con manage-bde.

El informe se exporta a un archivo CSV con el botón Export, que es la forma práctica de revisarlo en Excel.

Rotar la clave de BitLocker con Intune después de usarla

Una clave dictada por teléfono queda expuesta. Para eso, BitLocker con Intune tiene dos respuestas. La primera es automática: con Configure Recovery Password Rotation activado, la clave cambia sola después de usarse para desbloquear el equipo. La segunda es manual, la acción BitLocker key rotation en la ficha del equipo, que la página de la acción ubica en Secure.

Las dos exigen Windows 10 versión 1909 o posterior, o Windows 11, y que la directiva tenga la copia a Microsoft Entra ID activada y marcada como obligatoria antes de cifrar. Sin esos dos ajustes, la rotación no hace nada.

Quién puede ver las claves de BitLocker en Intune y Entra ID

Este es el punto que menos se revisa. La referencia de roles de Microsoft Entra da el permiso de leer claves de BitLocker, microsoft.directory/bitlockerKeys/key/read, a estos siete roles:

Rol de Microsoft Entra	Qué suele hacer quien lo tiene
Administrador global	Todo
Administrador de dispositivos en la nube	Administrar los equipos en Microsoft Entra ID
Administrador del departamento de soporte técnico	Restablecer contraseñas y atender usuarios
Administrador de Intune	Administrar Intune
Administrador de seguridad	Administrar la seguridad
Lector de seguridad	Solo leer informes de seguridad
Lector global	Solo leer la configuración

Las dos últimas filas son la sorpresa: dos roles pensados para mirar, no para tocar, pueden abrir cualquier disco cifrado de la empresa. Antes de dar un rol de lector a alguien de fuera de la empresa, conviene saberlo.

Las páginas de Microsoft no dan la misma lista. La guía de BitLocker en Intune nombra tres roles, la de administración de dispositivos de Entra nombra cinco y la referencia de roles, que es la que define los permisos, da los siete de la tabla.

Para ejecutar la rotación de BitLocker en Intune hace falta además un rol de Intune con el permiso Rotate BitLockerKeys: Help Desk Operator o Endpoint Security Manager, según la referencia de roles de Intune. La guía de cifrado llama al segundo «Endpoint Security Administrator», nombre que no aparece en esa referencia.

Autoservicio: que cada persona vea la clave de su equipo

De fábrica, el usuario que figura como propietario de un equipo puede ver su clave sin llamar a nadie, en https://myaccount.microsoft.com, pestaña de dispositivos y opción View BitLocker Keys. Ahorra llamadas a la mesa de ayuda a las siete de la mañana, pero también significa que cualquiera con la contraseña de esa persona puede leer la clave.

En la configuración de dispositivos de Microsoft Entra ID hay un interruptor, Restrict non-admin users from recovering the BitLocker key(s) for their owned devices, que viene en No, es decir, permitiendo el autoservicio. Cambiarlo exige como mínimo el rol de administrador de roles con privilegios. Otra opción, según Microsoft, es dejar el autoservicio y exigir con acceso condicional un equipo que cumpla las directivas para ver la clave.

Hay una contradicción menor en la documentación: la guía de Intune dice que el portal es account.microsoft.com, que es el de las cuentas personales, y la guía de recuperación de BitLocker dice myaccount.microsoft.com, que es el de las cuentas de trabajo. Para una cuenta de la empresa, el bueno es el segundo.

BitLocker en Active Directory

En un dominio, la clave se guarda con una directiva de grupo, y Active Directory la almacena como un objeto hijo de la cuenta del equipo. Lo que hay que saber primero es lo que pasa si no se configura nada: según la guía de configuración, sin la directiva, la información de recuperación no se copia en Active Directory. Cifrar en un dominio no basta para que la clave quede en el dominio.

La directiva de grupo, con sus nombres en español

La plantilla de BitLocker trae 45 directivas, y varias tienen nombres casi iguales. Las de recuperación que sirven hoy están en Configuración del equipo, Directivas, Plantillas administrativas, Componentes de Windows, Cifrado de unidad BitLocker, y luego en una carpeta por tipo de unidad. Estos son los nombres exactos, leídos de la plantilla en español de Windows 11:

Carpeta	Directiva
Unidades del sistema operativo	Elegir cómo se pueden recuperar unidades del sistema operativo protegidas por BitLocker
Unidades de datos fijas	Elegir cómo se pueden recuperar unidades fijas protegidas por BitLocker
Unidades de datos extraíbles	Elegir cómo se pueden recuperar unidades extraíbles protegidas por BitLocker

Las opciones que deciden dónde queda la clave

Dentro de la primera directiva, al habilitarla, aparecen las opciones que deciden todo:

Opción	Valor recomendado	Qué hace
Guardar información de recuperación de BitLocker en AD DS para unidades de sistema operativo	Marcada	Copia la clave en la cuenta del equipo
Configurar almacenamiento de la información de recuperación de BitLocker en AD DS:	Almacenar contraseñas de recuperación y paquetes de claves	Guarda también el paquete de claves, que sirve para recuperar datos de un disco dañado
No habilitar BitLocker hasta que la información de recuperación se almacene en AD DS para unidades de sistema operativo	Marcada	No deja cifrar si la copia falla
Omitir opciones de recuperación en el asistente para la configuración de BitLocker	A criterio	Impide que el usuario elija dónde guardar la clave

Ojo con la directiva de la raíz que se llama Almacenar información de recuperación de BitLocker en los Servicios de dominio de Active Directory (Windows Server 2008 y Windows Vista). Su nombre parece el indicado, pero es de Windows Vista. Lo mismo pasa con Elegir cómo pueden los usuarios recuperar unidades protegidas por BitLocker (Windows Server 2008 y Windows Vista). En equipos actuales se configuran las de las carpetas de cada tipo de unidad.

Comprobar que el equipo recibió la directiva

La directiva de grupo deja sus valores en el registro, en HKLM\SOFTWARE\Policies\Microsoft\FVE, con los nombres que trae la plantilla. Esta orden los lee y no necesita permisos de administrador:

$clave = 'HKLM:\SOFTWARE\Policies\Microsoft\FVE'
if (Test-Path $clave) {
    Get-ItemProperty $clave | Select-Object OSRecovery, OSActiveDirectoryBackup, OSActiveDirectoryInfoToStore, OSRequireActiveDirectoryBackup
} else {
    'Este equipo no tiene directivas de BitLocker'
}

En un equipo con la directiva recomendada debería verse OSRecovery, OSActiveDirectoryBackup y OSRequireActiveDirectoryBackup en 1, y OSActiveDirectoryInfoToStore en 1, que es «contraseñas de recuperación y paquetes de claves» (2 es «solo contraseñas»). En el portátil de nuestras pruebas, que no está en ningún dominio, la orden respondió Este equipo no tiene directivas de BitLocker, en las dos versiones de PowerShell.

Activar BitLocker por GPO: lo que la directiva no hace

La expresión «activar BitLocker por GPO» se presta a confusión. La directiva de recuperación no cifra nada: dice dónde guardar la clave y si se permite cifrar sin guardarla. Y deja dos huecos que las preguntas frecuentes reconocen:

• No es retroactiva. Si un disco se cifró antes de que el equipo recibiera la directiva, por ejemplo antes de unirlo al dominio, su clave no se copia sola cuando la directiva llega. Microsoft recomienda unir el equipo al dominio como primer paso.
• No reintenta. Si la copia falla, por ejemplo porque no había conexión con un controlador de dominio, BitLocker no vuelve a intentarlo. Solo la casilla No habilitar BitLocker hasta que la información de recuperación se almacene en AD DS para unidades de sistema operativo evita el problema, porque sin copia no hay cifrado.

Para los equipos ya cifrados queda copiar la clave a mano, que es el escenario 3.

Ver la clave con BitLocker Recovery Password Viewer

La herramienta de Microsoft para ver las claves guardadas en el dominio es BitLocker Recovery Password Viewer, una extensión de Usuarios y equipos de Active Directory que viene con las herramientas de administración remota del servidor (RSAT). En Windows 11 se instala como característica opcional, con una consola de administrador:

Add-WindowsCapability -Online -Name 'Rsat.BitLocker.Recovery.Tools~~~~0.0.1.0'

El nombre de la capacidad sale de la lista de características a petición de Microsoft, donde figura como «BitLocker Drive Encryption Administration Utilities». Con la herramienta instalada, según la guía del proceso de recuperación, hay dos formas de buscar una clave:

• En las propiedades de la cuenta del equipo aparece una pestaña con sus claves de recuperación de BitLocker.
• Con el botón derecho sobre el dominio, la opción de buscar una contraseña de recuperación de BitLocker (en inglés, Find BitLocker Recovery Password) la encuentra por los primeros ocho caracteres del identificador que muestra la pantalla de recuperación.

Dos reglas de Active Directory que hay que tener presentes. De fábrica, solo los administradores del dominio pueden leer las claves, y el acceso se puede delegar al grupo de la mesa de ayuda. Y Active Directory no borra las claves viejas: cada vez que un disco cambia de clave queda un objeto nuevo junto a los anteriores, y para saber cuál es la vigente hay que mirar la fecha. Solo se borran todas juntas cuando se borra la cuenta del equipo.

Ver la clave de BitLocker en Active Directory con PowerShell

Sin la herramienta gráfica, el módulo de Active Directory lee los mismos objetos, de la clase msFVE-RecoveryInformation. Este bloque muestra las claves de un equipo, de la más reciente a la más antigua, con una cuenta que tenga permiso para leerlas:

$equipo = Get-ADComputer -Identity 'PC-CONTABILIDAD'
Get-ADObject -Filter "objectClass -eq 'msFVE-RecoveryInformation'" -SearchBase $equipo.DistinguishedName -Properties whenCreated, msFVE-RecoveryPassword |
    Sort-Object whenCreated -Descending |
    Select-Object whenCreated, Name, msFVE-RecoveryPassword

Según la guía de recuperación, el nombre de cada objeto mide 63 caracteres y une la fecha y la hora de creación con el identificador de la clave, el mismo que muestra la pantalla de recuperación. Si la orden no devuelve nada, hay dos explicaciones posibles: el equipo nunca copió su clave o la cuenta con la que se ejecuta no tiene permiso para leerla.

Revisar todo el parque: qué equipos no tienen su clave guardada

Configurar bien desde hoy no arregla los equipos que se cifraron antes. La revisión que más vale la pena es una lista de todos los equipos con el número de claves guardadas de cada uno: los que tienen cero son los que, el día que pidan la clave, no van a tenerla. Estos cuatro escenarios cubren el dominio, la nube, el equipo suelto y la retirada de un portátil.

Escenario 1: equipos del dominio sin clave en Active Directory

Con el módulo de Active Directory y una cuenta con permiso para leer la información de recuperación, este bloque recorre una unidad organizativa, cuenta las claves de cada equipo y guarda el resultado en un CSV para Excel en el escritorio:

$base = 'OU=Equipos,DC=empresa,DC=com,DC=co'
$informe = foreach ($pc in Get-ADComputer -Filter 'Enabled -eq $true' -SearchBase $base -Properties OperatingSystem) {
    $claves = @(Get-ADObject -Filter "objectClass -eq 'msFVE-RecoveryInformation'" -SearchBase $pc.DistinguishedName -Properties whenCreated)
    [pscustomobject]@{
        Equipo  = $pc.Name
        Sistema = $pc.OperatingSystem
        Claves  = $claves.Count
        Ultima  = ($claves | Sort-Object whenCreated | Select-Object -Last 1).whenCreated
    }
}
$cod = if ($PSVersionTable.PSVersion.Major -ge 7) { 'utf8BOM' } else { 'UTF8' }
$informe | Sort-Object Claves | Export-Csv -Path (Join-Path ([Environment]::GetFolderPath('Desktop')) 'claves-ad.csv') -NoTypeInformation -Encoding $cod -Delimiter ';'

Las filas con Claves en 0 van primero. El punto y coma es el separador que espera Excel con la configuración regional de Colombia, y la codificación cambia según la versión porque PowerShell 7 escribe UTF-8 sin la marca que Excel necesita para leer bien las tildes. El informe no lleva las claves a propósito: un archivo con claves de recuperación en un escritorio es un riesgo mayor que el que resuelve.

Un 0 no siempre significa que falta la clave: también sale si la cuenta que ejecuta el bloque no tiene permiso para ver esos objetos. Por eso conviene ejecutarlo con la misma cuenta que usa la mesa de ayuda para recuperar claves.

Escenario 2: equipos de Intune y Entra ID sin clave de BitLocker

En la nube, la lista sale de Microsoft Graph. El permiso BitlockerKey.ReadBasic.All da los datos de cada clave sin la clave misma, que es justo lo que hace falta para contar, y la cuenta que se conecta necesita además uno de los roles de la tabla de arriba. El bloque usa los módulos Microsoft.Graph.Identity.SignIns y Microsoft.Graph.Identity.DirectoryManagement:

Connect-MgGraph -Scopes 'BitlockerKey.ReadBasic.All', 'Device.Read.All' -NoWelcome
$claves = @(Get-MgInformationProtectionBitlockerRecoveryKey -All)
$porEquipo = $claves | Group-Object DeviceId -AsHashTable -AsString
$informe = foreach ($d in Get-MgDevice -All | Where-Object OperatingSystem -eq 'Windows') {
    $suyas = @(if ($porEquipo -and $porEquipo.ContainsKey($d.DeviceId)) { $porEquipo[$d.DeviceId] })
    [pscustomobject]@{
        Equipo = $d.DisplayName
        Union  = $d.TrustType
        Claves = $suyas.Count
        Ultima = ($suyas | Sort-Object CreatedDateTime | Select-Object -Last 1).CreatedDateTime
    }
}
$cod = if ($PSVersionTable.PSVersion.Major -ge 7) { 'utf8BOM' } else { 'UTF8' }
$informe | Sort-Object Claves | Export-Csv -Path (Join-Path ([Environment]::GetFolderPath('Desktop')) 'claves-entra.csv') -NoTypeInformation -Encoding $cod -Delimiter ';'

La columna Union dice cómo está cada equipo, con los valores de Microsoft Graph: AzureAd es unido a Microsoft Entra ID, ServerAd es híbrido y Workplace es solo registrado. Un Workplace con 0 claves no es un fallo de la directiva, es la cuarta fila de la tabla del principio: ese equipo nunca se unió.

Dos detalles de la referencia de Graph: la lista de claves no admite $top, así que no hay que usar -Top con este cmdlet, y la clave solo viaja si se pide la propiedad key, lo que deja una entrada en el registro de auditoría. Para ver la clave de BitLocker en Entra ID de un equipo concreto está la ficha del equipo en Intune o en el centro de Microsoft Entra, que también deja auditoría.

Escenario 3: copiar la clave de un equipo que ya está cifrado

Para los equipos con 0 claves en cualquiera de los dos informes, la guía de operaciones de BitLocker da los cmdlets que copian la clave desde el propio equipo. En una consola de administrador:

$protectores = (Get-BitLockerVolume -MountPoint C:).KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword'
foreach ($p in $protectores) {
    BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $p.KeyProtectorId
}

En un equipo del dominio, la orden del bucle es Backup-BitLockerKeyProtector, con los mismos parámetros. Y con la consola clásica, manage-bde -protectors -aadbackup C: -id seguido del identificador entre llaves para Microsoft Entra ID, o -adbackup para Active Directory. Si el disco no tiene ninguna contraseña de recuperación, primero hay que añadirla, como explica la guía de BitLocker con PowerShell.

En muchos equipos a la vez, el mismo bloque se puede ejecutar con PowerShell remoto o distribuirse como script: desde Intune, si los equipos usan BitLocker con Intune, o desde la directiva de grupo. Después, los eventos del apartado siguiente confirman la copia en el equipo, y el informe del escenario 1 o del 2, en el directorio.

Escenario 4: retirar o reasignar un portátil sin perder la clave

Aquí está la trampa más cara, porque las tres consolas borran la clave de formas distintas:

Si borra el equipo en	Lo que pasa, según Microsoft
Intune, un equipo unido a Microsoft Entra ID	La sincronización quita los protectores del disco del sistema y deja BitLocker suspendido
Microsoft Entra ID	Se borran sus claves de BitLocker, y no se puede deshacer
Active Directory	Se borran sus objetos de recuperación, que viven dentro de la cuenta del equipo

El orden seguro es el inverso al habitual. Primero se decide si el disco se va a borrar: si el equipo se restablece o se reinstala, la clave vieja ya no hace falta. Si el disco va a conservarse, por ejemplo para guardar la información de quien se fue, primero se copia la clave en un sitio seguro y luego se borra el equipo de las consolas. La página de administración de dispositivos de Microsoft Entra recomienda además retirar o borrar el equipo en Intune antes de eliminarlo del directorio, para que BitLocker no quede suspendido en un disco que sigue en uso.

Con Windows Autopilot hay un caso más: cuando un equipo pasa a otra persona, Microsoft advierte que el nuevo propietario no ve las claves anteriores y tiene que pedírselas a un administrador.

Los eventos que dicen si la copia funcionó

Cada copia deja un evento en el propio equipo, en Visor de eventos, en el registro de administración de BitLocker (Microsoft-Windows-BitLocker/BitLocker Management). Los textos son los del proveedor de eventos Microsoft-Windows-BitLocker-API, que trae dos versiones de cada mensaje de copia en Active Directory. En nuestro Windows 11 con la interfaz en español salieron en inglés:

Evento	Qué dice
513 y 784	La copia de la información de recuperación en Active Directory funcionó
514 y 785	La copia en Active Directory falló
845	La copia en Microsoft Entra ID funcionó
846	La copia en Microsoft Entra ID falló
852	Failed to enable Silent Encryption. Device is not Entra ID joined.

Para leerlos sin abrir el visor:

Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-BitLocker/BitLocker Management'; Id = 513, 514, 784, 785, 845, 846, 852 } -MaxEvents 20 |
    Select-Object TimeCreated, Id, Message

En el portátil de las pruebas, sin permisos de administrador, la orden leyó el registro y respondió No se encontraron eventos que coincidan con los criterios de selección especificados., lo esperable en un equipo que no está unido a nada. Un evento de éxito tampoco es la prueba final: las preguntas frecuentes de Microsoft advierten que la clave puede haberse borrado después del directorio, o el protector del disco, y que lo único que confirma una copia válida es buscarla en el directorio.

Lo que la documentación de Microsoft no deja claro

Al cruzar las páginas oficiales aparecieron estas diferencias. Ninguna impide configurar bien, pero conviene conocerlas antes de citar una página en una discusión:

Tema	Lo que dice una página	Lo que dice otra
Rotación de la clave, valor de fábrica	La guía de configuración y el texto del CSP de BitLocker: encendida en los equipos unidos a Microsoft Entra ID	La tabla del mismo CSP: valor 0, apagada
Arranque seguro para el cifrado silencioso	La guía de cifrado con Intune: obligatorio	La guía de solución de problemas de Intune: no es obligatorio, y con TPM 1.2 tampoco hace falta UEFI
Roles que leen las claves	La guía de Intune: tres	La de dispositivos de Entra: cinco; la referencia de roles: siete
Rol de Intune para rotar claves	La guía de cifrado: «Endpoint Security Administrator»	La referencia de roles y la de la acción: Endpoint Security Manager
Portal de autoservicio	La guía de Intune: account.microsoft.com	La guía de recuperación: myaccount.microsoft.com
Dónde está el informe	La guía de cifrado: Devices, Monitor, Encryption report	La del informe: Devices, Manage devices, Configuration, pestaña Monitor
Nombre del servicio en el equipo	La ayuda de manage-bde: «Azure Active Directory»	Los eventos de Windows: «Entra ID»

El ejemplo de Microsoft Graph que no funciona tal cual

Hay una diferencia más, que afecta a quien copie el ejemplo. La guía de recuperación publica una función para leer las claves de un equipo con Microsoft Graph que, para buscar el equipo por su nombre, usa Get-MgDevice. Sin embargo, el ejemplo solo instala el módulo Microsoft.Graph.Identity.SignIns y solo se conecta con el permiso BitlockerKey.Read.All. En el módulo de este equipo, Get-MgDevice pertenece a Microsoft.Graph.Identity.DirectoryManagement, y Find-MgGraphCommand dice que pide Device.Read.All. Por eso el bloque del escenario 2 pide los dos permisos y usa los dos módulos.

Errores comunes y qué significan

Mensaje o síntoma	Causa	Qué hacer
No BitLocker key found for this device en Intune	La clave no está en Microsoft Entra ID	Escenario 3 en ese equipo
«Recovery key backup failed» en el informe de cifrado	La copia de la clave falló	Revisar los eventos de fallo del apartado anterior y copiarla con el escenario 3
Failed to enable Silent Encryption. Device is not Entra ID joined.	El equipo está solo registrado, no unido	Unirlo a Microsoft Entra ID antes de exigir el cifrado
El cifrado silencioso falla con un conflicto de directivas	Alguna directiva o línea base permite o exige PIN o llave de inicio	Dejar el PIN y la llave de inicio en «no permitir»
Failed to enable Silent Encryption. TPM is not available.	Sin TPM o con el TPM desactivado en el firmware	Activarlo en la configuración del firmware
El cifrado silencioso falla en un equipo con muchas claves guardadas	Microsoft Entra ID admite hasta 200 claves por equipo y, al llegar, la copia previa al cifrado falla	Contar las claves del equipo con el escenario 2
Get-ADObject no devuelve ninguna clave	El equipo no copió su clave o la cuenta no puede leerla	Probar con una cuenta de la mesa de ayuda y, si sigue en 0, escenario 3
La clave del dominio que aparece no abre el disco	Hay varias claves guardadas y se probó una antigua	Usar la de fecha más reciente o buscar por el identificador de la pantalla

Lo que no probamos

No configuramos Intune ni Microsoft Entra ID de ninguna organización, no unimos el equipo a un dominio y no ciframos nada. Todo lo que ocurre en esas consolas sale de la documentación de Microsoft, con sus contradicciones a la vista. Sí se midió en el equipo lo que se puede medir sin tocar su cifrado: los nombres de las directivas en la plantilla en español, sus valores de registro, el estado de unión, los textos de los eventos y la ayuda de manage-bde. Las órdenes se validaron contra los módulos instalados y contra la referencia oficial del módulo de Active Directory, y los bloques de los escenarios 1 y 2 se ejecutaron con datos simulados en las dos versiones de PowerShell.

Recomendaciones

1. Decida dónde queda la clave antes de cifrar el primer equipo, y marque siempre la opción que impide cifrar sin copiarla.
2. Una los equipos de verdad. Un portátil con la cuenta de trabajo agregada no es un equipo unido y no copia su clave a la nube.
3. Revise los equipos ya cifrados: la directiva no copia claves de discos cifrados antes de llegar.
4. Haga el inventario de claves una vez al trimestre con el escenario 1 o el 2, y copie las que falten con el 3.
5. Revise quién puede leer las claves, incluidos los roles de lector.
6. Decida sobre el autoservicio en lugar de dejar el valor de fábrica sin pensarlo.
7. Active la rotación de la clave en los equipos unidos a Microsoft Entra ID, para que una clave dictada por teléfono deje de servir.
8. Antes de borrar un equipo de cualquier consola, decida qué pasa con su disco.
9. No guarde claves en hojas de cálculo ni en correos. Los informes de esta guía cuentan claves, no las copian.

Cuando BitLocker es parte de la gestión de los equipos

BitLocker con Intune o con Active Directory protege los datos de cada portátil, pero solo si alguien lleva el control de las claves, revisa el inventario y sabe qué hacer el día que un equipo cambia de manos. Es un trabajo de rutina, no de una vez.

En KHARONTE lo hacemos dentro del soporte técnico para empresas: administramos los puestos de trabajo y su configuración, y nuestra mesa de ayuda TI atiende la pantalla de recuperación cuando aparece. La administración de Microsoft 365, del directorio y de las consolas de los equipos está en nuestra gestión de plataformas. Si busca servicios administrados de TI para que todo esto quede al día, revise nuestros servicios de TI para empresas. Y si su empresa tiene un dominio, la guía de Active Directory explica cómo se organiza.