"Access denied" error when running win_updates module on Windows vSphere hosts

[krustwell (Jerry)]

ansible [core 2.13.7] on Rocky Linux 8.9 connecting to/configuring Windows Server 2022 Standard

I have a pretty boring playbook:

- name: Search security updates
  ansible.windows.win_updates:
    category_names:
      - SecurityUpdates
    state: searched
    log_path: D:\logs\ansible_wu.txt

It errors with the following:

The full traceback is:
Exception calling "NativeCreateProcess" with "9" argument(s): "CreateProcessW() failed (Access is denied, Win32ErrorCode 5 - 0x00000005)"
At line:2182 char:24
+ ...  $taskPid = Invoke-InProcess @invokeSplat -ParentProcessId $parentPid ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Invoke-InProcess], MethodInvocationException
    + FullyQualifiedErrorId : Win32Exception,Invoke-InProcess

ScriptStackTrace:
at Invoke-InProcess, <No file>: line 490
at <ScriptBlock>, <No file>: line 2182
fatal: [SERVERNAME]: FAILED! => {
    "changed": false,
    "failed_update_count": 0,
    "filtered_updates": {},
    "found_update_count": 0,
    "installed_update_count": 0,
    "invocation": {
        "module_args": {
            "accept_list": null,
            "category_names": [
                "SecurityUpdates"
            ],
            "log_path": "D:\\logs\\ansible_wu.txt",
            "reboot": false,
            "reboot_timeout": 1200,
            "reject_list": null,
            "server_selection": "default",
            "skip_optional": false,
            "state": "searched"
        }
    },
    "msg": "Failed to start new win_updates task with Task Scheduler: Exception calling \"NativeCreateProcess\" with \"9\" argument(s): \"CreateProcessW() failed (Access is denied, Win32ErrorCode 5 - 0x00000005)\"",
    "updates": {}
}

Ansible can successfully connect to the server with win_ping, win_service_info, etc.

Thank you in advance, and please let me know what other information I can provide.

[Denney-tech (Caleb Denney)]

Looks like you need to use become to elevate your privileges, since that is a Windows permission error.

Edit: welcome to the forum by the way, saw your comment over in Social Space .

Since you seem to be new to ansible, please review the documentation for become which can be found here:
Understanding privilege escalation: become — Ansible Community Documentation

You can use win_whoami to see your user’s privileges, and make a debug playbook to test your user with and without become set.

- hosts: windows
  gather_facts: true
  become_method: runas
  become_flags: logon_type=interactive
  become_user: "DOMAIN\Admin_user"
  tasks:
    - name: unprivileged
      win_whoami:
    - name: privileged
      win_whoami:
      become: true

Once you have become working, you should be able to run the windows updates task with sufficient privileges.

[krustwell (Jerry)]

Thanks for the response.

I’m running the playbook as a domain service account with Administrator privileges. When I run win_whoami (which I had previously done to verify permissions), it came back with seemingly everything it needs, hence my frustration:

    "privileges": {
        "SeBackupPrivilege": "enabled-by-default",
        "SeChangeNotifyPrivilege": "enabled-by-default",
        "SeCreateGlobalPrivilege": "enabled-by-default",
        "SeCreatePagefilePrivilege": "enabled-by-default",
        "SeCreateSymbolicLinkPrivilege": "enabled-by-default",
        "SeDebugPrivilege": "enabled-by-default",
        "SeDelegateSessionUserImpersonatePrivilege": "enabled-by-default",
        "SeImpersonatePrivilege": "enabled-by-default",
        "SeIncreaseBasePriorityPrivilege": "enabled-by-default",
        "SeIncreaseQuotaPrivilege": "enabled-by-default",
        "SeIncreaseWorkingSetPrivilege": "enabled-by-default",
        "SeLoadDriverPrivilege": "enabled-by-default",
        "SeManageVolumePrivilege": "enabled-by-default",
        "SeProfileSingleProcessPrivilege": "enabled-by-default",
        "SeRemoteShutdownPrivilege": "enabled-by-default",
        "SeRestorePrivilege": "enabled-by-default",
        "SeSecurityPrivilege": "enabled-by-default",
        "SeShutdownPrivilege": "enabled-by-default",
        "SeSystemEnvironmentPrivilege": "enabled-by-default",
        "SeSystemProfilePrivilege": "enabled-by-default",
        "SeSystemtimePrivilege": "enabled-by-default",
        "SeTakeOwnershipPrivilege": "enabled-by-default",
        "SeTimeZonePrivilege": "enabled-by-default",
        "SeUndockPrivilege": "enabled-by-default"
    },
    "rights": [
        "SeInteractiveLogonRight",
        "SeNetworkLogonRight",
        "SeBatchLogonRight",
        "SeRemoteInteractiveLogonRight"
    ],
    "token_type": "TokenPrimary",
    "upn": "",
    "user_flags": []
}

Speaking of documentation, this is something I found a while back:

On Windows, you cannot connect with an underprivileged account and use become to elevate your rights. Become can only be used if your connection account is already an Administrator of the target host.

The win_updates documentation mentions this:

  become: true
  become_method: runas
  become_user: SYSTEM

which I just tried, resulting in the same error.

[Denney-tech (Caleb Denney)]

Sorry, apparently this is a broader and known issue that @jborean has yet been unable to replicate to try and find a fix.

win_update failed since ansible 7.7.0 · Issue #593 · ansible-collections/ansible.windows (github.com)

Issue on running ansible.windows.win_updates module · Issue #540 · ansible-collections/ansible.windows (github.com)

[Denney-tech (Caleb Denney)]

Looks like you might have some success if you use switch from the winrm connection plugin to the psrp plugin, but I’m sure Jordan would appreciate some feedback if you’re in a position to dig further into it. I’m wondering if there’s a Security Policy applied by GPO that might affect how privilege escalation impacts the winrm plugin vs the prsp one.

[krustwell (Jerry)]

I’m going to try the psrp route and update the thread. And if I can provide any info to Jordan, I certainly will try.

Thanks for your help.

[krustwell (Jerry)]

Wow, i changed my host file:

#ansible_connection=winrm
ansible_connection=psrp

And it worked. Such a simple fix to a problem that’s been vexing me for several days.

Thank you again!

[jborean (Jordan Borean)]

If you have any more info on the host setup that you might think is relevant it would be great to post on one of those issues. I would really love to find the underlying problem but my hands are tied in that I cannot replicate and thus cannot see what the underlying problem is.

[krustwell (Jerry)]

Just to muddy the waters a bit:

The issue I reported was happening when I ran the playbook from the command line on one of our Jenkins nodes. Changing the protocol from winrm to psrp in my inventory fixed that. I then put the job in our Jenkins UI, at which point it failed repeatedly saying pypsrp dependencies were missing. I changed the Jenkins job back to winrm and now THAT works.

I’m happy to supply any requested information, provided I have the time, know how, etc.