Delegação de Kerberos para Inserção de SQL em Massa (acesso negado)

Question

Eu tenho um problema ao tentar inserir em massa no SQL na seguinte situação:

• Executando o Management Studio na estação de trabalho A
• SQL em execução no servidor B
• Arquivo para upload em massa localizado no Servidor C

Sempre que tento fazer upload em massa, recebo o erro

Cannot bulk load because the file <filename> could not be opened. Operating system error code 5(Access is denied.).

Agora, estou ciente de que temos uma questão de duplo salto aqui e precisamos resolver a delegação. Os SPNs foram configurados para SQL da seguinte maneira (o SQL está sendo executado em uma porta diferente). O SQL está sendo executado como um usuário de domínio e os SPNs estão nessa conta.

command: setspn -l domain\sqluser

result:
MSSQLSvc/WIN-D04V1IOTESN
MSSQLSvc/WIN-D04V1IOTESN.domain.local
MSSQLSvc/win-d04v1iotesn.domain.local:55037
MSSQLSvc/WIN-D04V1IOTESN:55037

Eu também configurei uma delegação da conta de usuário SQL para o servidor de arquivos para Cifs e HOST, mas sem sucesso.

Eu habilitei o log do Kerberos e estou vendo o seguinte evento no visualizador de eventos:

 A Kerberos Error Message was received:
     on logon session 
     Client Time: 
     Server Time: 14:44:10.0000 8/9/2011 Z
     Error Code: 0xe KDC_ERR_ETYPE_NOTSUPP
     Extended Error: 
     Client Realm: 
     Client Name: 
     Server Realm: domain.LOCAL
     Server Name: krbtgt/domain.LOCAL
     Target Name: krbtgt/[email protected]
     Error Text: 
     File: 9
     Line: efb
     Error Data is in record data.

Então, algum pensamento sobre o que estou sentindo falta aqui? Eu tive esse tipo de delegação trabalhando antes, mas sempre com o SQL na porta padrão, isso poderia ter um impacto?

Editar

Eu também estou vendo este erro do Kerbors ao lado do primeiro:

A Kerberos Error Message was received:
 on logon session 
 Client Time: 
 Server Time: 15:4:10.0000 8/9/2011 Z
 Error Code: 0xe KDC_ERR_ETYPE_NOTSUPP
 Extended Error: 
 Client Realm: 
 Client Name: 
 Server Realm: domain.LOCAL
 Server Name: krbtgt/domain.LOCAL
 Target Name: krbtgt/[email protected]
 Error Text: 
 File: 9
 Line: efb
 Error Data is in record data.

    

Answer 1

Nos comentários, você está se conectando ao SQL usando um login de domínio para que o SQL tente se passar por você ao se conectar ao compartilhamento de arquivos. Se você não tiver a delegação configurada para isso em sua conta de domínio, ela falhará.

Ao executar o procedimento armazenado conectado como um login SQL, o SQL tentará usar a conta de serviço de domínio em execução, para a qual você diz que já configurou a delegação.

Se você conectar sua janela de consulta usando a conta de serviço do domínio, o SQL estará sendo executado, já que deve funcionar, já que a delegação já está configurada. Configure uma confiança de delegação no servidor de arquivos para sua própria conta de domínio e ela deverá começar a funcionar.

    

Answer 2

O SPN parece correto para o SQL Server. Os SPNs corretos estão registrados para o servidor de arquivos?

A outra coisa que pode atrapalhar a autenticação do kerberos no SQL Server são os problemas de DNS. Eu li em algum lugar que o cliente sql fará uma pesquisa inversa de DNS no endereço do servidor e usar esse nome para formar o SPN.

Eu sei que você já fez muitas dessas etapas, mas isso deve ser tudo o que você precisa fazer.
Certifique-se de que a resolução de DNS esteja funcionando corretamente para o servidor SQL e o servidor de arquivos. Registre os SPN's para o SQL Server. Assegure-se de que não haja SPNs duplicados. setspn no SQL 2008 pode fazer essa verificação para você.
Registre os SPNs para o servidor de arquivos. Verifique se não há duplicatas.
Habilite "confiável para delegação" na conta de serviço do SQL Server.
Além disso, verifique se sua conta não está marcada como não contagiante. (isso é uma palavra?)

Se você não conseguir fazê-lo funcionar, poderá configurar um trabalho do SQL Agent para remover a inserção em massa. Em seguida, ele será executado na conta que você configura o trabalho para ser executado como.

    

Answer 3

A falta de tempo do cliente em sua mensagem de erro me faz suspeitar. A autenticação Kerberos falhará se a hora no cliente e a hora no servidor forem muito diferentes. (Eu nunca tive certeza do que "muito diferente" realmente é. Eu sei que um minuto pode fazer isso porque nós tivemos esse problema (novamente) ontem com um novo servidor.)

Quando a autenticação do kerberos falha, o SSMS provavelmente ainda se conectará, mas voltará silenciosamente a usar a autenticação NTLM.

Você pode forçar o kerberos, ajustando as configurações de conexão e seqüências de caracteres, para que uma conexão falhe com dificuldade se a autenticação do kerberos, mas há uma maneira mais fácil de ver se você está se conectando com o Kerberos. Para garantir que você esteja conectado usando a autenticação Kerberos, conecte-se normalmente via SSMS e execute-o em uma janela de consulta do SSMS:

selecione auth_scheme em master.sys.dm_exec_connections, em que session_id = @@ spid

Você deve ver "KERBEROS". Se você não o fizer, provavelmente verá "NTLM" e saberá que algo está errado.