Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Recuperación de agentes utiliza autenticación de servidor a servidor (S2S) de alta confianza para conectarse a SharePoint Server local. En lugar de almacenar un nombre de usuario y una contraseña, la extensión firma un json Web Token (JWT) con una clave privada de certificado y SharePoint lo valida mediante la clave pública registrada.
Si necesita ingerir contenido de SharePoint en entornos restringidos o desconectados, este enfoque le ayuda a evitar las credenciales almacenadas y la dependencia de tokens externos, sin dejar de mantener disponible la autenticación.
En este artículo se explica la arquitectura de autenticación, los componentes de confianza y el modelo de configuración para que pueda planear una conexión segura SharePoint para su entorno.
Este artículo se aplica si ejecuta Recuperación de agentes en Azure Kubernetes Service (AKS) o Azure Local (Kubernetes habilitado para Azure Arc) y se conecta a SharePoint Server Edición de Suscripción (local).
Importante
Recuperación de agentes en Foundry local está actualmente en VERSIÓN PRELIMINAR. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.
Lo que configuras frente a lo que gestiona la extensión
En la tabla siguiente se muestran las tareas de instalación única que se completan y las tareas de certificado y token que la extensión controla automáticamente.
| Su responsabilidad (configuración inicial) | La extensión controla automáticamente |
|---|---|
| Crear un certificado de intercambio de información personal (PFX) y un archivo de certificado público (.cer) | Sincroniza el certificado de Key Vault en el clúster mediante el controlador container Storage Interface (CSI) |
| Carga de PFX en Azure Key Vault | Firma los tokens JWT con la clave privada del certificado en tiempo de ejecución |
| Registro de confianza de certificados en SharePoint Server | Guarda en caché los tokens (12 horas), gestiona la expiración y reintenta en caso de errores transitorios. |
| Registrar la entidad de servicio de la aplicación y conceder permisos en SharePoint | Monta el certificado en los pods de ingesta de forma segura |
| Creación de una identidad administrada y federación con el clúster | Detecta automáticamente el dominio de SharePoint (si no se proporciona) |
| Crear un perfil de usuario y obtener el identificador de Seguridad de Windows (SID) | |
| Proporcionar valores de configuración durante la implementación de la extensión o al agregar un origen de datos en el portal para desarrolladores |
Architecture
La arquitectura de ingesta de servidor a servidor SharePoint para la recuperación de agente usa confianza basada en certificados para autenticar solicitudes sin credenciales almacenadas ni un servicio de token externo. Azure Key Vault almacena el certificado PFX y la contraseña, el controlador CSI Secrets Store los sincroniza con Kubernetes y el pod de ingestión firma JWT localmente. SharePoint Server valida el token mediante la clave pública de confianza y, a continuación, devuelve documentos.
diagrama de 
Puntos de diseño clave
Esta arquitectura de ingesta de servidor a servidor usa confianza basada en certificados para proporcionar autenticación segura y resistente SharePoint en entornos conectados y desconectados sin almacenar credenciales de usuario.
- Sin contraseñas almacenadas: la autenticación usa un JWT firmado por certificado.
- No se requiere AD FS ni ACS: el pod crea el token localmente.
- Compatible con entornos desconectados o aislados: una vez que el certificado se sincroniza con el clúster, no se necesita conectividad con Azure para la autenticación.
- Aislamiento a nivel de origen de datos: diferentes sitios de SharePoint pueden usar identidades distintas.
- Almacenamiento en caché de tokens: los JWT son válidos durante 12 horas y se actualizan automáticamente.
Resumen de requisitos previos
Antes de implementar la recuperación de Agentic con SharePoint habilitado, asegúrese de que tiene lo siguiente:
- Un clúster de Kubernetes habilitado para AKS o Arc en funcionamiento.
- Acceso a Azure Key Vault.
- Un entorno de SharePoint Server Edición de Suscripción en funcionamiento.
- Se completó la configuración de certificados, identidades y confianza necesarias.
- Conectividad de red desde los pods del clúster a SharePoint y Azure Key Vault.
Para ver los pasos de instalación completos y la validación paso a paso, consulte Set up SharePoint server-to-server authentication for Agentic Recovery.
SharePoint campos de configuración
Al instalar Agentic Retrieval en el portal de Azure, la sección Data Source Connection / Authentication incluye los siguientes campos de SharePoint.
Campos de entrega de certificados y de acceso a Key Vault
Estos campos configuran cómo se entrega el certificado de Azure Key Vault al clúster. Cambiar estos campos requiere una actualización de Helm y un reinicio del pod después de la instalación.
| Campo portal | Clave de Helm | Tipo | Predeterminado | Description |
|---|---|---|---|---|
| Habilitar la ingesta de SharePoint | sharepoint.sharepointIngestionEnabled |
Control de alternancia | false |
Habilita todos los recursos de SharePoint (CSI SecretProviderClass, ServiceAccount, montajes de certificados). |
| Nombre de Key Vault | sharepoint.s2s.keyvaultName |
Texto | (vacío) | Nombre del Azure Key Vault que contiene el certificado PFX y la contraseña. |
| Nombre del secreto del certificado de KV | sharepoint.s2s.kvCertSecretName |
Texto | edgerag-sp-s2s-cert |
Nombre del secreto en Key Vault que contiene el certificado PFX (codificado en base64). |
| Nombre del secreto de contraseña de certificado KV | sharepoint.s2s.kvCertPasswordSecretName |
Texto | sp-cert-password |
Nombre del secreto en Key Vault que contiene la contraseña PFX. |
| Id. de cliente de identidad de carga de trabajo | sharepoint.s2s.workloadIdentityClientId |
Identificador único global (GUID) | (vacío) | Identificador de cliente de la identidad administrada asignada por el usuario que tiene acceso get a los secretos de Key Vault. |
| Identificador del inquilino de Key Vault | sharepoint.s2s.kvTenantId |
Identificador único global (GUID) | (automáticamente desde la sesión) | Identificador del inquilino de Microsoft Entra en el que se encuentran la identidad administrada y Key Vault. Este valor suele ser el inquilino de suscripción, que es el mismo inquilino en el que ha iniciado sesión en Azure Portal. Normalmente se rellena automáticamente y rara vez necesita cambiar. Vuelve a auth.tenantId si no se especifica. |
Campos de identidad del origen de datos
Establezca estos campos durante la instalación o posterior para cada origen de datos en el portal para desarrolladores. La extensión las almacena en un objeto ConfigMap. Puede actualizarlos sin volver a instalar mediante az k8s-extension update.
Si administra varios sitios de SharePoint con identidades diferentes, deje los campos de identidad de servidor a servidor vacíos en tiempo de instalación y configúrelos para cada origen de datos en el portal para desarrolladores.
| Campo portal | Clave de Helm | Tipo | Predeterminado | Description |
|---|---|---|---|---|
| Id de cliente | sharepoint.s2s.clientId |
GUID | (vacío) | El identificador de cliente de la aplicación que elige al registrar la entidad de servicio de la aplicación en SharePoint. |
| Identificador del emisor | sharepoint.s2s.issuerId |
GUID | (vacío) | El identificador del emisor que elige al registrar el emisor de tokens de seguridad de confianza. |
| SID predeterminado | sharepoint.s2s.defaultSid |
String | (vacío) | Windows SID de la cuenta de servicio (por ejemplo, S-1-5-21-...-1001). |
| Reino | sharepoint.s2s.realm |
GUID | (vacío, detectado automáticamente) | Ámbito de autenticación de SharePoint. Si se deja en blanco, la extensión la detecta automáticamente desde el servidor de SharePoint. |
Prioridad de configuración
Los valores de configuración se aplican en este orden:
- Si escribe valores de identidad de servidor a servidor durante la instalación, esos valores se convierten en valores predeterminados del clúster.
- Al agregar o editar un origen de datos de SharePoint, los valores de ese origen de datos invalidan los valores predeterminados del clúster.
- Si deja un campo de origen de datos en blanco, se aplica el valor predeterminado de instalación.
Este enfoque le permite usar una identidad compartida de forma predeterminada mientras usa identidades diferentes para sitios de SharePoint específicos.
Preguntas más frecuentes
¿La extensión necesita acceso a Internet para autenticarse en SharePoint? N.º El pod firma el JWT localmente mediante la clave privada del certificado. La extensión no se comunica con un servicio de token externo. La única conectividad Azure necesaria es la sincronización inicial del certificado desde Key Vault (a través del controlador CSI).
¿Qué versiones de SharePoint se admiten? SharePoint Server Edición de Suscripción (SE). Es posible que las versiones anteriores funcionen, pero no se prueban.
¿Puedo usar el mismo certificado para varios sitios de SharePoint? Yes. Registre la confianza en cada servidor de SharePoint y registre la entidad de servicio de la aplicación en cada colección de sitios. El certificado está en todo el clúster.
¿Y si no conozco mi dominio SharePoint?
Deje el realm campo en blanco. La extensión la detecta automáticamente mediante el envío de una solicitud no autenticada al servidor de SharePoint y el análisis del encabezado de respuesta WWW-Authenticate.
¿Puedo cambiar la identidad de servidor a servidor (id. de cliente, identificador de emisor, SID) sin reinstalar?
Yes. La extensión almacena estos valores en un objeto ConfigMap. Puede actualizarlos mediante az k8s-extension update. Los valores de instalación (nombre de Key Vault, identidad administrada) requieren una actualización de Helm.
¿Qué permisos necesita la entidad de servicio de la aplicación?FullControl en el ámbito de SiteCollection. Este nivel de permiso permite a la extensión enumerar y descargar documentos. El acceso de solo lectura no es suficiente porque SharePoint API requieren permisos elevados para la enumeración de la biblioteca de documentos.
¿Cuál es el SID de Windows y por qué es necesario?
El SID de Windows (identificador de seguridad, formato S-1-5-21-...) identifica la cuenta de servicio en la notificación de JWT nameid. SharePoint lo usa para resolver la identidad de usuario y aplicar permisos. Usar DOMAIN\username provoca errores HTTP 401.
¿Cómo llega el certificado al pod?
El controlador del almacén de secretos de CSI sincroniza el PFX y la contraseña desde Azure Key Vault con un secreto de Kubernetes. El pod monta este secreto como un volumen en /certs/cert.pfx y recibe la contraseña como la variable de entorno SHAREPOINT_CERT_PASSWORD. El pod nunca se comunica directamente con Key Vault.
¿Qué ocurre si Key Vault deja de ser accesible después de la configuración inicial? El secreto de Kubernetes persiste en el clúster. Los pods nuevos y existentes siguen funcionando mediante el secreto almacenado en caché. El certificado no gira hasta que se puede volver a acceder a Key Vault, pero la autenticación continúa sin interrupciones.