Понимание повышения привилегий: become

Ansible использует существующие системы повышения привилегий для выполнения задач с правами root или с правами другого пользователя. Поскольку эта функция позволяет вам «стать» другим пользователем, отличным от пользователя, вошедшего в систему (удаленный пользователь), мы называем её become. Ключевое слово become использует существующие инструменты повышения привилегий, такие как sudo, su, pfexec, doas, pbrun, dzdo, ksu, runas, machinectl и другие.

• Использование become

  • Директивы become
  • Переменные подключения become
  • Опции become в командной строке

• Риски и ограничения become

  • Риски повышения привилегий до непривилегированного пользователя
  • Не поддерживается всеми плагинами подключения
  • Только один метод может быть включен на один хост
  • Повышение привилегий должно быть общим
  • Невозможно получить доступ к переменным среды, заполненным pamd_systemd

• Become и автоматизация сетей

  • Установка режима включения для всех задач

    • Пароли для режима включения
  • authorize и auth_pass

• Become и Windows

  • Права администратора
  • Локальные учетные записи служб
  • Become без указания пароля
  • Учетные записи без пароля
  • Флаги become для Windows
  • Ограничения become в Windows

Использование become

Вы можете управлять использованием become с помощью директивы play или task, переменных подключения или в командной строке. Если вы задаёте свойства повышения привилегий несколькими способами, ознакомьтесь с общими правилами приоритета, чтобы понять, какие настройки будут использоваться.

Полный список всех плагинов become, включенных в Ansible, можно найти в списке плагинов.

Директивы become

Вы можете задать директивы, которые контролируют become на уровне play или task. Вы можете переопределить эти параметры, задав переменные подключения, которые часто отличаются от одного хоста к другому. Эти переменные и директивы независимы. Например, установка become_user не устанавливает become.

become

устанавливается в yes для активации повышения привилегий.

become_user

устанавливается в пользователя с требуемыми привилегиями — пользователя, в которого вы become, а НЕ пользователя, с которым вы вошли в систему. Не подразумевает become: yes, чтобы его можно было установить на уровне хоста. Значение по умолчанию — root.

become_method

(на уровне play или task) переопределяет метод по умолчанию, заданный в ansible.cfg, устанавливает использование любого из плагинов become.

become_flags

(на уровне play или task) разрешает использование конкретных флагов для задач или ролей. Одно из распространённых применений — изменение пользователя на nobody, когда оболочка задана как nologin. Добавлено в Ansible 2.2.

Например, чтобы управлять системной службой (что требует root привилегий), когда подключение осуществляется как непривилегированный root пользователь, вы можете использовать значение по умолчанию become_user (root).

- name: Ensure the httpd service is running
  service:
    name: httpd
    state: started
  become: yes

Чтобы выполнить команду как пользователя apache.

- name: Run a command as the apache user
  command: somecommand
  become: yes
  become_user: apache

Чтобы сделать что-то как пользователя nobody при оболочке nologin:

- name: Run a command as nobody
  command: somecommand
  become: yes
  become_method: su
  become_user: nobody
  become_flags: '-s /bin/sh'

Чтобы указать пароль для sudo, выполните ansible-playbook с --ask-become-pass (-K для краткости). Если вы запускаете playbook, использующий become, и он, кажется, зависает, скорее всего, он застрял на запросе повышения привилегий. Прекратите его с помощью CTRL-c, затем выполните playbook с -K и соответствующим паролем.

Переменные подключения become

Вы можете определить разные опции become для каждого управляемого узла или группы. Эти переменные можно определить в инвентаре или использовать как обычные переменные.

ansible_become

аналогично директиве become, решает, используется ли повышение привилегий.

ansible_become_method

какой метод повышения привилегий следует использовать

ansible_become_user

устанавливает пользователя, которому вы повышаете привилегии; не подразумевает ansible_become: yes

ansible_become_password

устанавливает пароль повышения привилегий. См. Использование зашифрованных переменных и файлов для получения подробной информации о том, как избежать наличия секретов в открытом виде

Например, если вы хотите выполнить все задачи как root на сервере с именем webserver, но можете подключаться только как manager пользователь, вы можете использовать запись в инвентаре:

webserver ansible_user=manager ansible_become=yes

Опции become в командной строке

--ask-become-pass, -K

запрашивает пароль повышения привилегий; не подразумевает, что будет использоваться become. Обратите внимание, что этот пароль будет использоваться для всех хостов.

