Contexto de segurança de conexões do PowerPivot em um farm

Mesmo que eu fale rápido, não é possível incluir tudo em um único vídeo.

Portanto, esta é a continuação da seção anterior, e nosso foco agora será a Integração do PowerPivot com os Serviços do Excel.

Creio que muito já se falou sobre o PowerPivot para Excel, mas o resultado disso é um arquivo XLSX que, se você analisar, é um arquivo zip e está de alguma forma inserido no formato de arquivo, o que é basicamente um ABF.

Pense em um ABF como nosso formato de arquivo de backup.

Portanto, imagine que, em alguma parte do XLSX está inserido um ABF e que o nosso sistema, quando recebe um XLSX, sabe localizar o ABF, recuperá-lo e interagir com ele.

Criei um deles usando o Suplemento PowerPivot para Excel e criei este XLSX, que tem um ABF inserido nele.

Eu o carreguei no SharePoint.

Voltando aqui, estou com ele aberto, vejo-o no navegador e agora quero interagir com ele.

Quero na verdade clicar em uma Segmentação de Dados ou expandir algum nível na Tabela Dinâmica.

Quando isso ocorre, assim como ocorre com qualquer fonte de dados, temos uma fonte de dados.

Nosso Provedor OLE DB é geralmente chamado de MS OLAP, e ele diria aos Serviços do Excel: “Preciso emitir esta consulta MDX para obter mais dados, a fim de descobrir o que devo exibir“.

Vou abrir uma conexão via MS OLAP e enviar essa consulta.

Vamos voltar ao que vimos há pouco, onde o nome de usuário é autenticado até aqui.

Tenho um token de declaração que flui até aqui e tenho o Claims to Windows Token Service sendo executado em meu computador, com o qual esta pessoa interage em uma chamada para obter um token.

E existe a conexão física, em que você na verdade abre um arquivo chamado connections.xml, que está inserido no arquivo zip, e nele você encontrará uma conexão cuja fonte de dados está listada como $embedded$.

Se você o abrir no Cliente do Excel, poderá ir para Conexões; depois de criar essa pasta de trabalho, vá para Conexões e poderá vê-lo.

Se você for para as Propriedades Avançadas para a Autenticação do Excel, verá que marcamos Windows.

Talvez esteja um pouco rápido, mas há pouco falamos que, para o Windows, o Excel típico exigiria a delegação restrita de Kerberos, caso contrário, você não poderia realmente transmitir um token válido do Windows.

Você não pode saltar do computador para um SQL Server em outro computador ou um banco de dados Oracle.

Em nosso mundo, no entanto, permitimos o Windows porque fazemos parte do mundo SharePoint.

Na verdade, somos capazes de entender tokens de declaração e usar o SharePoint STS para gerar um token de declaração até dentro do MS OLAP.

O que acaba acontecendo no MS OLAP é que a chamada entra e, então, nós vemos que é uma chamada $embedded$.

Junto com isso, há uma interface no Provedor OLE DB onde os Serviços do Excel nos dizem basicamente que estamos em um modo hospedado.

Portanto, esse Provedor MS OLAP é o mesmo que seria invocado se eu estivesse no Cliente do Excel abrindo minha pasta de trabalho e clicando em Segmentações de Dados.

O fato de trabalharmos de modo diferente aqui e aqui, precisávamos ter como saber, e os Serviços do Excel realmente nos dizem que estamos em um ambiente hospedado.

A conclusão é não carregar esse ABF inserido em seu espaço de processamento.

Queremos carregá-lo em um servidor separado, talvez um servidor independente, que é na verdade um mecanismo completo do Analysis Services.

Uma forma clássica de se pensar no servidor é como um local onde podemos fazer coisas como compartilhar.

Se várias pessoas estiverem abrindo a mesma pasta de trabalho, poderemos carregá-la apenas uma vez.

Podemos, por exemplo, armazenar em cache o ABF extraído localmente em disco em um formato que seja mais fácil e rápido de ser carregado pelo Analysis Services.

Podemos fazer muitas outras coisas que estão em diferentes figuras, mas essa é a chave.

Existe uma forma de detectarmos e ter um handshake com nosso chamador que não signifique carregar no processo.

