Configurar Azure AD y SharePoint para identidades administradas

Trabajar con Azure AD, SharePoint y Power Platform cada vez exige más seguridad y configuraciones algo más finas de las que estamos acostumbrados. Cuando queremos automatizar procesos como gestionar documentos, integrar Dataverse o preparar el terreno para crear y administrar usuarios en Azure AD a partir de datos de SharePoint, ya no basta con «tirar» de las credenciales de siempre.

Desde marzo de 2025, Microsoft ha endurecido la forma en que se accede a la tabla de documentos de SharePoint desde Dynamics 365 y aplicaciones basadas en modelos, especialmente cuando dicho acceso se realiza desde Power Automate o llamadas a la API de Dataverse. Esto implica que necesitamos usar una aplicación registrada en Azure, identidades administradas y credenciales federadas para seguir trabajando con seguridad y sin interrupciones.

Contexto: por qué necesitas una app de Azure para acceder a SharePoint

Cuando una solución de negocio en Dynamics 365 o Power Platform usa la tabla de documentos de SharePoint, muchas veces lo hace fuera de la clásica cuadrícula de documentos de una app basada en modelos. Es decir, se accede a SharePoint desde flujos de Power Automate, plugins, conectores personalizados o llamadas directas a la API de Dataverse que necesitan permisos intensivos sobre los sitios y bibliotecas.

Hasta hace poco, este acceso podía aprovechar mecanismos heredados menos estrictos, pero Microsoft ha decidido retirar ese acceso en marzo de 2025 para reforzar la protección del entorno. En la práctica, si no preparas la nueva configuración, te puedes encontrar con flujos que dejan de funcionar, integraciones que ya no leen ni escriben documentos, o automatismos que empiezan a fallar sin previo aviso.

La solución pasa por crear y configurar una aplicación en Azure (Microsoft Entra ID) que actúe como identidad centralizada para las integraciones, asignarle los permisos adecuados de SharePoint y enlazarla con Dataverse mediante identidades administradas y credenciales federadas. Todo esto te permitirá seguir ejecutando automatizaciones que, por ejemplo, leen listas de SharePoint, gestionan documentos o incluso sirven como base de procesos que después crean o administran usuarios en Azure AD a partir de esa información.

Registro de una aplicación en Azure con permisos sobre SharePoint

El primer pilar de esta configuración es registrar una aplicación en Azure (Microsoft Entra ID) que será la que represente a tus automatizaciones cuando necesiten hablar con SharePoint. Esta app funcionará con permisos de aplicación (no delegados), de manera que podrá operar sin depender de un usuario conectado interactuando.

Para empezar, entra en el portal de Azure con una cuenta que tenga permisos para gestionar registros de aplicaciones y configuración de Entra ID. Una vez dentro, ve a la sección de «Registros de aplicaciones», normalmente visible dentro de Microsoft Entra ID o directamente en «Servicios de Azure». Ahí es donde vas a crear la identidad que usará Dataverse para acceder a SharePoint.

Haz clic en «Nuevo registro» y asigna un nombre reconocible a la aplicación, de manera que sea fácil identificarla como la que gestiona la autenticación con SharePoint (por ejemplo, algo alusivo a Power Platform o a la organización). En el apartado de «Tipos de cuenta admitidos», selecciona la opción que restringe el acceso a «Cuentas solo en este directorio organizativo», ya que la app va a trabajar dentro de tu tenant concreto.

Al completar el asistente, pulsa en «Registrar» para finalizar la creación de la app. En la pantalla de resumen de la aplicación registrada, en la sección de «Información básica» u «Essentials», verás dos valores críticos: el «Id. de la aplicación (cliente)» y el «Id. de directorio (inquilino)». Estos identificadores en formato GUID serán claves más adelante para vincular la app con Dataverse y la configuración de identidades administradas.

Anota y guarda con cuidado el Id. de la aplicación (clientId) y el Id. de directorio (tenantId), ya que los vas a usar tanto al crear los registros de identidad administrada en Dataverse como al definir la credencial federada que generará el token correcto para SharePoint.

