A autenticação Kerberos e Solucionando problemas de delegação

Meu nome é Martin Smith e estou com grupo de resolução de problemas crítica do Microsoft Internet Information Services (IIS) da Microsoft. Eu sido Microsoft nove anos e ter sido com a equipe do IIS, todos os nove anos. Compilei informações de vários locais em http://msdn.microsoft.com (http://msdn.microsoft.com) e http://www.microsoft.com (http://www.microsoft.com) sobre como solucionar problemas de delegação e Kerberos.

IIS 6.0

O seguinte white paper descreve como configurar a delegação no Microsoft Windows Server 2003. O white paper tem informações específicas para rede NLB (balanceamento de carga) de mas inclui excelentes detalhes sobre como configurar um cenário delegado sem usando NLB. Para exibir este white paper, visite o seguinte site: Observação Use HTTP Service principal names (SPNs) especialmente quando você usa o NLB.

Outro problema Kerberos popular recentemente foi necessário para permitir vários pools de aplicativos usar o mesmo nome DNS. Infelizmente, quando você usa o Kerberos para delegar credenciais, você não pode vincular o nome principal do mesmo serviço (SPN) para pools de aplicativos diferentes. Você não pode fazer isso por causa do design do Kerberos. O protocolo Kerberos requer vários segredos compartilhados para o protocolo funcione corretamente. Usando o mesmo SPN para pools de aplicativos diferentes, podemos eliminar um desses segredos compartilhados. Será suporte ao protocolo essa configuração do Kerberos devido o problema de segurança de serviço de diretório do Active Directory.

Configurar os SPNs dessa maneira faz com que a autenticação Kerberos falha. Uma possível solução alternativa para esse problema seria usar a transição de protocolo. A autenticação inicial entre o cliente e servidor executando IIS seria manipulada usando o protocolo de autenticação NTLM. Kerberos trataria a autenticação entre o IIS e o servidor de recurso do back-end.

Microsoft Internet Explorer 6 ou posterior

O navegador do cliente pode enfrentar problemas, como recebimento repetido prompts de logon para credenciais ou mensagens de erro "401 acesso negado" do servidor executando o IIS. Descobrimos os dois problemas a seguir, que podem ajudar a resolver esses problemas:

