Updates are a tricky one, they don't allow you to access the internal API 
when come from a network logon which is why we use become to bypass that 
limitation. Luckily if you are using the win_updates module there is an 
option use_scheduled_task [1] option you can set to not use become but a 
scheduled task to bypass that limitation as well.

[1] 
https://docs.ansible.com/ansible/latest/collections/ansible/windows/win_updates_module.html#parameter-use_scheduled_task
On Tuesday, April 20, 2021 at 1:39:42 AM UTC+10 [email protected] 
wrote:

> Thanks for update, just for my understanding, I am able to reboot servers 
> and search updates while running my domain admin account as runas which has 
> Administrative rights. While installing patches only it is giving the 
> error, when it is logging as Administrator user it should run the tasks 
> right why it need to get as an Administrator again?
>
>
>
> On Monday, April 19, 2021 at 12:55:04 PM UTC+1 [email protected] wrote:
>
>> There isn't unfortunately, your security team should hopefully be aware 
>> that this doesn't prevent Mimikatz attacks just makes it slightly harder. 
>> Once you are an admin it is trivial to give yourself the privileges 
>> necessary for Mimikatz to work (psexec -i -s mimikatz.exe). As for Ansible 
>> there really is no other way without us doing those same things that 
>> malware would do. We opted to make our code simple and require the standard 
>> rights you typically get as an administrator.
>>
>> On Saturday, April 17, 2021 at 1:40:05 AM UTC+10 [email protected] 
>> wrote:
>>
>>> Hi
>>>
>>> Thanks for the update and it is the cause of issue, but Security team 
>>> requested to disable it to prevent Against Mimikatz Attacks. They are not 
>>> willing to enable it, is there any work around to make it work while 
>>> SeDebugPrivilage dsabled, we tried to become user and used runas method 
>>> still same error.
>>>
>>> On Thursday, April 15, 2021 at 10:53:17 PM UTC+1 [email protected] 
>>> wrote:
>>>
>>>> The primary reason for not being able to get the SYSTEM token (required 
>>>> for passwordless become on Windows) is your connection user doesn't have 
>>>> the SeDebugPrivilege. This should be assigned to Admins users by default 
>>>> but sometimes custom environment settings remove this privilege. You can 
>>>> use the win_whoami module to check what privileges you account has, or 
>>>> even 
>>>> just 'win_command: whoami /priv'.
>>>>
>>>> On Friday, April 16, 2021 at 12:15:40 AM UTC+10 [email protected] 
>>>> wrote:
>>>>
>>>>> We are trying to install patches from Ansible on Windows servers and 
>>>>> it used to work fine well, but recently few changes happened from AD or 
>>>>> GPO 
>>>>> which is causing the below error while executing the Windows updates 
>>>>> script 
>>>>> from Ansible.
>>>>>
>>>>> "Failed to get token for NT AUTHORITY\SYSTEM required for become as a 
>>>>> service account or an account without a password" ---> System.Exception: 
>>>>> Failed to get token for NT AUTHORITY\SYSTEM required for become as a 
>>>>> service account or an account without a password
>>>>>
>>>>> "msg": "internal error: failed to become user 'SYSTEM': Exception 
>>>>> calling \"CreateProcessAsUser\" with \"9\" argument(s): \"Failed to get 
>>>>> token for NT AUTHORITY\\SYSTEM required for become as a service account 
>>>>> or 
>>>>> an account without a password\"
>>>>>
>>>>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/ae38342b-1dbf-4a42-8c66-fbcae60fa9adn%40googlegroups.com.

Reply via email to