# win\_shell, kerberos and credential delegation **URL:** \ **Category:** Ansible Project\ **Tags:** windows\ **Created:** [May 13, 2020, 12:42pm UTC](https://forum.ansible.com/t/win-shell-kerberos-and-credential-delegation/32922 "2020-05-13T12:42:43Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Luca\_remix\_tj\_Lorenz](https://avatars.discourse-cdn.com/v4/letter/l/ea666f/32.png) [@Luca\_remix\_tj\_Lorenz](https://forum.ansible.com/u/Luca_remix_tj_Lorenz)\ **Post date:** [May 13, 2020, 12:42pm UTC](https://forum.ansible.com/t/win-shell-kerberos-and-credential-delegation/32922/1 "2020-05-13T12:42:43Z")
Hello, i’m hitting an issue with windows authentication and credential delegation. That’s the piece of playbook that has problem with privileges: - name: define migrator command set\_fact: migratore\_command: “{{ backup\_path }}\Migrator\DB.Migrator.exe -s -connstring "Server=application-listener.dev\applications,64000; Database=USERAPPDB; User Id=USERAPP; Integrated Security=True;"” - name: Execute migrator win\_shell: “{{ migrator\_command }}” args: chdir: “{{ backup\_path }}\Migrator” register: migrator failed\_when: migrator.rc != 6 run\_once: true I’m connecting to the windows machine where DB.Migrator.exe is via winrm authenticated through kerberos. Authentication works fine, because tasks before this are working perfectly (copy, remove file, other win\_shell, unarchive, etc). this DB.Migrator is a tool that uses my own credentials to connect to a remote MSSQL application listener via integrated security and then updates some data on that DB. I’m hitting this error (returned by stdout of execution): System.Data.SqlClient.SqlException (0x80131904): Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’ On my inventory file i’ve set this parameters: ansible\_port=5986 ansible\_connection=winrm ansible\_winrm\_server\_cert\_validation=ignore ansible\_winrm\_transport=kerberos ansible\_winrm\_kerberos\_delegation=true What i’m expecting is that with kerberos\_delegation, the application will connect using the ansible\_user, not anonymous logon. What is wrong? Is possible to use become: to use a given user to run this task, using the right permissions? Thanks, Luca ---
**Author:** ![Luca\_remix\_tj\_Lorenz](https://avatars.discourse-cdn.com/v4/letter/l/ea666f/32.png) [@Luca\_remix\_tj\_Lorenz](https://forum.ansible.com/u/Luca_remix_tj_Lorenz)\ **Post date:** [May 14, 2020, 1:56pm UTC](https://forum.ansible.com/t/win-shell-kerberos-and-credential-delegation/32922/2 "2020-05-14T13:56:55Z")
Hi, nobody has knowledge on this topic? It's quite critical to me for having a deployment workflow completed entirely with ansible. Luca ---
**Author:** ![jborean](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jborean/32/1525_2.png) [@jborean](https://forum.ansible.com/u/jborean)\ **Post date:** [May 14, 2020, 9:00pm UTC](https://forum.ansible.com/t/win-shell-kerberos-and-credential-delegation/32922/3 "2020-05-14T21:00:22Z")
It really depends on how the ‘DB.Migrator.exe’ binary is set to use credentials over a network path. If it’s trying to find a credential in the user’s DPAPI cred store then Kerberos with credential delegation is not enough to unlock it. Your options for this case are either: - Use become on the task with the connection user credentials - Use credssp as the transport I would also suggest you use win\_command and not win\_shell for this task. The latter is only really useful if you want shell-isms, to run a binary win\_command is usually enough for you. My personal preference here is to use become as that will do more than just fix credential delegation, it runs the task in a similar security context as to how it is run interactively. Here is the task as I would write it with become ` - name: Execute migrator win\_command: \> “{{ backup\_path}}\Migrator\DB.Migrator.exe” -s -connstring “Server=application-listener.dev\applications,64000; Database=USERAPPDB; User ID=USERAPP; Integrated Security=True;” args: chdir: ‘{{ backup\_path }}\Migrator’ become: yes become\_method: runas vars: ansible\_become\_user: ‘{{ ansible\_user }}’ ansible\_become\_pass: ‘{{ ansible\_password }}’ register: migrator failed\_when: migrator.rc != 6 run\_once: true ` A few things I’ve changed - I’ve done away with the set\_fact task as it shouldn’t be needed - Used win\_command instead of win\_shell, the latter shouldn’t be needed for your task - Using a yaml multiline syntax ‘\>’ that turns newlines into spaces so the task line isn’t too long - Use a double quote for the executable argument. Because it’s in a yaml multilines string you don’t need to escape that or backslashes making the command line more representative of what will run - Use single quotes for quoting YAML values like you need for chdir, no need to escape double quotes - Added the become vars to run with become Thanks Jordan ---
**Author:** ![Luca\_remix\_tj\_Lorenz](https://avatars.discourse-cdn.com/v4/letter/l/ea666f/32.png) [@Luca\_remix\_tj\_Lorenz](https://forum.ansible.com/u/Luca_remix_tj_Lorenz)\ **Post date:** [June 17, 2020, 10:36am UTC](https://forum.ansible.com/t/win-shell-kerberos-and-credential-delegation/32922/4 "2020-06-17T10:36:51Z")
Hi Jordan, > It really depends on how the 'DB.Migrator.exe' binary is set to use credentials over a network path. If it's trying to find a credential in the user's DPAPI cred store then Kerberos with credential delegation is not enough to unlock it. Your options for this case are either: > > Use become on the task with the connection user credentials > Use credssp as the transport [cut] I've used become, with become method runas, with kerberos and the result has been perfect, credential delegation has worked > I would also suggest you use win\_command and not win\_shell for this task. The latter is only really useful if you want shell-isms, to run a binary win\_command is usually enough for you. My personal preference here is to use become as that will do more than just fix credential delegation, it runs the task in a similar security context as to how it is run interactively. [cut] > A few things I've changed > > I've done away with the set\_fact task as it shouldn't be needed > Used win\_command instead of win\_shell, the latter shouldn't be needed for your task > Using a yaml multiline syntax '\>' that turns newlines into spaces so the task line isn't too long > Use a double quote for the executable argument. Because it's in a yaml multilines string you don't need to escape that or backslashes making the command line more representative of what will run > Use single quotes for quoting YAML values like you need for chdir, no need to escape double quotes The changes you suggested have been precious, because solved also escaping issues i've been having! The task has been performed successfully, with the right user. Luca