Fase de migración 5: Tareas posteriores a la migración

  • Artículo

Use la siguiente información para la fase 5 de la migración de AD RMS a Azure Information Protection. Estos procedimientos abarcan los pasos del 10 al 12 de la Migración de AD RMS a Azure Information Protection.

Paso 10: Desaprovisionamiento de AD RMS

Quite el punto de conexión de servicio (SCP) de Active Directory para evitar que los equipos detecten la infraestructura de Rights Management local. Este paso es opcional para los clientes existentes que migró debido a la redirección que configuró en el Registro (por ejemplo, ejecutando el script de migración). Sin embargo, quitar el SCP impide que los nuevos clientes y potencialmente los servicios y herramientas relacionados con RMS encuentren el SCP cuando se complete la migración. En este momento, todas las conexiones de equipo deben ir al servicio Azure Rights Management.

Para quitar el SCP, asegúrese de que ha iniciado sesión como administrador de empresa de dominio y, a continuación, use el procedimiento siguiente:

  1. En la consola de Active Directory Rights Management Services, haga clic con el botón derecho en el clúster de AD RMS y, a continuación, haga clic en Propiedades.

  2. Haga clic en la pestaña SCP.

  3. Seleccione la casilla Cambiar SCP.

  4. Seleccione Quitar SCP actual y, a continuación, haga clic en Aceptar.

Ahora supervise los servidores de AD RMS para la actividad. Por ejemplo, compruebe las solicitudes del informe de estado del sistema, la tabla ServiceRequest o audite el acceso de los usuarios al contenido protegido.

Cuando haya confirmado que los clientes de RMS ya no se comunican con estos servidores y que los clientes usan correctamente Azure Information Protection, puede quitar el rol de servidor de AD RMS de estos servidores. Si usa servidores dedicados, es posible que prefiera el paso más conservador de apagar primero los servidores durante un período de tiempo. Esto le proporciona tiempo para asegurarse de que no hay problemas notificados que podrían requerir que reinicie estos servidores para la continuidad del servicio mientras investiga por qué los clientes no usan Azure Information Protection.

Después de desaprovisionar los servidores de AD RMS, es posible que quiera aprovechar la oportunidad de revisar la plantilla y las etiquetas. Por ejemplo, convertir plantillas en etiquetas, consolidar las plantillas para que los usuarios tengan menos de las que elegir o volver a configurarlas. Este también sería un buen momento para publicar plantillas predeterminadas.

Para las etiquetas de confidencialidad y el cliente de etiquetado unificado, use el portal de cumplimiento Microsoft Purview. Para más información, consulte la documentación de Microsoft 365.

Importante

Al final de esta migración, el clúster de AD RMS no se puede usar con Azure Information Protection y la opción mantener su propia clave (HYOK).

Configuración adicional para equipos que ejecutan Office 2010

Importante

El soporte extendido de Office 2010 finalizó el 13 de octubre de 2020. Para más información, consulte AIP y versiones heredadas de Windows y Office.

Si los clientes migrados ejecutan Office 2010, los usuarios pueden experimentar retrasos en la apertura de contenido protegido después de que nuestros servidores de AD RMS se desaprovisionen. O bien, es posible que los usuarios vean mensajes que no tienen credenciales para abrir contenido protegido. Para resolver estos problemas, cree una redirección de red para estos equipos, lo cual redirige el FQDN de la dirección URL de AD RMS a la dirección IP local del equipo (127.0.0.1). Para ello, puede configurar el archivo hosts local en cada equipo o mediante DNS.

  • Redireccionamiento a través del archivo hosts local: agregue la siguiente línea en el archivo hosts local, sustituyendo <AD RMS URL FQDN> por el valor del clúster de AD RMS, sin prefijos ni páginas web:

    127.0.0.1 <AD RMS URL FQDN>

  • Redireccionamiento a través de DNS: cree un registro de host (A) para el FQDN de dirección URL de AD RMS, que tiene la dirección IP 127.0.0.1.

Paso 11: Finalización de las tareas de migración de cliente

Para clientes de dispositivos móviles y equipos Mac: quite los registros SRV de DNS que creó al implementar la extensión de dispositivo móvil de AD RMS.

Cuando se hayan propagado estos cambios de DNS, estos clientes detectarán y empezarán a usar automáticamente el servicio Azure Rights Management. Sin embargo, los equipos Mac que ejecutan Office para Mac almacenan en caché la información de AD RMS. En estos equipos, este proceso puede tardar hasta 30 días.

Para forzar que los equipos Mac ejecuten el proceso de detección inmediatamente, en la cadena de claves, busque "adal" y elimine todas las entradas de ADAL. Posteriormente, ejecute los comandos siguientes en estos equipos:


rm -r ~/Library/Cache/MSRightsManagement

rm -r ~/Library/Caches/com.microsoft.RMS-XPCService

