Contexto de seguridad de las conexiones de PowerPivot en una granja

Esta serie de cuatro vídeos de Lee Graber proporciona una introducción a la arquitectura de PowerPivot para SharePoint. La segunda parte se basa en la primera y explica el diagrama de flujo de la identidad de usuario cuando un usuario solicita datos PowerPivot.

Este vídeo se encuentra disponible con subtítulos cerrados. Para ver los subtítulos cerrados, haga clic en CC en la barra de control del vídeo.

Vídeo anterior

Vídeo siguiente

Pese a que hablo todo lo rápido que puedo, parece que no hemos sido capaces de hacer que todo cupiese en un solo vídeo.

Por tanto, esta es la continuación de la sección anterior y ahora nos centraremos en la integración de PowerPivot con Excel Services.

Creo que ya se ha hablado antes de PowerPivot para Excel y la conclusión, el resultado que se obtiene es un archivo XLSX, que en realidad, si lo miramos bien, es un archivo. zip y de alguna forma, incrustado en el formato del archivo, tenemos un ABF.

Podríamos considerar que un ABF es el formato del archivo de copia de seguridad.

Así que, podríamos imaginarnos que en alguna parte del XLSX hay incrustado un ABF y que nuestro sistema, cuando se le da un XLSX, sabría como encontrar el ABF, recuperarlo e interactuar con él.

Con lo cual, he creado uno de estos con un complemento PowerPivot para Excel y he creado este XLSX, que tiene incrustado un ABF.

Lo cargué en SharePoint.

Lo he abierto, lo puedo ver en el explorador y ahora quiero interactuar con él.

Es decir, hacer clic en una segmentación de datos o expandir algún nivel de la tabla dinámica.

Cuando hago esto, el comportamiento es igual que cualquier otro origen de datos porque en realidad es un origen de datos.

Nuestro proveedor OLE DB es por lo general MSOLAP y le va a pedir a Excel Services que emita esta consulta MDX para obtener más datos de forma que pueda saber lo que debo mostrar.

Abramos una conexión a través de MSOLAP y enviemos esta consulta.

Repasemos lo que acabo de decir hace un momento donde el usuario se autentica hasta llegar aquí.

Luego tengo un token de notificación que va hasta aquí y también tengo Notificaciones al servicio de token de Windows que se ejecutan en mi equipo y con las que esta persona está interactuando a través de una llamada, esencialmente para obtener un token.

Pasemos a la conexión, y hay una conexión física, en realidad podemos abrir un archivo que se denomina connections.xml, que es un archivo .zip incrustado y ahí encontraremos una conexión cuyo origen de datos aparece como $embedded$.

Si lo abrimos en el cliente Excel, puede ir a Conexiones; después de crear esto, se va a Conexiones, y ahí lo podrá ver.

Si va Propiedades avanzadas de la autenticación de Excel, verá que Windows está marcado.

Quizá vaya un poco rápido, pero hace un rato hablamos que para marcar Windows, un Excel típico necesitará la delegación limitada de Kerberos, de lo contrario, un token de Windows válido no podrá pasar.

No se puede saltar de un equipo a cualquier SQL Server que esté en otro equipo o a una base de datos de Oracle.

No obstante, en nuestro mundo, permitimos esta opción de Windows porque formamos parte del mundo de SharePoint y

tenemos la capacidad de descifrar los tokens de notificaciones y utilizar SharePoint STS para generarlos, incluso en MSOLAP.

Al final, lo que pasa es que la llamada entra en MSOLAP y la reconocemos, entonces, vemos que es $embedded$.

Y junto con todo esto hay una interfaz en el Proveedor OLE DB donde Excel Services esencialmente no está diciendo que estamos en un modo hospedado.

Con lo cual, este Proveedor MSOLAP es el mismo Proveedor MSOLAP que se invocaría si estuviera en el cliente de Excel abriendo el libro y haciendo clic en segmentaciones de datos.

Por tanto, existe una forma para saber que estamos trabajando de forma diferente aquí y aquí, y es Excel Services el que os indica que estamos en un entorno hospedado.

La conclusión es que no se debe cargar este ABF incrustado en su espacio de procesamiento.

Lo idóneo es cargarlo en un servidor independiente, potencialmente un servidor independiente, en un servicio independiente y que es en realidad un motor de Analysis Services a gran escala.

Se podría decir que es un servidor al estilo clásico donde podemos hacer cosas como compartir.

Es decir, si varias personas van a abrir el mismo libro, lo podríamos carga solo una vez.

También podríamos hacer cosas como almacenar en caché el ABF que hemos extraído localmente en el disco y en un formato que resulte sencillo para que Analysis Services lo pueda cargar rápidamente.

Podríamos hacer otras muchas cosas que están en los distintos dibujos, pero la clave está aquí.

