Verificando o evento de Error para obter maiores detalhes:

Após fazer uma pesquisa encontrei um post que explica essa situação.

Aparentemente, a conta que está levantando o SQL Server e está executando o pakage do DTS não está tendo acesso ao diretório necessário. Para corrigir isso fazer o seguinte:

1. Abrir o SQL Server Management Studio
2. Conectar a seu servidor
3. Expandir Management->Legacy->Data Transformation Services
4. Botão direito em  ‘Microsoft Forefront Client Security’ e escolher ‘Open’
5. Clicar no menu ‘Package’ e escolher ‘Properties’
6. Navegar até a aba ‘Global Variables’ e verificar o valor do campo ‘ScriptFileDirectory’.
7. Agora abra este diretório usando o Windows Explorer e atribua direitos de leitura e gravação para a conta que esta subindo os serviços do SQL Server (no meu caso o NETWORK SERVICE) neste diretório
8. Pronto, o problema esta corrigido.
9. Para forçar a execução da tarefa, volte ao SQL Server Management Studio
10. Expandir SQL Server  Agent -> Jobs
11. Clicar com o botão direito em Microsoft Forefront Client Security e escolher Start Job at Step

Não estava sendo possível fazer logon utilizando a autenticação do Windows (Windows Autentication) no SQL.

A princípio, parecia ser problema de permissões. No caso em questão, o grupo DOMINIO\Domain Admins estava configurado no SQL com o role de SysAdmin, entretanto, mesmo logando com uma conta de domínio que faz parte deste equipamento, não estava sendo possível se autenticar.

Fui verificar nos logs do windows e o seguinte evento me chamou a atenção:

Login failed for user ‘DOMAIN\admin’. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: <local machine>]

Após uma busca na internet, encontrei um artigo que indicava que o problema poderia ser ocasionado pelo UAC (User Account Control) do Windows 2008 R2. Fui no painel de controle e desabilitei o UAC deste equipamento. Após reiniciar ele, o problema foi resolvido.

Aparentemente, com o recurso do UAC ativado, o windows não consegue “encaminhar” para o SQL Server todo o Membership da conta utilizada. No caso, o SQL sabia que o grupo DOMAIN\Domain Admins era SysAdmin do SQL, porém ele não conseguia identificar que a conta DOMAIN\admin fazia parte deste grupo. Ao meu ver, esse comportamento é muito estranho, principalmente em se tratando de dois produtos da Microsoft.

Uma outra alternatia seria dar permissões diretamente para a conta DOMAIN\admin no SQL Server, apesar desta não ser uma boa prática de segurança.