• Verifique Ativar Integrated Windows Authentication selecionada nas propriedades do navegador.Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento:
  299838  (http://support.microsoft.com/kb/299838/ ) Não é possível negociar a autenticação Kerberos após atualizar para Internet Explorer 6
• Se a configuração de segurança reforçada do Internet Explorer é ativada em Adicionar ou remover programas, você deve adicionar um site que usa delegação para a lista de sites confiáveis.Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento:
  815141  (http://support.microsoft.com/kb/815141/ ) Configuração de segurança reforçada do Internet Explorer altera a experiência de navegação

IIS 5.0 e IIS 6.0

Após a atualização do IIS 4.0 para o IIS 5.0 ou IIS 6.0, a delegação pode não funcionar corretamente ou possivelmente alguém ou um aplicativo modificou a propriedade de metabase NTAuthenticationProviders. Para obter mais informações sobre como corrigir esse problema, clique no número abaixo para ler o artigo na Base de dados de Conhecimento:

Uma área específica de problemas pode ocorrer quando você definir o SPN

Determinar o nome do servidor

Determinar se você estiver se conectando ao site usando o nome real do NetBIOS do servidor ou usando um nome de alias, como um nome DNS (por exemplo, www.microsoft.com). Se você estiver acessando o servidor Web usando um nome diferente do nome real do servidor, um nome principal do novo serviço (SPN) deve ter sido registrado usando a ferramenta Setspn do Windows 2000 Server Resource Kit. Porque o serviço de diretório do Active Directory não sabe o nome do serviço, o serviço de concessão de tíquete (TGS) não concede um tíquete para autenticar o usuário. Esse comportamento força o cliente para usar o próximo método de autenticação disponíveis, NTLM, é para renegociar. Se o servidor está respondendo a um nome DNS de www.microsoft.com, mas o servidor de Web for denominada webserver1.development.microsoft.com, você deve registrar www.microsoft.com no Active Directory no servidor que está executando executando IIS. Para fazer isso, você deve baixar a ferramenta Setspn e instalar no servidor que está executando o IIS.

Para obter mais informações sobre como obter a ferramenta Setspn, visite o seguinte site: Se você estiver usando o Windows Server 2003 e IIS 6, a ferramenta Setspn para Microsoft Windows Server 2003 está disponível no seguinte local:Para determinar se você estiver se conectando utilizando o nome real, tente se conectar ao servidor usando o nome real do servidor em vez do nome DNS. Se você não pode se conectar ao servidor, consulte a seção "Verificar o computador é confiável para delegação".

Se você pode se conectar ao servidor, siga estas etapas para definir um SPN para o nome DNS que você está usando para se conectar ao servidor:

1. Instale a ferramenta Setspn.
2. No servidor executando o IIS, abra um prompt de comando e abra a pasta C:\Program programas\Resource Kit.
3. Execute o seguinte comando para adicionar esse novo SPN (www.microsoft.com) para o Active Directory para o servidor:
   Setspn - A HTTP/www.microsoft.com webserver1
   Observação Este comando webserver1 representa o nome NetBIOS do servidor.

Receber saída é semelhante à seguinte:
Para exibir uma listagem de SPNs no servidor para ver esse novo valor, digite o seguinte comando no servidor executando o IIS: Observe que você não tem registrar todos os serviços. Muitos tipos de serviço, como HTTP, W3SVC, WWW, RPC, CIFS (acesso de arquivo), WINS e no-break (UPS) irão mapear para um tipo de serviço padrão que é denominado HOST. Por exemplo, se seu software de cliente usa um SPN de HTTP/webserver1.microsoft.com para criar uma conexão HTTP para o servidor Web no servidor webserver1.microsoft.com, mas esse SPN não está registrado no servidor, o controlador de domínio do Windows 2000 automaticamente mapear a conexão para HOST/webserver1.microsoft.com. Este mapeamento se aplica somente se o serviço da Web está executando sob a conta sistema local.

Verifique se o computador é confiável para delegação

Se este servidor executando o IIS é um membro do domínio, mas não é um controlador de domínio, o computador deve ser confiável para delegação de Kerberos funcione corretamente. Para fazer isso, execute essas etapas:

1. No controlador de domínio, clique em Iniciar, aponte para configurações e clique em Painel de controle.
2. No painel de controle, abra Administrative Tools.
3. Clique duas vezes em Active Directory Users and Computers.
4. Em seu domínio, clique em Computers.
5. Na lista, localize o servidor que executa o IIS, clique com o botão direito do mouse no nome do servidor e clique em Propriedades.
6. Clique na guia Geral, clique para selecionar a caixa de seleção confiável para delegação e clique em OK.

Observe que se vários sites são atingidos por mesmo URL mas em portas diferentes, delegação não funcionará. Para fazer esse trabalho, você deve usar nomes de host diferentes e SPNs diferentes. Quando o Internet Explorer solicita qualquer http://www. mywebsite .com ou http://www. mywebsite .com:81, o Internet Explorer solicita uma permissão para HTTP/www.mywebsite.com SPN. Internet Explorer não adiciona a porta ou o vdir à solicitação SPN. Esse comportamento é o mesmo para http://www. mywebsite .com/app1 ou http://www. mywebsite .com/app2. Nesse cenário, Internet Explorer irá solicitar uma permissão para SPN http://www. mywebsite .com do Centro de distribuição de chaves (KDC). Cada SPN pode ser declarado apenas para uma identidade. Portanto, você também poderia receber uma mensagem de erro KRB_DUPLICATE_SPN se você tentar declarar este SPN para cada identidade.

Microsoft ASP.NET e delegação

Para obter mais informações sobre a configuração para delegar credenciais quando você usar um ASP.NET aplicativo, clique no número abaixo para ler o artigo na Base de dados de Conhecimento: Representação e delegação são dois métodos para um servidor para autenticar em nome do cliente. Decidir qual desses métodos para usar e sua implementação pode causar alguma confusão. Você deve revisar a diferença entre esses dois métodos e examinar que esses métodos, você poderá usar para seu aplicativo. Minha recomendação seria leia o seguinte white paper para obter mais detalhes:

Como sempre, sinta-se à vontade para enviar idéias em tópicos desejados no futuro endereçados colunas ou na Base de dados de Conhecimento usando o formulário Ask For It (http://support.microsoft.com/common/survey.aspx?scid=sw;en;1321) .