Existe una forma que nos permite detectar e interactuar con el autor de la llamada que dice que no que quiere que se le cargue en el proceso.

Con lo cual cuando MSOLAP recibe esta llamada, reconoce que es $embedded$ y sabemos por tanto estamos en un entorno hospedado donde no queremos cargar nada.

Lo que vamos a determinar es cuál es el método más indicado. MSOLAP, en su nivel inferior, dispone de cuatro métodos de transporte.

Tenemos un TCP, un HTTP, tenemos un Local y tenemos lo que denominamos un Canal.

Este último es nuevo. Entonces, este está conectado a AS, se trata de una conexión normal.

Esto suele ser MSMDPUMP.

Este se utilizaba generalmente para archivos cub.

Este componente nuevo lo hemos incluido para que en este punto se utilice un enlace WCF; podemos configurar e interactuar con WCF en un entorno administrado.

En realidad lo que hacemos es volver a este entorno administrado e interactuar directamente con un servidor web back-end que está frente a Analysis Services,

que es un servicio de entidad privada y este otro un servicio web.

En el otro lado, transmitimos las consultas.

Entonces comenzamos con ese usuario, luego Excel se llama en las consultas para el servicio de token de Windows; estamos trabajando con un token de usuario limitado.

Pero este token de usuario limitado es suficiente para volver a generar el mismo conjunto de consultas que se han estado transmitiendo a través de este nivel.

Las volvemos a generar.

El enlace utiliza el mismo token de emisión en el transporte.

Pasa por todo el camino y al llegar a este punto, ya podemos hacer cosas como validar que se dispone de acceso al archivo, hacer un seguimiento de la información sobre el usuario y enviarlo al servidor de Analysis Services adecuado.

Esto podría indicar que tenemos que cargarlo.

Es posible que la base de datos ya esté cargada.

En un entorno con varios equipos, podremos escoger cualquiera de ellos basándonos en un sistema circular o de elección según el estado.

A modo de apunte, este transporte local que he mencionado anteriormente y que se usa para archivos cub, es lo mismo que se utiliza aquí.

En el mundo exclusivo de Excel se utilizará el método local, lo cual básicamente carga el archivo ABF en el proceso.

Por tanto, podemos utilizar esto para las tareas dentro del proceso y esto es lo que utilizamos cuando queremos usar "embedded" e irnos fuera del proceso.

Esta sería la forma rápida de explicar por qué no se necesita la delegación limitada de Kerberos incluso aunque se trate de un origen de datos independiente.

Por lo general, los orígenes de datos que utiliza ECS y que estén marcados con Windows necesitan Kerberos.

Ahora bien, hay un par de puntos interesantes sobre esto que se deben resaltar.

Uno, como ya comenté antes, es que c2wts va a intentar hacer llamar a algo para ir a AD.

Si el equipo no está conectado a la red, no será posible comunicarse con Active Directory.

Creo que ha habido otra exposición donde se indicaba que una de las alternativas era configurar Active Directory en el mismo equipo.

Con lo cual, se puede hacer esto, pero hay que tener en cuenta que Notificaciones del servicio de token de Windows (aunque no intentemos utilizar la delegación limitada de Kerberos) intentará ponerse en comunicación con AD, aunque solo sea para obtener un token limitado.

Otra cosa que hay que saber, que mencioné antes, es que pese a que pensemos que aquí estamos aplicando autenticación NTLM para Windows, quizás lo que estemos utilizando sea Autenticación basada en formularios o autenticación de notificaciones.

Con cualquiera de estas autenticaciones, esto no funcionaría.

No hay forma de convertir a un usuario de Autenticación basada en formularios en un usuario de Windows.

No se puede hacer.

Llegados a este punto, esto deja de ser una opción.

Por tanto, si se ha configurado la Autenticación basada en formularios - y hay ciertas cosas que no terminan de funcionar bien con esta opción - hay que saber que esta situación funcionaría si se cambia esto a Ninguno o a SSO.

Repercutirá en parte de nuestra capacidad para llevar un seguimiento de la información.

Con lo cual, cuando estamos viajando por aquí, en realidad podemos identificar qué hizo un usuario X, y en Analysis Servicies, lo que hacemos es establecer el usuario efectivo, un término típico en AS, de forma que en SQL Profiler y similares, cuando vayamos a comprobar quién está interactuando, podamos ver a este usuario.

Si el usuario se autentica con uno de estos métodos, no podremos pasar por aquí.

Pero si utilizamos Ninguno o SSO, sí que podremos hacerlo aunque perderemos algo de información.

Sin embargo, hacemos que el proceso funcione.

Con lo cual, estos eran los dos aspectos importantes a tener en cuenta para las distintas configuraciones de topologías.