rm -r ~/Library/Caches/Microsoft\ Rights\ Management\ Services

rm -r ~/Library/Containers/com.microsoft.RMS-XPCService

rm -r ~/Library/Containers/com.microsoft.RMSTestApp

rm ~/Library/Group\ Containers/UBF8T346G9.Office/DRM.plist

killall cfprefsd

Cuando todos los equipos Windows existentes se han migrado a Azure Information Protection, no hay ninguna razón para seguir usando controles de incorporación y mantener el grupo AIPMigrated que creó para el proceso de migración.

Quite primero los controles de incorporación y, a continuación, puede eliminar el grupo AIPMigrated y cualquier método de implementación de software que haya creado para implementar los scripts de migración.

Para quitar los controles de incorporación:

  1. En una sesión de PowerShell, conéctese al servicio Azure Rights Management y, cuando se le solicite, especifique las credenciales de administrador global:

    Connect-AipService

  2. Ejecute el comando siguiente e introduzca Y para confirmar.

    Set-AipServiceOnboardingControlPolicy -UseRmsUserLicense $False

    Tenga en cuenta que este comando quita cualquier aplicación de licencia para el servicio de protección de Azure Rights Management, de modo que todos los equipos puedan proteger documentos y correos electrónicos.

  3. Confirme que los controles de incorporación ya no están establecidos:

    Get-AipServiceOnboardingControlPolicy

    En la salida, Licencia debe mostrar el valor False y no se muestra ningún GUID para SecurityGroupOjbectId.

Por último, si usa Office 2010 y ha habilitado la tarea de Administración de plantillas de directiva de derechos de AD RMS (Automatizado) en la biblioteca del programador de tareas de Windows, deshabilite esta tarea porque no la usa el cliente de Azure Information Protection.

Esta tarea se habilita normalmente mediante la directiva de grupo y admite una implementación de AD RMS. Puede encontrar esta tarea en la siguiente ubicación: Microsoft>Windows>Active Directory Rights Management Services Client.

Importante

El soporte extendido de Office 2010 finalizó el 13 de octubre de 2020. Para más información, consulte AIP y versiones heredadas de Windows y Office.

Paso 12: Volver a especificar la clave de inquilino de Azure Information Protection

Este paso es necesario cuando se completa la migración si la implementación de AD RMS usaba el modo criptográfico RMS 1 porque este modo usa una clave de 1024 bits y SHA-1. Esta configuración se considera que ofrece un nivel de protección inadecuado. Microsoft no aprueba el uso de longitudes de clave inferiores, como claves RSA de 1024 bits, y el uso asociado de protocolos que ofrecen niveles de protección inadecuados, como SHA-1.

Volver a establecer la clave da como resultado la protección que usa el modo criptográfico RMS 2, lo cual da como resultado una clave de 2048 bits y SHA-256.

Incluso si la implementación de AD RMS usaba el modo criptográfico 2, se recomienda seguir este paso porque una nueva clave ayuda a proteger el inquilino frente a posibles infracciones de seguridad a la clave de AD RMS.

Al volver a establecer la clave de inquilino de Azure Information Protection (un proceso también conocido como "implementar gradualmente la clave"), la clave actualmente activa se archiva y Azure Information Protection comienza a usar una clave diferente que especifique. Esta clave diferente podría ser una clave nueva que cree en Azure Key Vault o la clave predeterminada que se creó automáticamente para el inquilino.

Pasar de una clave a otra no es un proceso que sucede inmediatamente, sino durante unas pocas semanas. Dado que no es inmediato, no espere hasta que sospeche una infracción de la clave original, pero realice este paso tan pronto como se complete la migración.

Para volver a especificar la clave de inquilino de Azure Information Protection:

  • Si Microsoft administra la clave de inquilino: ejecute el cmdlet de PowerShell Set-AipServiceKeyProperties y especifique el identificador de clave de la clave que se creó automáticamente para el inquilino. Para identificar el valor que se va a especificar, ejecute el cmdlet Get-AipServiceKeys. La clave que se creó automáticamente para el inquilino tiene la fecha de creación más antigua, por lo que puede identificarla mediante el comando siguiente:

    (Get-AipServiceKeys) | Sort-Object CreationTime | Select-Object -First 1

  • Si la clave de inquilino la administra personalmente (BYOK): en Azure Key Vault, repita el proceso de creación de claves para el inquilino de Azure Information Protection y, a continuación, vuelva a ejecutar el cmdlet Use-AipServiceKeyVaultKey para especificar el URI de esta nueva clave.

Para más información acerca de cómo administrar la clave de inquilino de Azure Information Protection, consulte Operaciones para la clave de inquilino de Azure Information Protection.

Pasos siguientes

Ahora que ha completado la migración, revise la hoja de ruta de implementación de AIP para la clasificación, el etiquetado y la protección para identificar cualquier otra tarea de implementación que necesite realizar.