A continuación, necesitas conceder a la aplicación los permisos adecuados sobre el API de SharePoint. En el menú de navegación de la app, entra en «Permisos de API» y selecciona la opción «Agregar un permiso». Elige el servicio SharePoint y, cuando se te pregunte por el tipo de permisos, marca «Permisos de aplicación», que son los que permiten a la app actuar por sí misma sin un usuario interactivo.

Dentro de la lista de permisos disponibles, localiza y selecciona «Sites.FullControl.All». Este permiso otorga a la aplicación control total sobre todos los sitios de SharePoint del tenant, algo que encaja con escenarios donde Power Platform gestiona documentos, carpetas y metadatos de forma intensiva. Una vez marcado, haz clic en «Agregar permisos» para incorporarlo a la app.

Con el permiso añadido, aún falta el paso clave: conceder el consentimiento de administrador. En la misma pantalla de permisos, verás la opción de «Conceder el consentimiento de administrador para <nombre del inquilino>». Ejecuta esta acción con una cuenta que tenga privilegios de administrador global o similar, para que el permiso de SharePoint quede activo y la app pueda usarlo en producción.

Creación de identidades administradas en Dataverse

Con la aplicación de Azure lista y con los permisos correctos sobre SharePoint, el siguiente paso es conectar esa identidad con Dataverse mediante registros de identidad administrada. Esto permite que sea el propio entorno de Power Platform el que utilice esa app para generar tokens y acceder de manera segura a SharePoint.

El proceso se realiza creando registros en las tablas internas de Dataverse, concretamente en la tabla «managedidentity», que representa cada identidad administrada asociada a un entorno. Para ello, puedes utilizar la API web de Dataverse, apoyándote en herramientas como Postman, Insomnia o cualquier cliente HTTP que te facilite lanzar peticiones autenticadas.

En la tabla managedidentity tendrás que insertar una nueva fila con una serie de campos específicos. El campo applicationid debe contener el GUID del Id. de la aplicación (cliente) que obtuviste al registrar la app en Azure. Por su parte, el campo tenantid almacenará el GUID del Id. de directorio (inquilino) del mismo registro de aplicación.

Además de esos identificadores, hay otros campos de configuración que determinan el tipo de credencial y el alcance. En credentialsource debes establecer el valor 2, que indica una fuente de credenciales gestionada (IsManaged) por la plataforma. En el campo subjectscope se debe usar el valor 1, que corresponde a un ámbito de tipo EnvironmentScope, es decir, ligado a un entorno concreto de Dataverse.

La petición HTTP a la API web de Dataverse tendrá forma de POST a la URL [Organization URI]/api/data/v9.2/managedidentities, con cabeceras típicas de OData (por ejemplo, Content-Type application/json, OData-MaxVersion 4.0, etc.) y un cuerpo JSON parecido a este, adaptado a tus valores reales:

POST [Organization URI]/api/data/v9.2/managedidentities
Content-Type: application/json; charset=utf-8
OData-MaxVersion: 4.0
OData-Version: 4.0
Accept: application/json
{
"applicationid": "<appId>",
"credentialsource": 2,
"subjectscope": 1,
"tenantid": "<tenantId>"
}

Si todo va bien, la API devolverá una respuesta HTTP 204 No Content, acompañada de una cabecera OData-EntityId que incluye la URL del nuevo registro creado. Dentro de esa URL verás un GUID que corresponde al managedidentityid, algo como aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb; guarda ese identificador porque lo necesitarás para relacionarlo con la identidad administrada específica de SharePoint.

Asociar la identidad administrada de SharePoint en Dataverse

Una vez que la identidad administrada base está creada en la tabla managedidentity, toca vincularla a una entrada de tipo SharePoint managed identity, que vive en la tabla sharepointmanagedidentity. Esta es la pieza que conecta explícitamente Dataverse con el uso de SharePoint mediante dicha identidad.

Para ello, tendrás que insertar una nueva fila en la tabla sharepointmanagedidentity utilizando, de nuevo, la API web de Dataverse. El campo uniquename debe contener un nombre único dentro del entorno, por ejemplo "new_ppmiforsharepointauth", que identifica claramente que esta identidad está pensada para la autenticación con SharePoint.

En el campo name puedes usar una etiqueta descriptiva y amigable, como "Identidad administrada para la autenticación de SharePoint" o similar, que te sirva para localizarla rápidamente desde herramientas de administración o scripts.