--become, -b

выполнить операции с become (пароль не подразумевается)

--become-method=BECOME_METHOD

метод повышения привилегий для использования (по умолчанию=sudo), допустимые варианты: [ sudo | su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl ]

--become-user=BECOME_USER

выполнить операции от имени этого пользователя (по умолчанию=root), не подразумевает –become/-b

Риски и ограничения become

Хотя повышение привилегий в основном интуитивно понятно, есть несколько ограничений в его работе. Пользователи должны быть осведомлены об этих ограничениях, чтобы избежать неожиданностей.

Риски повышения привилегий до непривилегированного пользователя

Модули Ansible выполняются на удалённой машине, сначала подставляя параметры в файл модуля, затем копируя файл на удалённую машину и, наконец, выполняя его там.

Всё в порядке, если файл модуля выполняется без использования become, когда become_user является root, или когда подключение к удалённой машине выполняется как root. В этих случаях Ansible создаёт файл модуля с разрешениями, которые позволяют чтение только пользователю и root, или только чтение непривилегированному пользователю, к которому осуществляется переход.

Однако, когда и пользователь подключения, и become_user являются непривилегированными, файл модуля записывается как пользователь, с которым Ansible подключается, но файл должен быть читаем пользователем, которому Ansible настроен на become. В этом случае Ansible делает файл модуля доступным для всех для чтения на время выполнения модуля Ansible. После завершения выполнения модуля Ansible удаляет временный файл.

Если какие-либо параметры, передаваемые в модуль, являются конфиденциальными, и вы не доверяете клиентским машинам, это представляет потенциальную опасность.

Способы решения этой проблемы включают:

• Использование pipelining. Когда включена обработка потоков, Ansible не сохраняет модуль во временный файл на клиенте. Вместо этого он направляет модуль в стандартный ввод удалённого интерпретатора Python. Обработка потоков не работает для модулей Python, связанных с передачей файлов (например: copy, fetch, template), или для не-Python модулей.
• Установка поддержки POSIX.1e файловых ACL на управляемом хосте. Если временная директория на удалённом хосте смонтирована с поддержкой POSIX acls и утилита setfacl находится в удалённом PATH Ansible будет использовать POSIX acls для совместного использования файла модуля со вторым непривилегированным пользователем, вместо того чтобы делать файл доступным для всех.
• Избегайте повышения привилегий до непривилегированного пользователя. Временные файлы защищаются правами доступа в UNIX, когда вы become root или не используете become. В Ansible 2.1 и выше права доступа в UNIX также защищены, если вы подключаетесь к управляемой машине как root и затем используете become для доступа к непривилегированной учётной записи.

Ansible затрудняет неосторожное использование become небезопасным образом. Начиная с Ansible 2.1, Ansible по умолчанию выводит ошибку, если не может выполнить операцию безопасно с become. Если вы не можете использовать конвейеризацию или POSIX ACL, вы должны подключиться как непривилегированный пользователь, использовать become для выполнения как другой непривилегированный пользователь, и вы считаете, что ваши управляемые узлы достаточно безопасны для того, чтобы модули, которые вы хотите там запустить, имели права на чтение для всех, вы можете включить allow_world_readable_tmpfiles в файле ansible.cfg. Установка allow_world_readable_tmpfiles изменит это с ошибки на предупреждение и позволит задаче выполняться, как и до 2.1.

Не поддерживается всеми плагинами подключения

Методы повышения привилегий также должны поддерживаться используемым плагином подключения. Большинство плагинов подключения будут предупреждать, если они не поддерживают become. Некоторые просто проигнорируют его, так как всегда выполняются от имени root (тюрьма, chroot и так далее).

Можно включить только один метод на хост

Методы не могут быть объединены. Вы не можете использовать sudo /bin/su - для повышения привилегий до уровня пользователя, вам нужно иметь права на выполнение команды от имени этого пользователя с помощью sudo или возможность напрямую выполнить su (то же самое для pbrun, pfexec или других поддерживаемых методов).

Повышение привилегий должно быть общим

Вы не можете ограничить права повышения привилегий определёнными командами. Ansible не всегда использует конкретную команду для выполнения действия, а запускает модули (код) из временного файла с именем, которое меняется каждый раз. Если у вас есть `/sbin/service` или `/bin/chmod` в списке разрешённых команд, это приведёт к ошибке в Ansible, так как эти пути не будут соответствовать временному файлу, который Ansible создаёт для запуска модуля. Если у вас есть правила безопасности, которые ограничивают среду sudo/pbrun/doas выполнением только определённых путей команд, используйте Ansible от специальной учётной записи, не имеющей этого ограничения, или используйте Red Hat Ansible Tower для управления косвенным доступом к SSH-кредитам.

