Registrando nomes da entidade de serviço Kerberos usando Http.sys
Os Serviços Web de XML nativos foram preteridos. Esse recurso será removido em uma versão futura do Microsoft SQL Server. Evite usar esse recurso em desenvolvimentos novos e planeje modificar os aplicativos que atualmente o utilizam.
Ao criar ou modificar pontos de extremidade HTTP usando CREATE ENDPOINT ou ALTER ENDPOINT, você especifica o tipo de autenticação usado para autenticar os usuários que estão enviando uma solicitação SOAP HTTP para o ponto de extremidade. Para obter mais informações, consulte CREATE ENDPOINT (Transact-SQL) e ALTER ENDPOINT (Transact-SQL).
Usando CREATE ENDPOINT ALTER ENDPOINT, é possível configurar pontos de extremidade para oferecer suporte à autenticação Kerberos destas formas:
Definindo AUTHENTICATION=KERBEROS, Kerberos é usado como o único meio de autenticação HTTP
Quando AUTHENTICATION=INTEGRATED, a autenticação HTTP do ponto de extremidade pode oferecer as seguintes opções como parte do desafio de autenticação: NEGOTIATE, KERBEROS e NTLM. Para a opção NEGOTIATE, o cliente e o servidor tentam estabelecer uma autenticação baseada em Kerberos. Se o cliente não oferecer suporte a Kerberos ou a negociação não for possível, a autenticação retornará a NTLM. Para impedir que o cliente retorne a NTLM quando você usar NEGOTIATE, recomendamos que o cliente defina AUTHENTICATION=KERBEROS no ponto de extremidade.
Para dar suporte à autenticação mútua em Kerberos, uma instância do SQL Server deve associar um SPN (nome da entidade de serviço) à conta em que será executada como, por exemplo, a conta Sistema Local ou de usuário do domínio. Os detalhes específicos do registro SPN feito pela instância específica do SQL Server são determinados pelo tipo de conta de serviço em que ela foi configurada. Caso o SQL Server esteja em execução na conta Sistema Local ou na conta do serviço de rede, os SPNs devem ser registrados no nome do computador. Caso o SQL Server esteja em execução em uma conta de usuário do domínio, os SPNs devem ser registrados no nome de usuário do domínio.
Usando SetSPN.exe
Para habilitar a associação de um SPN com a conta em que a instância do SQL Server está em execução, use a ferramenta de suporte SetSPN.exe do Windows. Essa ferramenta adiciona o SPN do nome do computador no qual a instância do SQL Server está em execução na conta de usuário de serviço do domínio do Windows no Active Directory. Nesse cenário, a ferramenta SetSPN.exe pode ser usada para adicionar dois SPNs: um do nome do NetBIOS e outro no nome DNS totalmente qualificado.
Por exemplo, caso a ferramenta SetSPN.exe seja executada na instância do SQL Server em execução em MyComputer, estes dois SPNs são associados à conta na qual a instância do SQL Server está em execução e devem ser adicionados ao diretório:
HTTP/MyComputer;
HTTP/MyComputer.fully.qualified.domain.name.com
Observe que uma única conta pode ter vários SPNs, mas apenas um SPN pode ser registrado em uma conta.
Para excluir os mesmos dois nomes SPN, tanto NetBIOS quanto DNS totalmente qualificado, também use SetSPN.exe.
Considerações
Semelhante a Httpcfg.exe, SetSPN.exe está disponível no Windows Server 2003 e é instalado quando você usa o mesmo procedimento para instalar Httpcfg.exe e as demais Ferramentas de Suporte do Windows. Para obter mais informações, consulte Configurando o driver do modo kernel HTTP (Http.sys).
Caso uma instância do SQL Server não esteja em execução como sendo a conta Sistema Local, apenas os usuários integrados com privilégios DOMAIN ADMIN podem alterar o registro SPN usando a ferramenta SetSPN.exe.
Caso uma instância do SQL Server esteja em execução como sendo a conta Sistema Local, apenas os membros da função de servidor fixa SQL Serversysadmin podem alterar os registros SPN usando a ferramenta SetSPN.exe.
Caso a conta de serviço seja Sistema Local, o SPN é adicionado na conta do Active Directory do computador sem que seja preciso usar a ferramenta SetSPN.exe.
Sintaxe de SetSPN.exe
A sintaxe de SetSPN.exe é:
setspn { -ASPN | -DSPN | -L } service_account
Argumentos
-A
Adiciona o SPN especificado à conta.-D
Exclui o SPN especificado para a conta.-L
Lista todos os SPNs registrados para a conta.
Exemplos
Caso uma instância do SQL Server esteja em execução como um usuário do domínio (MyDomain\MySQLAccount) em um computador chamado MySQLHost, os seguintes comandos podem ser usados para definir os SPNs apropriados:
setspn –A http/MySQLHost MyDomain\MySQLAccount
setspn –A http/MySqlHost.Mydomain.Mycorp.com MyDomain\MySQLAccount
Observe que uma conta pode ter vários SPNs (um para cada serviço ou nome de host), mas um SPN pode ser registrado em apenas uma conta. Contar com o mesmo SPN registrado em várias contas faz com que a autenticação Kerberos falhe.
Por exemplo, a conta MyDomain\MySQLAccount pode ter estes SPNs diferentes registrados. Os dois primeiros comandos se destinam a dois serviços diferentes (http e rpc). O último se destina a um nome de host diferente, supondo que o computador tenha vários nomes de host.
setspn –A http/MySQLHost MyDomain\MySQLAccount
setspn –A rpc/MySQLHost MyDomain\MySQLAccount
setspn –A http/MySecondHost MyDomain\MySQLAccount
Por outro lado, o seguinte cenário causará uma falha em Kerberos:
setspn –A http/MySQLHost MyDomain\MySQLAccountOne
setspn –A http/MySQLHost MyDomain\MySQLAccountTwo
Ocorre uma falha porque há duas instâncias do SQL Server em um computador em execução em duas contas de serviço diferentes (MySQLAccountOne e MySQLAccountTwo). Não há suporte para o cenário de registro de ambos os SPNs, um para cada instância do SQL Server.
Isso tem implicações quando há várias instâncias do SQL Server executadas no mesmo computador, mas em contas diferentes. O SPN só pode ser registrado para uma conta. Caso você precise que várias instâncias do SQL Server (por exemplo, Inst1 e Inst2) coexistam com outros aplicativos (como, por exemplo, o IIS) e queira usar a autenticação Kerberos HTTP em todos os serviços, use uma das seguintes opções para resolver conflitos de registro SPN:
Todas as instâncias e os aplicativos são executados na mesma conta.
Por exemplo, Inst1, Inst2 e IIS são todos executados como LocalSystem ou Mydomain\MyServiceAccount.
Registre vários nomes de host para o mesmo computador e faça com que cada instância e aplicativo escute outro host. Para isso, nesse caso, você teria que fazer o seguinte:
Crie três nomes de host diferentes para o computador.
Atribua cada host a um aplicativo diferente.
Registre três conjuntos de SPNs, um para cada combinação nome de host/aplicativo.
Solucionando problemas de registro SPN do Kerberos
Os problemas mais comuns no registro SPN do Kerberos são os seguintes:
Um SPN não é registrado.
Quando um SPN não for registrado, a autenticação Kerberos funcionará no computador local em que a instância do SQL Server está em execução, mas falhará nos computadores do cliente remoto.
Um SPN é registrado mais de uma vez.
Há vários cenários em que um administrador pode duplicar os SPNs no diretório do domínio, o que causará uma falha na autenticação Kerberos. Entre eles estão:
Fazer alterações na conta do domínio em que a instância do SQL Server é executada
Se SetSpn.exe for executado enquanto uma instância do SQL Server estiver em execução como uma conta de domínio como, por exemplo, DOMAIN\User1, e essa conta de domínio usada para executar o SQL Server for alterada como DOMAIN\User2, quando for executado novamente, SetSPN.exe fará com que o mesmo SPN seja inserido no diretório em ambas as contas.
Instalar várias instâncias do SQL Server executadas em contas diferentes
Se você instalar várias instâncias do SQL Server e executar cada uma delas em uma conta diferente, se SetSpn.exe for executado em todas elas, haverá contas duplicadas no diretório de cada conta de serviço do SQL Server. Isso se aplica a ambas as instâncias em execução em um usuário do domínio, além da conta Sistema Local.
Remover e reinstalar uma instância do SQL Server em uma conta diferente
Se você instalar o SQL Server em uma conta, registrar os SPNs, remover e reinstalar o SQL Server em uma conta diferente e, em seguida, registrar novamente os SPNs, cada conta de domínio terá os mesmos SPNs. Isso significa que os SPNs serão duplicados.
Em cada um desses cenários, o problema é que o ponto de extremidade HTTP retornará à autenticação NTLM até que o problema seja resolvido. Isso normalmente envolve pesquisar o diretório em busca de SPNs duplicados ou obsoletos e removê-los manualmente.