win_shell, kerberos and credential delegation

[Luca Lorenzetto]

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

[Luca 'remix_tj' Lorenzetto]

Hi,

nobody has knowledge on this topic? It's quite critical to me for
having a deployment workflow completed entirely with ansible.

Luca

> --
> You received this message because you are subscribed to the Google Groups "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/35124e9b-76fe-4e89-829b-e6bfe5de6916%40googlegroups.com.



--
"E' assurdo impiegare gli uomini di intelligenza eccellente per fare
calcoli che potrebbero essere affidati a chiunque se si usassero delle
macchine"
Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)

"Internet è la più grande biblioteca del mondo.
Ma il problema è che i libri sono tutti sparsi sul pavimento"
John Allen Paulos, Matematico (1945-vivente)

Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , <lorenze...@gmail.com>

[Jordan Borean]

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

[Luca 'remix_tj' Lorenzetto]

Hi Jordan,

On Thu, May 14, 2020 at 11:00 PM Jordan Borean <jbor...@gmail.com> wrote:
>
> 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