Нельзя получить доступ к переменным среды, заполненным pamd_systemd

Для большинства дистрибутивов Linux, использующих systemd в качестве init, используемые по умолчанию методы become не открывают новую «сессию» в смысле systemd. Так как модуль pam_systemd не будет полностью инициализировать новую сессию, могут возникнуть неожиданности по сравнению с обычной сессией, открытой через ssh: некоторые переменные среды, установленные pam_systemd, в частности XDG_RUNTIME_DIR, не заполняются для нового пользователя, а вместо этого наследуются или просто очищаются.

Это может вызвать проблемы при попытке вызвать команды systemd, которые зависят от XDG_RUNTIME_DIR для доступа к шине:

$ echo $XDG_RUNTIME_DIR

$ systemctl --user status
Failed to connect to bus: Permission denied

Чтобы принудительно заставить become открыть новую сессию systemd, которая проходит через pam_systemd, можно использовать become_method: machinectl.

Для получения дополнительной информации, см. данную проблему systemd.

Become и автоматизация сети

С версии 2.6 Ansible поддерживает become для повышения привилегий (переход в режим enable или привилегированный режим EXEC) на всех поддерживаемых Ansible сетевых платформах, которые поддерживают режим enable. Использование become заменяет параметры authorize и auth_pass в словаре provider.

Для использования become для повышения привилегий на сетевых устройствах, необходимо установить тип подключения на connection: ansible.netcommon.network_cli или connection: ansible.netcommon.httpapi. Подробности можно найти в документации Параметры платформ.

Вы можете использовать повышенные привилегии только для конкретных задач, для всего выполнения или для всех выполнений. Добавление become: yes и become_method: enable указывает Ansible на переход в режим enable перед выполнением задачи, выполнения или книги задач, в которых установлены эти параметры.

Если вы видите это сообщение об ошибке, задача, которая его сгенерировала, требует режима enable для успешного выполнения:

Invalid input (privileged mode required)

Чтобы установить режим enable для конкретной задачи, добавьте become на уровне задачи:

- name: Gather facts (eos)
  arista.eos.eos_facts:
    gather_subset:
      - "!hardware"
  become: yes
  become_method: enable

Чтобы включить режим для всех задач в одном выполнении, добавьте become на уровне выполнения:

- hosts: eos-switches
  become: yes
  become_method: enable
  tasks:
    - name: Gather facts (eos)
      arista.eos.eos_facts:
        gather_subset:
          - "!hardware"

Включение режима для всех задач

Часто необходимо, чтобы все задачи во всех выполнимых сценариях запускались в режиме повышения привилегий. Лучше всего это достигается с помощью group_vars.

group_vars/eos.yml

ansible_connection: ansible.netcommon.network_cli
ansible_network_os: arista.eos.eos
ansible_user: myuser
ansible_become: yes
ansible_become_method: enable

Пароли для режима enable

Если для перехода в режим enable требуется пароль, вы можете указать его двумя способами:

• указав параметр командной строки --ask-become-pass
• установив переменную подключения ansible_become_password

authorize и auth_pass

Ansible по-прежнему поддерживает режим enable с connection: local для устаревших сетевых playbooks. Чтобы перейти в режим enable с connection: local, используйте параметры модуля authorize и auth_pass:

- hosts: eos-switches
  ansible_connection: local
  tasks:
    - name: Gather facts (eos)
      eos_facts:
        gather_subset:
          - "!hardware"
      provider:
        authorize: yes
        auth_pass: " {{ secret_auth_pass }}"

Рекомендуется обновить ваши playbooks, чтобы использовать become для сетевых устройств enable consistently. Использование словарей authorize и provider будет устаревать в будущем. Подробности можно найти в документации Параметры платформ и Сетевые модули.

Become и Windows

С Ansible 2.3, become может использоваться на Windows-хостах через метод runas. Become на Windows использует ту же конфигурацию инвентаризации и аргументы вызова, что и become на не-Windows-хосте, поэтому настройки и имена переменных такие же, как определены в этом документе.

