Cambio a la aplicación administrada de RealmJoin

Sustituye el registro de la aplicación RealmJoin Runbook Management por Tenant y su secreto de cliente por la aplicación administrada multi-Tenant de RealmJoin, usando el módulo de PowerShell de RealmJoin.

Resumen

Los tenants que conectaron Azure Automation antes de la incorporación basada en PowerShell usan un RealmJoin Runbook Management registro de aplicación en su propio tenant. RealmJoin se autentica contra tu Automation Account con el ID de cliente y el secreto de cliente de esa aplicación.

Los tenants incorporados recientemente ya no hacen esto: RealmJoin usa su propio aplicación multitenant, a la que se le concede Contributor en tu Automation Account y nada más. Puedes cambiar una configuración existente con el módulo de RealmJoin para PowerShell.

No hay una fecha límite aquí. A diferencia de la migración de Log Analytics, Microsoft no retira nada — la ruta heredada sigue funcionando. Cambia cuando te convenga.

Por qué cambiar

• No hay ningún secreto de cliente que rotar. El secreto por tenant expira y debe renovarse; cuando expira, la sincronización y la ejecución de runbooks se detienen hasta que alguien se da cuenta. La aplicación administrada no tiene ningún secreto por tu parte.
• No hay ningún registro de aplicación que mantener en tu tenant.
• Ámbito más reducido. Al service principal heredado normalmente se le asignaba Contributor en todo el grupo de recursos. A la aplicación administrada solo se le concede Contributor en la Automation Account.
• Tu Automation Account, su identidad administrada, sus permisos y tus runbooks permanecen exactamente igual.

Qué cambia al hacer el cambio

El mismo Set-RJAutomationAccount comando que para una nueva configuración se usa, apuntando a tu existente Automation Account. Este:

• crea el RealmJoin Azure Resources service principal en tu tenant, si aún no existe
• le concede Colaborador en esa Automation Account
• vuelve a establecer los permisos de aplicación de la identidad administrada — Microsoft Graph, Exchange Online, Defender y SharePoint — para el conjunto que incluye el módulo
• indica a RealmJoin que se autentique con la aplicación administrada a partir de ahora

Tu Automation Account conserva su nombre, su identidad administrada y su ID de objeto, por lo que los roles de Entra ID y cualquier permiso que le hayas asignado siguen siendo válidos. Los runbooks no se reimportan desde cero.

El registro restablece la rama del repositorio compartido de runbooks a producción. Si tu tenant sigue deliberadamente otra rama, configúrala de nuevo después en el Portal, en Settings → Runbooks.

Requisitos previos

Lo mismo que para una nueva configuración — consulta Requisitos previos en la página de incorporación. En resumen:

• Acceso al área Settings en el RealmJoin Portal, para obtener el comando y su token
• PowerShell 5.1 o posterior, en una sesión local recién abierta — devolvería Azure Cloud Shell
• Una cuenta que pueda crear entidades de servicio y conceder permisos de aplicación en Entra ID (Administrador global o Privileged Role Administrator) y que pueda crear asignaciones de roles en la suscripción (Propietario, o Colaborador además de Administrador de acceso de usuario)

Migración

1

Copie el comando del RealmJoin Portal