Portanto, quando o MS OLAP recebe essa chamada, ele reconhece que é $embedded$ e estamos em um ambiente hospedado; portanto não queremos carregar nada.

O que vamos precisar perguntar é qual é a melhor maneira. O MS OLAP, no nível mais baixo, tem quatro transportes.

Temos um TCP, um HTTP, um Local e o que chamamos de Canal.

Este é novo. Este está conectado ao AS, apenas uma conexão normal.

Este é classicamente MSMDPUMP.

Este classicamente era usado para arquivos cub.

Este é um novo componente que nós escrevemos para que, assim como aqui, haja uma associação WCF; nós podemos configurar e interagir com o WCF em um mundo gerenciado.

Na verdade, o que fazemos é voltar ao mundo gerenciado e interagir diretamente com o serviço Web de back-end que está à frente do Analysis Services.

Este é um serviço de entidade física, e este é um serviço Web.

E, do outro lado, transmitimos declarações.

Utilizamos este usuário, o Excel chama o Claims to Windows Tokens Service e recebemos um token de usuário limitado.

O token de usuário limitado é suficiente para regenerarmos o mesmo conjunto de declarações que estavam fluindo por esse nível.

Nós os regeneramos.

Nossa associação utiliza o mesmo token de emissão no transporte.

Criamos o fluxo e, nesse ponto, podemos, por exemplo, validar que você tinha acesso ao arquivo, rastrear as informações sobre você e encaminhar a você o Analysis Services Server apropriado.

Isso pode significar que temos que carregá-lo.

Talvez o banco de dados já tenha sido carregado.

Em um cenário de vários computadores, podemos escolher um deles com base em um sistema de rodízio ou na integridade.

Apenas como observação, esse transporte local que eu mencionei aqui foi anteriormente usado para arquivos cub, o mesmo que é usado aqui.

No mundo exclusivo do Excel, é utilizado o método local, que basicamente carrega o arquivo ABF no processo.

Portanto, podemos usar isso no processo, e isso é o que usamos para inserir onde queremos realmente sair do processo.

Essa é a maneira fácil de entender por que não exigimos Delegação Restrita de Kerberos, embora trate-se de uma fonte de dados separada.

Em geral, qualquer fonte de dados usada pelo ECS que esteja marcada como Windows exige Kerberos.

Há alguns elementos interessantes a serem observados sobre tudo isso.

Um deles, como mencionei antes, é que o c2wts vai realmente tentar fazer uma chamada para ir ao AD.

Se o seu computador estiver desconectado da rede, não poderá se comunicar com o Active Directory.

Acredito que tenha sido falado sobre uma das alternativas ser a configuração do Active Directory no mesmo computador.

Você pode fazer isso, mas saiba que o Claims to Windows Token Service, embora não estejamos tentando usar a Delegação Restrita de Kerberos, tentará se comunicar com o AD, mesmo que apenas para obter um token limitado.

Outra coisa a ser observada, que mencionei antes, é que, embora geralmente se faça a autenticação NTLM do Windows, você poderia fazer a autenticação baseada em formulários e, tecnicamente, baseada em declarações.

Se você fizer uma destas, isto não funcionará.

Não há como converter um usuário de autenticação baseada em formulários em usuário do Windows.

Você não pode fazer isso.

Neste ponto, isso deixa de ser uma opção.

Portanto, se você configurou a autenticação baseada em formulários, e nós tivermos recursos que não funcionam exatamente com a autenticação baseada em formulários, este cenário poderá funcionar se você alterar isto para Nenhum ou SSO.

Isso afetará a nossa capacidade de rastrear informações.

Quando todo este fluxo estiver ocorrendo, estaremos na verdade rastreando o fato de que o usuário X fez algo e, dentro do Analysis Services, o que fazemos é configurar o usuário efetivo, que é um termo clássico do AS, para que no SQL Profiler e similares, quando você vir quem está interagindo, você verá este usuário.

Se o usuário estiver sendo autenticado com um destes métodos, não poderemos fazer este fluxo.

Portanto, se você usar Nenhum ou SSO, poderá conseguir, mas perderá informações.

Você pode, na verdade, fazer as coisas funcionarem corretamente.

Portanto, estes são dois aspectos importantes a serem entendidos para configurações de topologias diferentes.