Lo más importante es la relación con el registro de identidad administrada base que creaste antes. Para eso se utiliza el campo de enlace ManagedIdentityId@odata.bind, cuyo valor debe apuntar al recurso /managedidentities(<managedidentityid>), sustituyendo <managedidentityid> por el GUID devuelto anteriormente por la creación de la identidad administrada.

La petición a la API web de Dataverse quedaría aproximadamente así, de nuevo usando POST pero ahora contra la tabla sharepointmanagedidentities:

POST [Organization URI]/api/data/v9.2/sharepointmanagedidentities
Content-Type: application/json; charset=utf-8
OData-MaxVersion: 4.0
OData-Version: 4.0
Accept: application/json
{
"uniquename": "new_ppmiforsharepointauth",
"name": "Managed Identity For SharePoint Auth",
"ManagedIdentityId@odata.bind": "/managedidentities(<managedidentityid>)"
}

Al igual que antes, la respuesta será HTTP 204 No Content con la cabecera OData-EntityId señalando al nuevo registro, por ejemplo sharepointmanagedidentities(bbbbbbbb-1111-2222-3333-cccccccccccc). Ese GUID es el sharepointmanagedidentityid, que tendrás que usar al construir el identificador del sujeto (subject) para la credencial federada en Azure.

Configuración de credenciales federadas en la aplicación de Azure

Con la aplicación registrada en Azure y las identidades administradas ya creadas en Dataverse, el último gran bloque es configurar una credencial federada en el propio registro de la app. Esta credencial es la que permite a Power Platform intercambiar tokens con Azure AD de forma segura, usando la relación establecida con la identidad administrada y SharePoint.

Para configurarla, vuelve al portal de Azure y accede a Microsoft Entra ID. Dentro del menú, entra a «Registros de aplicaciones» y localiza el registro concreto que creaste para gestionar el acceso a SharePoint. Ábrelo para editar su configuración de autenticación y certificados.

En el panel lateral del registro, entra en «Certificados y secretos», y después dirígete a la pestaña de «Credenciales federadas». Ahí tendrás la opción de «Agregar credencial», que es donde vas a definir tanto el emisor (issuer) como el sujeto (subject) que representará a Dataverse.

En el campo de «Escenario» para la credencial federada, selecciona «Otro emisor», ya que vas a indicar manualmente tanto la URL del emisor como el patrón del identificador de sujeto. Esto te da la flexibilidad de encajar la configuración exacta que requiere Power Platform para las identidades administradas de SharePoint.

En el campo «Emisor» debes escribir una URL con el formato https://login.microsoftonline.com/<tenantId>/v2.0, sustituyendo <tenantId> por el GUID del Id. de directorio (inquilino) de tu app de Azure. Esa URL representa el punto de emisión de tokens de Azure AD para tu tenant.

El campo clave es el de «Valor», donde se establece el identificador del sujeto que se usará en la relación federada. El formato esperado es una cadena del tipo:
/eid1/c/pub/t/<base64-encoded-tenantId>/a/<base64-encoded-appid>/Env/<orgid>/sharepointmanagedidentity/<sharepointmanagedidentityid>

En esa estructura, el tenantId codificado en Base64 URL-safe se coloca en <base64-encoded-tenantId>, y el identificador de la aplicación de Power Platform que actúa como Managed Identity (un AppId concreto proporcionado por Microsoft) también va codificado en Base64 en <base64-encoded-appid>. Además, <orgid> es el GUID del entorno u organización de Dataverse, mientras que <sharepointmanagedidentityid> corresponde al GUID de la entrada creada en la tabla sharepointmanagedidentity.

Una vez que completes estos datos, pulsa en «Agregar» para crear la credencial federada. A partir de ese momento, la identidad administrada de Dataverse vinculada con SharePoint podrá obtener tokens a través de esta configuración, permitiendo que flujos, plugins o integraciones externas accedan a la tabla de documentos de SharePoint de manera controlada y segura.

Generación del identificador de sujeto con PowerShell

Montar a mano la cadena del subject para la credencial federada puede ser bastante engorroso, sobre todo porque implica codificar GUIDs a Base64 de forma segura para URL y respetar una estructura muy concreta. Para simplificar esta tarea, puedes usar un script de PowerShell que genere automáticamente tanto el identificador de sujeto como otros valores relevantes.

