Понимание эскалации привилегий

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

• Стать
• Директивы
  • Переменные подключения
  • Параметры командной строки
  • Для тех, кто использует версии до 1.9, sudo и su по-прежнему работают!
  • Ограничения
    • Стать непривилегированным пользователем
    • Поддержка плагинов подключения
    • Только один метод может быть включён для каждого хоста
    • Невозможно ограничить эскалацию определёнными командами
    • Переменные окружения, заполненные pam_systemd
• Стать и сети
  • Установка режима включения для всех задач
    • Пароли для режима включения
  • authorize и auth_pass
• Стать и Windows
  • Права администратора
  • Локальные учётные записи служб
  • Стать без установки пароля
  • Учётные записи без пароля
  • Флаги стать
  • Ограничения

Стать

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

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

Директивы

Они могут быть установлены от уровня воспроизведения до уровня задачи, но переопределяются переменными подключения, так как они могут быть специфичными для хоста.

become

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

become_user

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

become_method

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

become_flags

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

Например, чтобы управлять системной службой (которая требует 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 при shell nologin:

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

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

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

ansible_become

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

ansible_become_method

какой метод эскалации привилегий следует использовать

ansible_become_user

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

ansible_become_password

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

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

webserver ansible_user=manager ansible_become=yes

Параметры командной строки

Для тех, кто использует версии до 1.9, sudo и su по-прежнему работают!

Для тех, кто использует старые скрипты воспроизведения, не потребуется вносить изменения, даже если они устарели, sudo и su директивы, переменные и опции продолжат работать. Рекомендуется перейти на стать, так как они могут быть удалены в будущем. Вы не можете смешивать директивы на одном объекте (become и sudo), Ansible выдаст ошибку, если вы попытаетесь это сделать.

Стать по умолчанию будет использовать старые конфигурации и переменные sudo/su, если они существуют, но переопределит их, если вы укажете новые.

Ограничения

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

Стать непривилегированным пользователем

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

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

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

Если какие-либо параметры, передаваемые модулю, являются конфиденциальными, эти данные находятся в файле модуля, доступном для общего чтения на период выполнения модуля Ansible. После выполнения модуля Ansible удалит временный файл. Если вы доверяете клиентским машинам, то здесь нет проблем. Если вы не доверяете клиентским машинам, то это потенциальная опасность.

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

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

В дополнение к дополнительным способам безопасного выполнения этого, Ansible 2.1 также затрудняет неосознанное выполнение этого небезопасно. В то время как в Ansible 2.0.x и ниже Ansible молча разрешал небезопасное поведение, если не удавалось найти другой способ совместного доступа к файлам с пользователем без привилегий, в Ansible 2.1 и выше Ansible по умолчанию выводит ошибку, если это невозможно сделать безопасно. Если вы не можете внести никакие из вышеуказанных изменений для решения проблемы и решите, что машина, на которой вы работаете, достаточно безопасна для того, чтобы модули, которые вы хотите запустить там, были доступны всем, вы можете включить 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 для выполнения модуля.

Переменные окружения, заполняемые pam_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.

Поднятие привилегий и сети

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

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

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

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

Invalid input (privileged mode required)

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

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

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

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

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

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

group_vars/eos.yml

ansible_connection: network_cli
ansible_network_os: 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 для устаревших книг задач. Чтобы войти в режим 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 }}"

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

Поднятие привилегий и Windows

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

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

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

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

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

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

- 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
    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 работало только с локальной или доменной учетной записью пользователя. Локальные учетные записи служб, такие как System или NetworkService, не могли использоваться как become_user в этих более старых версиях. Это ограничение было снято с момента выпуска Ansible 2.5. Три учетные записи служб, которые можно установить в become_user:

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

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

Выполнение в режиме без указания пароля

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

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

Режим выполнения без пароля достигается одним из двух способов:

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

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

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

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

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

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

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

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

Флаги выполнения

Ansible 2.5 добавляет параметр become_flags к методу выполнения 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
  win_copy:
    src: \\server\share\data\file.txt
    dest: C:\temp\file.txt
    remote_src: yex
  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
  win_whoami:
  become: yes
  become_flags: logon_type=batch

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

Ограничения

Обратите внимание на следующие ограничения при использовании become в Windows:

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