Exchange ya migra buzones a Microsoft 365 con OAuth, sin contraseñas de administrador

Durante años, mover buzones entre un Exchange local y Microsoft 365 tuvo un precio incómodo: dejarle a la nube el usuario y la contraseña de una cuenta privilegiada de Active Directory. El 9 de noviembre de 2026, el equipo de Exchange anunció que el Mailbox Replication Service (MRS) de Microsoft 365 ya acepta OAuth para esas migraciones, en organizaciones híbridas y no híbridas. Para quien todavía opera correo en servidores propios y está a medio camino hacia la nube, es la diferencia entre entregar una llave maestra y entregar un pase con permisos acotados. No viene gratis: la configuración toca Entra ID, DNS, certificados y PowerShell en los dos lados.

Qué anunció Microsoft

Según el anuncio, MRS no permitía autenticarse con OAuth al migrar buzones entre Microsoft 365 y Exchange local; solo con autenticación Basic, es decir, las credenciales de un usuario privilegiado del AD local. Ahora el administrador del tenant puede crear un endpoint de migración OAuth y usarlo en lotes de migración o en movimientos de onboarding (de local a la nube) y offboarding (de la nube de regreso a local).

Microsoft insiste en que es una alternativa, no un reemplazo: "No action is required", dice el anuncio, y los endpoints existentes y las migraciones en curso no se ven afectados. Basic sigue funcionando para esto.

Quién puede usarlo

Las condiciones son estrechas:

Requisito	Detalle según Microsoft
Nube	Solo Microsoft 365 multi-tenant (WW). Para otras nubes, Microsoft promete noticias "en los próximos meses"
Exchange local	Exchange Server Subscription Edition (SE) de octubre de 2026 o más nuevo
Alternativa	Exchange Server 2019 CU15 con la actualización de seguridad ESU de octubre de 2026
Balanceador	Solo con Exchange SE: afinidad de sesión por cookie (capa 7)

El detalle de Exchange 2019 tiene trampa. Exchange 2016 y 2019 salieron de soporte el 14 de octubre de 2025, y lo que siguió fue un programa pagado de actualizaciones extendidas (ESU). Microsoft creó un segundo periodo de ESU que terminó a finales de octubre de 2026, avisó que no habría más extensiones y, en una actualización del 13 de octubre, dijo que ya había liberado el último paquete de ese programa. Traducido: si tu servidor 2019 no está en el ESU, no tiene esa actualización y no entra. Mi lectura es que, en la práctica, esto está pensado para quien ya está en SE o para quien pagó para alargarle la vida a 2019 mientras termina de migrar.

Cómo funciona por dentro

Diagrama del flujo de autenticación OAuth entre el MRS de Microsoft 365, Microsoft Entra ID y el MRSProxy de Exchange local, comparado con la autenticación Basic

La guía de Microsoft Learn aclara algo que se presta a confusión: esto no es Hybrid Modern Authentication, la que se usa para que los usuarios se autentiquen. Es un modelo aparte, basado en una identidad de aplicación, con tres propiedades que Microsoft destaca:

una identidad bien definida que representa a MRS;
separación entre la autorización de migraciones y el resto de las cargas híbridas de Exchange;
autorización específica por tenant usando el Object ID del service principal, no un ID de aplicación compartido.

El flujo tiene tres piezas. En Entra ID registras una aplicación de un solo tenant que representa a tu MRSProxy local. MRS, desde Microsoft 365, pide un token para esa aplicación. Y tu Exchange local valida ese token en dos capas: primero el front-end (CAFE) y después el propio MRS, que revisa una lista de entradas autorizadas.

Lo que hay que configurar

Resumen de la guía oficial, para que dimensiones el trabajo. No lo probé; todo sale de la documentación de Microsoft.

En Microsoft Entra ID:

Registra una aplicación de un solo tenant y ponle un Application ID URI todo en minúsculas. Microsoft recomienda el formato https://<client-id>.tudominio.com/ews/mrsproxy.svc, aunque puedes reusar el URI de tu endpoint actual. Si usas el client ID en el nombre, tendrás que crear el registro DNS y cubrirlo en tu certificado público.
Quita los permisos de Microsoft Graph que trae por defecto y crea un app role con tipo de miembro Applications.
Agrega a los access tokens los claims opcionales idtyp y xms_aud_guid (el segundo, editando el manifiesto).
Con el módulo de Microsoft Graph PowerShell, registra en tu tenant el service principal del Mailbox Replication Service y asígnale ese app role.

En Exchange local (en un servidor con la versión más reciente), todo con New-SettingOverride:

habilita OAuth en el MRSProxy con la cadena AuthorizedEntries en formato TenantID|ObjectID|Audience|Role. El Audience distingue mayúsculas y debe ser único;
agrega el client ID de tu aplicación a la validación del GUID de audiencia (AudGuidValidation), sin borrar los valores que ya existan;
activa la autorización OAuth para MRS en los servidores front-end.

En Exchange Online: creas el endpoint con New-MigrationEndpoint -UseOAuth -ExchangeRemoteMove y un -RemoteServer que coincida con el host del Application ID URI. Después lo pruebas con Test-MigrationServerAvailability.

Las trampas que vale la pena leer dos veces

La prueba no prueba tanto. Según la propia salida que muestra Microsoft, Test-MigrationServerAvailability solo valida que se pueda obtener el token; "no intenta conectarse al host remoto". Un Success ahí no garantiza que tu MRSProxy acepte el token.
Mayúsculas y minúsculas. El URI va en minúsculas, y el Audience y el Role distinguen mayúsculas. Es la receta perfecta para una tarde de "todo está bien configurado y no jala".
Set-SettingOverride sobrescribe. Si modificas un override, reemplaza los parámetros anteriores, así que hay que volver a ponerlos todos.
Logs separados. CAFE escribe en Logging\HttpProxy\Ews y MRS en Logging\MrsProxyAuthorization. Microsoft recomienda activar el log de OAuth de MRS durante las primeras migraciones.
Move requests. Al crear un New-MoveRequest hay que indicar -RemoteHostName igual al host del URI y -ArchiveDomain para que el cmdlet elija bien su juego de parámetros.

Lo que todavía no se sabe

El anuncio no da fechas para las nubes soberanas o gubernamentales. En los comentarios del blog, un administrador preguntó si se puede limitar la aplicación a ciertos usuarios, por ejemplo con un grupo de seguridad, como en las migraciones entre tenants. La guía publicada no describe ese tipo de alcance, y al momento de escribir esto la pregunta no tenía respuesta.

Mi lectura

Es un cambio pequeño en el anuncio y grande en el modelo de riesgo. Una migración híbrida puede durar meses, y durante todo ese tiempo una contraseña con privilegios en tu AD vive en la configuración de un servicio en la nube. Cambiarla por un token de aplicación, autorizado por tenant y validado en dos capas, reduce lo que se pierde si algo se filtra.

Si tu migración va a terminar la semana que entra, quizá no valga la pena: la configuración es larga y Basic sigue funcionando. Si apenas empiezas o tienes lotes para rato, vale la pena. Y si sigues en Exchange 2019 sin ESU, el mensaje real de Microsoft no es este: es que te quedaste sin parches y te toca moverte a SE o a la nube.