Riscos envolvidos na configuração da autenticação Kerberos para o WSS Reporting Services

Question

Riscos envolvidos na configuração da autenticação Kerberos para o WSS Reporting Services

Navegue suas respostas

#1 resposta do (2 votos)
#2 resposta do (1 votos)
#3 resposta do (0 votos)

3

Temos uma intranet estabelecida com base no WSS com dois front ends e um banco de dados.

Atualmente, toda a autenticação é NTLM.

Instalamos o Reporting Services no modo de integração.

O RS funciona desde que o front-end da web que tem o RS instalado nele lide com as transações.

Se o front-end sem RS manipular a solicitação, obteremos um erro NÃO AUTORIZADO.

Na tentativa de corrigir esse problema, pesquisas na Web, etc. - aludiram ao problema que está sendo causado pelo farm que precisa executar a autenticação 'double-hop' - que não pode acontecer via NTLM.

Portanto, precisamos configurar o farm da Intranet para aceitar a autenticação do Kerberos.

Eu encontrei este útil guia Mas é preciso ter a mesma opinião de que estamos iniciando fazenda do zero.

Então, precisamos saber se há algum risco envolvido na configuração retroativa do Kerberos? O NTLM continuará como antes enquanto e depois de executarmos as etapas para ativar o Kerberos?

kerberos sharepoint ntlm ssrs wss

por Mesh 11.06.2009 / 17:33

3 respostas

2

Normalmente, fazemos o NTLM do SharePoint retroativo às alterações de autenticação do Kerberos, como você está propondo. Quando estabelecemos nossos sites do SharePoint, leva alguns dias para que as alterações de DNS se propaguem, e obter nossos SPNs definidos nas contas de serviço normalmente leva algum tempo também.

Assim, depois que nossos SPNs forem definidos, primeiro criaremos um pequeno site de teste no servidor que estiver sendo executado no pool de aplicativos do SP. Ativamos o WIA e colocamos uma única página de teste:

<%@ Page Language="C#" %>
<script runat="server" language="C#">
  void Page_Load(object Sender,EventArgs E)
  {
    if (User.Identity.IsAuthenticated) {
      lblIdentity.Text = User.Identity.Name;
    } else {
      lblIdentity.Text = "Anonymous";
    }
    lblImpersonation.Text =
      System.Security.Principal.WindowsIdentity.GetCurrent().Name;
  }
</script>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
  <HEAD>
    <TITLE>Test Application</TITLE>
  </HEAD>
  <BODY>
    <FORM id="frmForm1" method="post" runat="server">
      <HR width="100%" size="1">
      <P>
        <ASP:LABEL id="Label1" runat="server">Current Identity:
          </ASP:LABEL>&nbsp;
        <ASP:LABEL id="lblIdentity" runat="server">Label</ASP:LABEL>
      </P>
      <P>
        <ASP:LABEL id="LABEL3" runat="server">Impersonated Identity:
          </ASP:LABEL>&nbsp;
        <ASP:LABEL id="lblImpersonation" runat="server">Label</ASP:LABEL></P>
      <HR width="100%" size="1">
    </FORM>
  </BODY>
</HTML>

Navegue até a página com o Fiddler ativo e determine se o Kerberos funciona (a guia de autenticação do Fiddler mostrará se você está usando o NTLM ou o Kerberos).

Depois que você souber que o Kerberos funciona para sua conta de serviço / servidor / URL, vá em frente e faça a alteração no SharePoint.

por 12.06.2009 / 16:42

0

Graças a ambos os respondentes - ambos deram um excelente conselho.

Gostaria de destacar algumas ferramentas adicionais que descobrimos no caminho, enquanto configuramos nosso farm para o Kerberos:

DelegConfig V2 (beta!):

Por Brian Murphy-Booth Nós não poderíamos ter feito isso sem este Faça o download do seu blog Você responde a perguntas sobre a configuração que você quer e fornece onde e por que vai ou não vai funcionar - até tem instalações de teste e se a execução sob contas de administrador pode fazer as alterações necessárias para você.

Metabase Explorer

Muitos artigos recomendam que você use adsutil.vbs para definir o valor NTAuthenticationProviders de cada site. Achamos muito mais fácil usar o Metabase Explorer - especialmente porque tivemos que definir o valor em diretórios virtuais abaixo do site padrão. Também revela muitos muitos valores assustadores na metabase! Use com CUIDADO! Parte das Ferramentas do IIS 6.0 Resource Kit

por 17.06.2009 / 11:16

Tags kerberos sharepoint ntlm ssrs wss

Qual é a melhor maneira de acompanhar o Jitter e o Packetloss? Não é possível obter o arquivo proxy.pac para fazer com que os navegadores acessem DIRECT para localhost

score 1 · Accepted Answer

Existe algum risco em ativar a delegação do Kerberos para permitir saltos duplos. Basicamente, você está permitindo que o IIS represente o usuário sem que o usuário realmente insira quaisquer credenciais novamente. Em um ambiente do Active Directory do Windows 2000, existe apenas o que é conhecido como delegação sem restrições. Basicamente, você não pode restringir o que está fazendo a delegação e para onde ela pode delegar muito bem (assim como você gostaria). Nesses casos, a Microsoft recomenda enfaticamente não usar a delegação do Kerberos. Se você estiver no Windows 2003 ou no Active Directory 2008, poderá e deverá usar a delegação restrita. Isso permite que você seja bastante específico com a delegação. Nesse caso, há um risco maior, mas geralmente o fato de você não ter usuários que digitarem novas credenciais ou usar suas contas de serviço ou logins do SQL Server vale o risco aumentado.

Na medida em que o NTLM continuará ou não, isso depende. Se a autenticação Kerberos puder ser estabelecida, ela será usada. Isso inclui nos casos em que ele está retornando um erro (e você não acha que deveria ser), como se os SPNs estivessem errados, etc. Ele só retornará ao NTLM se a autenticação Kerberos não puder ser usada. Com isso dito, o Kerberos é o protocolo de segurança mais novo e possui recursos de segurança que o NTLM não inclui o timestamp (impedindo ataques de retransmissão), a capacidade do cliente de verificar a identidade do servidor (que o NTLM não pode fazer) e o uso de tickets o que deve reduzir o tráfego geral de autenticação para os DCs.