Executando um pacote SSIS de propriedade de um usuário de domínio do SQL Server em execução em uma conta de serviço local


10

Quero executar um pacote SSIS contendo tarefas Transferir objetos do SQL Server. Os servidores envolvidos estão no mesmo domínio, mas os serviços do SQL Server estão em execução nas contas de serviço local. Portanto, o ambiente fica assim:

Domínio

Servidor1

  • SQL Server em execução na conta local
  • No sistema de arquivos: pacote SSIS
  • No SQL Server Agent: um trabalho

Servidor 2

  • SQL Server em execução na conta local

Para poder fazer logon nos dois servidores, criei uma conta de domínio para ser usada como conta de serviço. Quando uso essa conta de domínio para fazer logon no Servidor 1 e, em seguida, executar o pacote no sistema de arquivos, todas as etapas são bem-sucedidas. No entanto, quando tento adicionar o trabalho ao SQL Server, encontro um dos seguintes problemas:

Situação 1. Proprietário do trabalho: conta local; execute a etapa do SSIS como proxy para a conta do domínio . Quando defino o proprietário da tarefa como uma conta local, mas a executo como proxy da conta do domínio, a tarefa será executada com êxito, mas o pacote gerará erros como

A execução falhou com o seguinte erro: "O diretório 'LocalApplicationData' não existe.".

Esse erro pode ser corrigido através da criação de um logon com direitos de administrador para o usuário do domínio no Servidor 1, mas obviamente essa não é uma solução desejável. Adicionar a conta a um dos grupos de agentes / DTS do SQL Server também não funciona.

Situação 2. Proprietário do trabalho: conta de domínio; execute a etapa do SSIS como um proxy para a conta do domínio . Quando defino o proprietário do trabalho e o 'executar como usuário' para a etapa da conta de domínio, o trabalho não inicia, com o seguinte erro:

Não foi possível determinar se o proprietário (domínio \ usuário do domínio) do trabalho Job nametem acesso ao servidor (motivo: não foi possível obter informações sobre o grupo / usuário do Windows NT 'Usuário do domínio \ domínio', código de erro 0x5. [SQLSTATE 42000] (Erro 15404)) .

Acredito que o último erro ocorre porque o SQL Server é executado em uma conta local e, portanto, não pode verificar quais contas de domínio de direitos possuem.

Qual é o caminho certo para executar o trabalho? A situação 2 parece mais limpa para mim, mas parece impossível porque o SQL Server é executado em uma conta local. A situação 1 também funcionaria, mas não será possível conceder direitos administrativos a um usuário de domínio no meu SQL Server.


ATUALIZAR:

@ JonSeigel e @ Mr.Brownstone:

Parece plausível que esse problema ocorra devido à falta de permissões. No entanto, o erro é sobre a inexistência de 'LocalApplicationData' - uma das pastas geradas para cada conta. Já efetuei login no servidor com as credenciais sob as quais o pacote é executado (criando um diretório de perfil) e tentei várias combinações de permissões para o diretório de perfil. Mesmo ao conceder manualmente quase todas as permissões nesse diretório específico, recebo o erro mencionado acima.

Enquanto fazia mais pesquisas, encontrei um tópico no fórum em http://www.sqlservercentral.com/Forums/Topic391332-148-1.aspx#bm391441, que é bastante semelhante - embora sem solução.


Existe uma razão para você não estar usando uma conta de domínio para serviços SQL?
Eric Higgins

Sim, mas não sei qual motivo (acho que algo com o ciclo DTAP e o domínio não está disponível em todos os lugares). Enfim, é um ambiente que eu não tenho permissão para alterar.
vstrien

A situação 1 parece ser a resposta. Eu acho que a mensagem de erro que você está recebendo é do pacote. Em outras palavras, o pacote está em execução, mas uma tarefa dentro dele requer mais permissões do que a conta de serviço foi concedida. Talvez você não precise conceder permissões em nível de administrador à conta para obter êxito (conceda permissões granulares ou altere o processo para não precisar das permissões).
21412 Jon Seigel

Você pode adicionar logons do SQL (autenticação SQL) ao SQL Server remoto (servidor 2)? Se você tiver essa opção, poderá usar o Logon do SQL na conexão SSIS usada para o destino. Isso significa que você precisará usar uma senha para criptografar o pacote, mas isso resolverá o seu problema.
precisa saber é o seguinte

@Justicator: Talvez, como último recurso. Mas sempre que possíveis logins de domínio, prefiro não usar a autenticação SQL.
vstrien

Respostas:


5

Minha opinião pessoal é que a opção 1 é o caminho a percorrer. Mas não vejo necessidade de conceder acesso de administrador local à conta do domínio. Parece-me que ele requer acesso a determinadas pastas e arquivos e, portanto, você pode conceder ao usuário do domínio acesso apenas aos recursos necessários para executar o pacote com êxito. Isso pode ser feito através da caixa de diálogo de propriedades de arquivo / pasta e selecione a guia segurança - não será necessário defini-lo para todos os arquivos e pastas, pois você pode definir as permissões do diretório pai e configurá-las para substituir as propriedades filho.

Espero que isso ajude você.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.