En el RealmJoin Portal, vaya a Configuración → Runbooks (https://portal.realmjoin.com/settings/runbooks-configuration).

La página muestra el aviso "Cambiar a la aplicación administrada de RealmJoin" junto con un bloque de comandos listo para copiar. Use el Copiar botón para copiarlo.

El comando se rellena previamente con tu grupo de recursos actual, el nombre de la Automation Account y la suscripción:

$latest = [version](Find-Module RealmJoin -Repository PSGallery -ErrorAction Stop).Version
if (-not (Get-Module -ListAvailable RealmJoin | Where-Object Version -ge $latest)) {
    Install-Module RealmJoin -Force -AllowClobber -ErrorAction Stop
}
Import-Module RealmJoin -Force
Set-RJAutomationAccount -ResourceGroupName "<ResourceGroup>" -AutomationAccountName "<AutomationAccountName>" -SubscriptionId "<SubscriptionId>" -Token "<Token>" 6>&1

Asegúrese de que -AutomationAccountName está presente y nombra tu existente cuenta. Sin él, el módulo crea una nueva Automation Account vacía en lugar de cambiar la que usas.

2

Ejecute el comando

Pegue el bloque en una nueva sesión de PowerShell y ejecútelo. El token es válido durante aproximadamente una hora — si ha expirado, vuelva a cargar la página de configuración y copie el comando de nuevo.

Se le pedirá que inicie sesión con Connect-AzAccount. Luego, la implementación informa de cada recurso y asignación de rol a medida que se aplica; lo que ya existe se detecta y se omite.

Cerrar sesión después: el inicio de sesión de Azure permanece activo después de que el comando haya terminado. Cuando haya terminado, ejecute Disconnect-AzAccount para cerrar sesión de la sesión existente.

3

Verifique en el Portal

Vuelva a Configuración → Runbooks y seleccione Actualizar.

El aviso de migración desaparece y la página ahora muestra Configuración de sincronización de runbooks con las opciones de rama y Hybrid Runbook Worker, además de una conexión de Azure sección de solo lectura. El ID de cliente y el secreto de cliente ya no forman parte de la configuración.

Comprueba que la rama es la que quieres y luego ejecuta un runbook para confirmar que la ejecución sigue funcionando.

4

Limpiar el antiguo registro de aplicación

Una vez que todo funcione, el RealmJoin Runbook Management registro de aplicación ya no se usa para runbooks y se puede quitar en Entra ID, junto con su asignación de rol Contributor en el grupo de recursos.

Comprueba primero qué más usa ese registro de aplicación. Es la misma aplicación que la heredada Log Analytics configuración puede reutilizar — si tu tenant sigue usando allí la Data Collector API, o aún lee datos de registro escritos antes de esa migración, el registro de aplicación y su secreto siguen siendo necesarios. Consulta Migración a la API de ingestión de registros.

Solución de problemas

"El módulo de RealmJoin está desactualizado - no se puede continuar con la ejecución"

Cada cmdlet verifica una vez por sesión que estás ejecutando la última versión publicada. Instala la versión actual y luego cierra la sesión y abre una nueva:

Install-Module -Name RealmJoin -Force -Scope CurrentUser

Se informa de un conflicto de versiones del módulo

Un Az.* módulo con una versión distinta de la fijada por el módulo de RealmJoin ya está cargado en la sesión. Esto no se puede corregir dentro de la sesión en ejecución — cierre PowerShell, abra una nueva sesión y ejecute el comando de nuevo. Esta es también la razón para no usar Azure Cloud Shell.

El despliegue falla al crear asignaciones de roles

Crear la asignación de Contributor en la Automation Account requiere un rol que pueda administrar el acceso — por ejemplo Propietario, Administrador de acceso de usuario o Administrador de Control de acceso basado en roles. Colaborador por sí solo no es suficiente.

Las asignaciones de roles que ya existen se detectan y se omiten, por lo que volver a ejecutar el comando después de corregir los permisos es seguro.

La implementación falla al asignar permisos de aplicación

Conceder roles de aplicación de Graph, Exchange, Defender y SharePoint a la identidad administrada requiere Administrador global o Privileged Role Administrator. Pide a alguien con ese rol que ejecute el comando, o ejecútalo de nuevo tú mismo después de que se haya activado el rol.

La sincronización de runbooks deja de funcionar después del cambio

Abra Configuración → Runbooks y revisa el aviso que se muestra en la parte superior de la página — RealmJoin verifica la configuración de la Automation Account cada vez que se carga la página. Luego usa Mostrar cmdlet en la conexión de Azure para volver a ejecutar el comando de configuración; es idempotente y vuelve a aplicar todo lo que falte.