El script propuesto define una función llamada GetSharePointManagedIdentifyConfig, que recibe varios parámetros obligatorios: el tipo de entorno (EnvironmentType), el GUID de la SharePoint Managed Identity (SharePointManagedIdentityId), el tenantId y el EnvironmentId asociado al entorno de Dataverse donde aplicas la configuración.

El parámetro EnvironmentType debe ser uno de los valores reconocidos por el script: Public, Gov, GovFR, High, DoD, MoonCake, USNat o USSec. Cada uno de ellos está asociado a una combinación distinta de issuer URL y Token Exchange Resource URL, ya que distintas nubes soberanas y regiones usan endpoints diferentes de autenticación.

Dentro del script se declara una función interna llamada Convert-ToBase64Url, que se encarga de transformar un GUID en su versión codificada en Base64 URL-safe. El procedimiento convierte el GUID a un array de bytes, lo codifica a Base64, elimina los signos de relleno (=) y reemplaza los caracteres + y / por - y _ respectivamente, asegurando así que el resultado sea válido para usar en URLs.

El script también define una constante con el AppId de la Power Platform Managed Identity, 58e835ab-2e39-46a9-b797-accce6633447, que es el identificador utilizado por Dataverse para estas integraciones. Este valor también se pasa por la función de codificación Base64 URL-safe para encajar en la cadena final del sujeto.

La configuración de entornos se gestiona mediante una lista ($environmentConfigList) que asigna a cada grupo de entornos un IssuerUrl, un TokenExchangeResourceUrl y un SubjectPrefix. Por ejemplo, para entornos de tipo Public, Gov y GovFR se usa el emisor https://login.microsoftonline.com/ y un prefijo de sujeto /eid1/c/pub, mientras que para entornos de tipo High o DoD se emplea https://login.microsoftonline.us/ con otro prefijo diferente.

Cuando invocas la función GetSharePointManagedIdentifyConfig, esta busca la configuración adecuada según el EnvironmentType proporcionado, construye la Issuer URL concatenando el tenantId y el sufijo /v2.0, y codifica en Base64 el tenantId y el AppId gestionado. Con todo eso, genera la cadena del sujeto con este patrón:
{SubjectPrefix}/t/{encodedTenantId}/a/{encodedAppId}/Env/{EnvironmentId}/sharepointmanagedidentity/{SharePointManagedIdentityId}

La función devuelve una salida formateada con los datos de entrada, los valores calculados y, finalmente, la URL de sujeto para la configuración de la credencial federada. Ese último valor es el que debes copiar y pegar en el campo «Valor» cuando creas la credencial federada en la app de Azure.

Para usar el script, primero lo guardas como GetSharePointManagedIdentifyConfig.ps1 y luego creas un segundo script test.ps1 que lo importe y le pase los parámetros adecuados. En test.ps1 se suele usar una estructura de hashtable como esta:

. .\GetSharePointManagedIdentifyConfig.ps1
$configInput = @{
environmentType = "<environmentType>"
sharePointManagedIdentityId = "<sharePointManagedIdentityId>"
tenantId = "<tenantId>"
environmentId = "<environmentId>"
}
GetSharePointManagedIdentifyConfig @configInput

Al ejecutar test.ps1, verás una salida con los datos de entrada, los IDs codificados, el issuer calculado y el resultado final del Subject URL. Ese valor final es el que se utiliza en la credencial federada; por ejemplo, algo similar a:
/eid1/c/pub/t/u7uqqgAAzMwREd3dIiLu7g/a/qzXoWDkuqUa3l6zM5mM0Rw/Env/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/sharepointmanagedidentity/bbbbbbbb-1111-2222-3333-cccccccccccc

Con esta combinación de app de Azure con permisos de SharePoint, identidades administradas en Dataverse y credenciales federadas cuidadosamente configuradas, dispones de una base robusta y alineada con las nuevas exigencias de seguridad de Microsoft. A partir de ahí, puedes diseñar flujos y soluciones que aprovechen listas y documentos de SharePoint como origen de datos para procesos avanzados (incluyendo la creación y gestión de usuarios en Azure AD), sabiendo que la autenticación está bien resuelta, es escalable y cumple con los requisitos modernos de protección del entorno.