Хотя become может использоваться для принятия личности другого пользователя, есть и другие способы использования его с Windows-хостами. Важное применение – обойти некоторые ограничения, накладываемые при работе с WinRM, такие как ограниченная делегация сети или доступ к запрещённым системным вызовам, как API WUA. Вы можете использовать become с тем же пользователем, что и ansible_user, чтобы обойти эти ограничения и выполнить команды, которые обычно недоступны в сессии WinRM.

Права администратора

Многие задачи в Windows требуют прав администратора для завершения. При использовании метода повышения привилегий runas Ansible попытается выполнить модуль с полными привилегиями, доступными удалённому пользователю. Если повышение привилегий пользователя не удаётся, Ansible продолжит использование ограниченного токена во время выполнения.

Пользователь должен иметь право SeDebugPrivilege для выполнения процесса повышения привилегий с повышенными правами. Это право по умолчанию предоставляется администраторам. Если право debug недоступно, процесс повышения привилегий выполнится с ограниченным набором прав и групп.

Чтобы определить тип токена, который удалось получить Ansible, выполните следующую задачу:

- Check my user name
  ansible.windows.win_whoami:
  become: yes

Вывод будет похож на следующий:

ok: [windows] => {
    "account": {
        "account_name": "vagrant-domain",
        "domain_name": "DOMAIN",
        "sid": "S-1-5-21-3088887838-4058132883-1884671576-1105",
        "type": "User"
    },
    "authentication_package": "Kerberos",
    "changed": false,
    "dns_domain_name": "DOMAIN.LOCAL",
    "groups": [
        {
            "account_name": "Administrators",
            "attributes": [
                "Mandatory",
                "Enabled by default",
                "Enabled",
                "Owner"
            ],
            "domain_name": "BUILTIN",
            "sid": "S-1-5-32-544",
            "type": "Alias"
        },
        {
            "account_name": "INTERACTIVE",
            "attributes": [
                "Mandatory",
                "Enabled by default",
                "Enabled"
            ],
            "domain_name": "NT AUTHORITY",
            "sid": "S-1-5-4",
            "type": "WellKnownGroup"
        },
    ],
    "impersonation_level": "SecurityAnonymous",
    "label": {
        "account_name": "High Mandatory Level",
        "domain_name": "Mandatory Label",
        "sid": "S-1-16-12288",
        "type": "Label"
    },
    "login_domain": "DOMAIN",
    "login_time": "2018-11-18T20:35:01.9696884+00:00",
    "logon_id": 114196830,
    "logon_server": "DC01",
    "logon_type": "Interactive",
    "privileges": {
        "SeBackupPrivilege": "disabled",
        "SeChangeNotifyPrivilege": "enabled-by-default",
        "SeCreateGlobalPrivilege": "enabled-by-default",
        "SeCreatePagefilePrivilege": "disabled",
        "SeCreateSymbolicLinkPrivilege": "disabled",
        "SeDebugPrivilege": "enabled",
        "SeDelegateSessionUserImpersonatePrivilege": "disabled",
        "SeImpersonatePrivilege": "enabled-by-default",
        "SeIncreaseBasePriorityPrivilege": "disabled",
        "SeIncreaseQuotaPrivilege": "disabled",
        "SeIncreaseWorkingSetPrivilege": "disabled",
        "SeLoadDriverPrivilege": "disabled",
        "SeManageVolumePrivilege": "disabled",
        "SeProfileSingleProcessPrivilege": "disabled",
        "SeRemoteShutdownPrivilege": "disabled",
        "SeRestorePrivilege": "disabled",
        "SeSecurityPrivilege": "disabled",
        "SeShutdownPrivilege": "disabled",
        "SeSystemEnvironmentPrivilege": "disabled",
        "SeSystemProfilePrivilege": "disabled",
        "SeSystemtimePrivilege": "disabled",
        "SeTakeOwnershipPrivilege": "disabled",
        "SeTimeZonePrivilege": "disabled",
        "SeUndockPrivilege": "disabled"
    },
    "rights": [
        "SeNetworkLogonRight",
        "SeBatchLogonRight",
        "SeInteractiveLogonRight",
        "SeRemoteInteractiveLogonRight"
    ],
    "token_type": "TokenPrimary",
    "upn": "vagrant-domain@DOMAIN.LOCAL",
    "user_flags": []
}

В ключе label значение account_name определяет, имеет ли пользователь права администратора. Вот значения, которые могут быть возвращены, и что они означают:

• Medium: Ansible не удалось получить повышенный токен, и выполнение происходило с ограниченным токеном. Во время выполнения модуля доступна только часть привилегий, назначенных пользователю, и пользователь не имеет прав администратора.
• High: Использовался повышенный токен, и все привилегии, назначенные пользователю, доступны во время выполнения модуля.
• System: Используется учётная запись NT AUTHORITY\System, имеющая наивысший уровень доступных привилегий.

Вывод также покажет список привилегий, предоставленных пользователю. Когда значение привилегии равно disabled, привилегия назначена токену входа, но не включена. В большинстве случаев эти привилегии автоматически включаются по необходимости.

Если выполнение на версии Ansible, младшей чем 2.5, или стандартный процесс повышения привилегий runas завершается неудачно, повышенный токен можно получить, выполнив:

• Установите become_user в значение System, которое имеет полный контроль над операционной системой.

• Предоставьте SeTcbPrivilege пользователю Ansible, подключающемуся через WinRM. SeTcbPrivilege – это привилегия высокого уровня, предоставляющая полный контроль над операционной системой. По умолчанию ни одному пользователю эта привилегия не предоставляется, и следует быть осторожным, предоставляя эту привилегию пользователю или группе. Более подробная информация об этой привилегии доступна по ссылке Действовать от имени операционной системы. Вы можете использовать следующую задачу для установки этой привилегии на Windows-хосте:

  - name: grant the ansible user the SeTcbPrivilege right
    ansible.windows.win_user_right:
      name: SeTcbPrivilege
      users: '{{ansible_user}}'
      action: add
  

• Отключите UAC на хосте и перезагрузите его перед попыткой повышения привилегий пользователя. UAC – это протокол безопасности, разработанный для работы учётных записей с принципом least privilege. Отключить UAC можно, выполнив следующие задачи:

  - name: turn UAC off
    win_regedit:
      path: HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
      name: EnableLUA
      data: 0
      type: dword
      state: present
    register: uac_result
  
  - name: reboot after disabling UAC
    win_reboot:
    when: uac_result is changed
  

Локальные учётные записи службы

Перед версией Ansible 2.5, become работала только в Windows с локальным или доменным учетной записью пользователя. Локальные учетные записи службы, такие как System или NetworkService, не могли использоваться в качестве become_user в этих более старых версиях. Это ограничение было снято с момента выпуска Ansible 2.5. Три учетные записи службы, которые могут быть установлены в become_user, это:

• Система
• NetworkService
• LocalService

Поскольку локальные учетные записи служб не имеют паролей, параметр ansible_become_password не требуется и игнорируется, если он указан.

Become без установки пароля

Начиная с Ansible 2.8, become может использоваться для перехода в локальную или доменную учетную запись Windows без необходимости пароля для этой учетной записи. Для работы этого метода должны быть выполнены следующие требования:

• Пользователь подключения имеет привилегию SeDebugPrivilege
• Пользователь подключения является частью группы BUILTIN\Administrators
• У become_user есть право пользователя SeBatchLogonRight или SeNetworkLogonRight

Использование become без пароля достигается одним из двух способов:

• Дублирование токена существующей сессии входа в систему, если учетная запись уже вошла в систему
• Использование S4U для генерации токена входа, который действителен только на удаленном хосте

В первом случае процесс become запускается от другого входа в систему для этой учетной записи пользователя. Это может быть существующий вход RDP, консольный вход, но это не гарантируется каждый раз. Это похоже на опцию Run only when user is logged on для запланированной задачи.

В случае, когда другой вход в систему для учетной записи become не существует, используется S4U для создания нового входа и запуска модуля через него. Это похоже на Run whether user is logged on or not с опцией Do not store password для запланированной задачи. В этом случае процесс become не сможет получить доступ к сетевым ресурсам, как обычный процесс WinRM.

Чтобы отличить использование become без пароля от перехода в учетную запись без пароля, убедитесь, что ansible_become_password не определено или что ansible_become_password: установлено.

Учетные записи без пароля

Ansible может использоваться для перехода в учетную запись Windows, у которой нет пароля (например, учетную запись Guest). Чтобы перейти в учетную запись без пароля, настройте переменные как обычно, но установите ansible_become_password: ''.

Прежде чем become сможет работать с такой учетной записью, локальная политика Учетные записи: ограничение использования учетными записями пустых паролей только для консольного входа должна быть отключена. Это можно сделать с помощью объекта групповой политики (GPO) или с помощью этой задачи Ansible:

- name: allow blank password on become
  ansible.windows.win_regedit:
    path: HKLM:\SYSTEM\CurrentControlSet\Control\Lsa
    name: LimitBlankPasswordUse
    data: 0
    type: dword
    state: present

Флаги become для Windows

Ansible 2.5 добавил параметр become_flags к методу become runas. Этот параметр можно установить с помощью директивы задачи become_flags или в конфигурации Ansible с помощью ansible_become_flags. Два допустимых значения, которые изначально поддерживаются для этого параметра, это logon_type и logon_flags.

Ключ logon_type задает тип операции входа в систему для выполнения. Значение может быть установлено в одно из следующих:

• interactive: Тип входа в систему по умолчанию. Процесс будет выполняться в контексте, таком же, как при выполнении процесса локально. Это обходит все ограничения WinRM и является рекомендуемым методом.
• batch: Выполняет процесс в контексте пакетной обработки, аналогичном запланированной задаче с заданным паролем. Это должно обойти большинство ограничений WinRM и полезно, если become_user не разрешено входить в систему интерактивно.
• new_credentials: Выполняет процесс с теми же учетными данными, что и вызывающий пользователь, но исходящие подключения выполняются в контексте become_user и become_password, аналогично runas.exe /netonly. Флаг logon_flags также должен быть установлен в netcredentials_only. Используйте этот флаг, если процесс должен получить доступ к сетевому ресурсу (например, к общей папке SMB) с использованием другой набора учетных данных.
• network: Выполняет процесс в сетевом контексте без кэшированных учетных данных. Это приводит к тому же типу сессии входа в систему, что и при выполнении обычного процесса WinRM без делегирования учетных данных, и действует в рамках тех же ограничений.
• network_cleartext: Как и тип входа в систему network, но вместо этого кэширует учетные данные, чтобы получить доступ к сетевым ресурсам. Это тот же тип сессии входа в систему, что и при выполнении обычного процесса WinRM с делегированием учетных данных.

Дополнительную информацию см. в dwLogonType.

Ключ logon_flags указывает, как Windows войдет в систему пользователя при создании нового процесса. Значение может быть установлено на none или несколько следующих:

• with_profile: Установленный по умолчанию флаг входа в систему. Процесс загрузит профиль пользователя в реестре HKEY_USERS в HKEY_CURRENT_USER.
• netcredentials_only: Процесс будет использовать тот же токен, что и вызывающий, но будет использовать become_user и become_password при доступе к удаленному ресурсу. Это полезно в междоменных сценариях, где нет отношений доверия, и должно использоваться с флагом new_credentials logon_type.

По умолчанию logon_flags=with_profile установлено, если профиль не должен загружаться, установите logon_flags= или если профиль должен загружаться с netcredentials_only, установите logon_flags=with_profile,netcredentials_only.

Дополнительную информацию см. в dwLogonFlags.

Вот несколько примеров использования become_flags с задачами Windows:

- name: copy a file from a fileshare with custom credentials
  ansible.windows.win_copy:
    src: \\server\share\data\file.txt
    dest: C:\temp\file.txt
    remote_src: yes
  vars:
    ansible_become: yes
    ansible_become_method: runas
    ansible_become_user: DOMAIN\user
    ansible_become_password: Password01
    ansible_become_flags: logon_type=new_credentials logon_flags=netcredentials_only

- name: run a command under a batch logon
  ansible.windows.win_whoami:
  become: yes
  become_flags: logon_type=batch

- name: run a command and not load the user profile
  ansible.windows.win_whomai:
  become: yes
  become_flags: logon_flags=

Ограничения become в Windows

• Выполнение задачи с async и become в Windows Server 2008, 2008 R2 и Windows 7 работает только при использовании Ansible 2.7 или более поздней версии.
• По умолчанию пользователь become входит в систему с интерактивной сессией, поэтому он должен иметь право на это на хосте Windows. Если он не наследует привилегию SeAllowLogOnLocally или наследует привилегию SeDenyLogOnLocally, процесс become завершится ошибкой. Либо добавьте привилегию, либо установите флаг logon_type для изменения типа входа в систему.
• До версии Ansible 2.3, become работал только тогда, когда ansible_winrm_transport был либо basic, либо credssp. Это ограничение было снято с момента выпуска Ansible 2.4 для всех хостов, кроме Windows Server 2008 (версия без R2).
• Служба вторичного входа в систему seclogon должна быть запущена, чтобы использовать ansible_become_method: runas