Ansible playbook, what is the proper syntax to run a powershell script with a specific (domain) user, in an elevated mode?

Question

running Ansible 2.4.2 in an offline environment, using kerberos to authenticate,

Via an ansible playbook, what is the proper syntax to run a powershell script with a specific (domain) user: DOMAIN\someuser, in an elevated mode?

By elevated mode I mean that in the Windows interface, I'd run the script by login in as DOMAIN\someuser , then by right clicking a cmd or powershell prompt shortcut, choosing "run as administrator". This of course does not mean I can run the script with the local user: "administrator".

What I want to run is:

powershell.exe -executionpolicy bypass -noninteractive -nologo -file "myscript.ps1" 

What I tried in a become.yml:

- name: sigh
  win_command: powershell.exe -executionpolicy bypass -noninteractive -nologo -file "myscript.ps1" 
  become: yes
  become_user: DOMAIN\someuser
  become_password: someuserpassword
  become_method: runas

The script runs, with errors that relate to it not running in elevation. Tried the same with win_shell and raw. Tried without the become_user and become_password (the yml runs with the [email protected] user and password so I don't really know if it's required for become).

I'm dragging through this and finding no reference to a solution via become: http://docs.ansible.com/ansible/latest/become.html

Any ideas?

Catanddog

Answer 1

I did the following to get it working in my playbook:

- name: Run ps1 script in privileged mode
  hosts: "{{ my_hosts }}"
  become_method: runas

  vars:
    ansible_become_password: mysupersecretpasswrod

  tasks:
    - win_shell: '.\myscript.ps1'
      become: yes
      become_user: Administrator

Sabotage

Seems to work on an external setup. I'm running into errors in the internal one, not sure if they're powershell related or caused by the elevation issue. Will try again this week. Thanks! – Catanddog

This seems to work, with the domain user and all, for the purpose of elevation (run as administrator) but I'm running into sharepoint issues ("cannot access the local farm) so I'll keep using PSEXEC , run from win_psexec. Marking this as the correct answer to my question, but the PSExec solution below solves a possible interactivity problem. Bottom line, for my specific issue/s the PSExec with win_psexec is the better option. Cheers! – Catanddog

@Nahshonpaz can you share the psexe command please ? – Nibble

Answer 2

I've used PsExec before to run tasks as a specific windows domain user for software installs that require the profile to be loaded. You could also use it to impersonate an elevated user on the remote system to run a powershell script.

This is not my first choice but I've also had issues getting become working on windows hosts.

- name: Copy PsExec
  win_copy:
    src: "files/PsExec.exe"
    dest: "c:\\temp\\psexec.exe"
    force: no

- name: Run powershell as a specific domain user
  win_psexec:
    command: "powershell.exe -executionpolicy bypass -noninteractive -nologo -file 'myscript.ps1'"
    executable: C:\temp\psexec.exe
    elevated: yes
    nobanner: yes
    username: "{{ dom_username }}"
    password: "{{ dev_password }}"
    interactive: yes

Aprylapse

I've used PSExec with scheduled tasks to gain elevation thus far. Your method might remove the need for scheduled tasks but I'd rather be done with PSExec altogether. – Catanddog

Well, this doesn't remove the need for PSEXEC but removes the need for scheduled tasks. I'm running into sharepoint issues with the runas solution so I'll keep using PSEXEC , run from win_psexec – Catanddog