権限昇格の理解: become

Become ディレクティブ

プレイまたはタスクレベルで、become を制御するディレクティブを設定できます。多くの場合は、ホストごとに異なる接続変数を設定することで、これらをオーバーライドできます。これらの変数とディレクティブは独立しています。たとえば、become_user に設定しても become に設定されません。

become

権限昇格をアクティブにするには、yes に設定します。

become_user

希望する権限を持つユーザーに設定します。ログインしたユーザーではなく、become を行ったユーザーになります。ホストレベルで設定できるようにする become: yes を意味するものではありません。デフォルト値は root です。

become_method

(play レベルまたは task レベルで)、ansible.cfg に設定されたデフォルトのメソッドをオーバーライドし、become プラグイン を使用するよう設定します。

become_flags

(play レベルまたは task レベルで) タスクまたはロールに特定のフラグの使用を許可します。一般的な使い方としては、シェルが nologin に設定されているときに、ユーザーを nobody に変更するのが一般的な方法です。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

シェルが nologin の場合に nobody ユーザーとして操作を行う場合は、次を実行します。

- 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) と一緒に実行します。become を使用して Playbook を実行し、Playbook がハングしているように見える場合は、ほとんどの場合、特権昇格のプロンプトで止まっています。CTRL-c で停止させてから、-K と適切なパスワードで Playbook を実行してください。

Become 接続変数

管理対象ノードまたはグループごとに異なる become オプションを定義できます。これらの変数はインベントリーで定義するか、通常の変数として使用できます。

ansible_become

become ディレクティブを上書きします。権限のエスカレーションが使用されるかどうかを指定します。

ansible_become_method

使用する権限昇格方法です。

ansible_become_user

権限昇格で become を行うユーザーを設定します。ansible_become: yes を意味するものではありません。

ansible_become_password

権限昇格パスワードを設定します。平文での秘密の使用を回避する方法は、「暗号化された変数とファイルの使用」を参照してください。

ansible_common_remote_group

setfacl と chown の両方が失敗した場合に、Ansible が一時ファイルをグループに chgrp しようとするかどうかを決定します。詳細は「非特権ユーザーになるリスク」を参照してください。バージョン 2.10 で追加されました。

たとえば、すべてのタスクを webserver という名前のサーバーで root として実行することを望み、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 が接続するユーザー (remote_user) として記述されますが、Ansible が become に設定されているユーザーがファイルを読み取れる必要があります。Ansible がこれをプラットフォーム別に解決する方法の詳細は次のとおりですが、POSIX システムでは、Ansible がこの問題を解決します。

まず、リモート PATH に setfacl がインストールされ、利用可能な場合は、リモートホストの一時ディレクトリーが POSIX.1e ファイルシステム ACL サポートでマウントされている場合、Ansible は POSIX ACL を使用して 2 つの非特権ユーザーとモジュールファイルを共有します。

次に、POSIX ACL が利用 できない か、setfacl を実行できない場合、Ansible は、特権のないユーザーとして対応するシステムの chown を使用してモジュールファイルの所有権を変更しようとします。

Ansible 2.11 の新機能として、Ansible は、ファイルに ACL を設定する際に macOS 固有の方法で chmod +a を試行します。

Ansible 2.10 の新機能で、上記のすべてが失敗すると、Ansible は構成設定 ansible_common_remote_group の値を確認します。多くのシステムでは、特定のユーザーが、ファイルのグループ所有権を、所属するグループに変更できます。その結果、2 番目の非特権ユーザー (become_user) に、Ansible が (remote_user``として) 接続するユーザーに共通する UNIX グループがあり、``ansible_common_remote_group がそのグループとして定義されている場合は、 chgrp を使用してモジュールファイルのグループ所有権をそのグループに変更しようとすることができます。したがって、become_user が読みるようになる可能性があります。

この時点で、ansible_common_remote_group が定義され、 chgrp が試行されて正常に返された場合、Ansible は新しいグループの所有権で十分であると仮定し (ただし、重要なことですが、確認はしません)、それ以上はフォールバックしません。つまり、become_user が実際に remote_user とグループを共有しているかどうかは 確認しません。コマンドが正常に終了する限り、Ansible はその結果を成功とみなし、以下の allow_world_readable_tmpfiles のチェックには進みません。

ansible_common_remote_group が 設定されておらず、そこでの chown が失敗した場合、または ansible_common_remote_group が 設定されているが chgrp (またはそれに続くグループパーミッションの chmod) が成功しない終了コードを返した場合、Ansible は最後に allow_world_readable_tmpfiles の値を確認します。この値が設定されていると、Ansible はモジュールファイルを誰もが読める一時ディレクトリーに置き、become_user (およびシステム上の他のユーザー) がファイルの内容を読めるように、誰もが読み取り可能なパーミッションを設定します。モジュールに渡されるパラメーターに機密性があり、リモートマシンを信用していない場合、これは潜在的なセキュリティーリスクとなります。

モジュールの実行が完了すると、Ansible は一時ファイルを削除します。

上記のロジックフローを完全に回避する方法はいくつかあります。

• pipelining を使用します。パイプラインを有効にすると、Ansible はモジュールをクライアント上の一時ファイルに保存しません。代わりに、モジュールをリモートの python インタープリターの標準入力にパイプします。パイプラインは、ファイル転送を伴う python モジュール (例: copy、fetch、template) や、python 以外のモジュールでは機能しません。

• 非特権ユーザーは使用しないでください。root に become した場合、または become を使用しない場合は、UNIX ファイルの権限で保護されます。Ansible 2.1 以降では、UNIX ファイルのパーミッションは、root として管理マシンに接続し、権限のないアカウントにアクセスするには、become を使用しても保護されます。

Ansible では、知らずに become を安全でない状態で使用することは困難です。Ansible 2.1 以降、Ansible は become で安全に実行できない場合は、デフォルトでエラーを発行するようになっています。パイプラインや POSIX ACL を使用できず、非特権ユーザーとして接続しなければならず、become を使用して別の非特権ユーザーとして実行しなければならず、管理対象のノードが、そこで実行したいモジュールが誰でも読むことができる程度に安全であると判断した場合は、ansible.cfg ファイルで allow_world_readable_tmpfiles を有効にすることができます。allow_world_readable_tmpfiles を設定すると、これがエラーから警告に変わり、2.1 以前のようにタスクを実行できるようになります。

Ansible 2.10 では、上記の ansible_common_remote_group フォールバックが導入されました。上記のように、有効になっていると、remote_user と become_user の両方が非特権ユーザーである場合に使用されます。このフォールバックが発生するときの詳細は、上記のテキストを参照してください。

すべての connection プラグインでサポートされない

特権昇格の方法は、使用する connection プラグインがサポートしている必要があります。ほとんどの connection プラグインは、become をサポートしていないと警告を表示します。一部の connection プラグインでは、常に root として実行されるため (jail、chroot など)、無視されます。

ホストごとに有効にできる方法は 1 つだけ

メソッドを連鎖させることはできません。sudo /bin/su - を使用してユーザーになる (become) ことはできません。そのユーザーとして sudo でコマンドを実行するか、直接 su できるような権限が必要です (pbrun、pfexec、その他のサポートされている方法も同様です)。

特権昇格は一般的なものにすること

特権昇格の許可を特定のコマンドに限定することはできません。Ansible は常に特定のコマンドを使用して何かを行うわけではなく、毎回変更される一時ファイル名からモジュール (コード) を実行します。許可されるコマンドとして「/sbin/service」や「/bin/chmod」を指定した場合、これらのパスは Ansible がモジュールを実行するために作成する一時ファイルと一致しないため、Ansible では失敗します。sudo/pbrun/doas 環境で特定のコマンドパスしか実行できないようなセキュリティールールがある場合は、この制約を受けない特別なアカウントで Ansible を使用するか、AWX または Red Hat Ansible Automation Platform を使用して SSH 認証情報への間接的なアクセスを管理してください。

pamd_systemd が設定する環境変数にアクセスできない場合

systemd を init として使用しているほとんどの Linux ディストリビューションでは、become が使用するデフォルトの方法では、systemd の意味での新しい「セッション」を開くことができません。pam_systemd モジュールは新しいセッションを完全には初期化しないため、ssh で開いた通常のセッションと比べて驚くことがあるかもしれません。pam_systemd によって設定されたいくつかの環境変数、特に XDG_RUNTIME_DIR は新しいユーザーには設定されず、代わりに継承されたり、単に空になったりします。

このため、バスへのアクセスを XDG_RUNTIME_DIR に依存する systemd コマンドを呼び出す際に問題が発生する可能性があります。

$ echo $XDG_RUNTIME_DIR

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

become に、pam_systemd を通して新しい systemd セッションを開くために、become_method: machinectl を使用することができます。

詳細情報は、「this systemd issue」を参照してください。

一時的なファイルエラーメッセージの解決

• 非特権ユーザーになる場合に Ansible が作成する必要のある一時ファイルに権限を設定できませんでした

• このエラーは、setfacl コマンドを提供するパッケージをインストールすることで解決できます (多くの場合、これは``acl``パッケージ ですが、OS ドキュメントを確認してください)。

すべてのタスクに enable モードの設定

すべてのプレイのすべてのタスクを特権モードで実行させたいと思うことがよくありますが、そのような場合には、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

authorize および auth_pass

Ansible では、従来のネットワークの Playbook について、connection: local を使用した enable モードを引き続きサポートしています。connection: local で enable モードに入るには、モジュールオプション 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 }}"

ネットワークデバイスの enable モードに become を一貫して使用するように Playbook を更新することが推奨されます。authorize および provider ディクショナリーの使用は、今後は推奨されません。詳細は、「Platform Options」および「Network modules」のドキュメントを参照してください。

管理者権限

Windows の多くのタスクを完了するには、管理者権限が必要です。runas の become メソッドを使用すると、Ansible は become ユーザーが使用できる全権限でモジュールの実行を試みます。ユーザートークンの昇格に失敗すると、実行中に制限されたトークンを引き続き使用します。

ユーザーは、昇格された権限で become プロセスを実行するには、SeDebugPrivilege が必要です。この権限はデフォルトで管理者に割り当てられます。デバッグ権限が利用できない場合、become プロセスは、限られた一連の特権およびグループで実行されます。

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": "[email protected]",
    "user_flags": []
}

label キーにおいて、account_name エントリーは、ユーザーに管理権限があるかどうかを判断します。ここでは、返すことができるラベルと、そのラベルが表す内容を紹介します。

• Medium: Ansible が昇格したトークンの取得に失敗し、制限付きのトークンで実行されました。モジュールの実行中に、ユーザーに割り当てられた特権のサブセットのみが利用可能で、ユーザーは管理者権限を持っていません。

• High: 昇格されたトークンが使用され、ユーザーに割り当てられたすべての特権は、モジュールの実行時に利用できます。

• System: NT AUTHORITY\System アカウントが使用され、利用可能な最高レベルの特権が付与されます。

出力には、ユーザーに付与される権限の一覧が表示されます。権限の値が disabled の場合、特権はログオントークンに割り当てられますが、有効になっていません。ほとんどのシナリオでは、これらの特権は必要に応じて自動的に有効になります。

Ansible のバージョンが 2.5 よりも古い場合や、通常の runas のエスカレーションプロセスが失敗した場合は、昇格したトークンを以下の方法で取得できます。

• become_user を、オペレーティングシステムを完全にコントロールする System に設定します。

• Ansible が WinRM で接続するユーザーに SeTcbPrivilege を付与します。SeTcbPrivilege は、オペレーティングシステムに対する完全な制御を付与する高レベルの特権です。デフォルトでは、この特権は指定されていません。この特権をユーザーまたはグループに付与する場合は注意が必要です。この特権の詳細は、「Act as part of the operating system」を参照してください。以下のタスクを使用して、Windows ホストでこの特権を設定できます。

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

• そのユーザーになる (become) 前に、ホストで 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 に設定できる 3 つのサービスアカウントは以下のとおりです。

• システム

• NetworkService

• LocalService

ローカルサービスアカウントはパスワードを持たないため、ansible_become_password パラメーターは必須ではなく、指定しても無視されます。

パスワードを設定しない Become

Ansible 2.8 では、Windows のローカルまたはドメインアカウントになるために、そのアカウントのパスワードがなくても become を使用することができます。この方法を行うには、以下の要件を満たす必要があります。

• 接続ユーザーに SeDebugPrivilege 権限が割り当てられている

• 接続ユーザーが BUILTIN\Administrators グループに属している

• become_user に、SeBatchLogonRight または SeNetworkLogonRight のユーザー権限がある

パスワードなしの become は、次のいずれかの方法で使用できます。

• アカウントがすでにログオンしている場合は、既存のログオンセッションのトークンを複製する

• S4U を使用してリモートホストでのみ有効なログイントークンを生成する

最初のシナリオでは、そのユーザーアカウントの別のログオンから become プロセスを起動します。これは既存の RDP ログイン、コンソールログオンですが、これは常に発生するとは限りません。これは、スケジュール済みタスクの Run only when user is logged on オプションと類似しています。

become アカウントの別のログオンが存在しない場合は、S4U を使用して新しいログオンを作成し、それを介してモジュールを実行します。これは、スケジュール済みタスクの Do not store password オプションを持つ Run whether user is logged on or not と似ています。このシナリオでは、become プロセスは通常の WinRM プロセスなどのネットワークリソースにアクセスできません。

パスワードなしで become を使用することと、パスワードがないアカウントになる (become) ことを区別するには、ansible_become_password を undefined にしておくか、ansible_become_password: を設定してください。

パスワードのないアカウント

Ansible を使用して、パスワードがない Windows アカウントになります (Guest アカウントなど)。パスワードのないアカウントになるには、通常どおり変数を設定しますが、ansible_become_password: '' を設定します。

このようなアカウントで become を有効にする前に、ローカルポリシー Accounts: Limit local account use of blank passwords to console logon only を無効にする必要があります。これは Group Policy Object (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

Windows での Become フラグ

Ansible 2.5 では、become_flags パラメーターを become メソッド runas に追加しました。このパラメーターは、become_flags タスクディレクティブを使用するか、ansible_become_flags を使用して Ansible の設定で設定できます。このパラメーターで最初にサポートされる 2 つの有効な値は logon_type と logon_flags です。

鍵 logon_type は、実行するログオン操作のタイプを設定します。値は以下のいずれかに設定できます。

• interactive: デフォルトのログオンタイプ。プロセスは、ローカルでプロセスを実行するときと同じコンテキストで実行されます。これにより、すべての WinRM 制限が回避され、推奨される方法です。

• batch: パスワードセットを使用してスケジュールされたタスクに似たバッチコンテキストでプロセスを実行します。これにより、ほとんどの WinRM 制限を回避する必要があり、become_user が対話的にログインできない場合に役立ちます。

• new_credentials: 呼び出し元ユーザーと同じ認証情報の下で実行されますが、発信側の接続は runas.exe /netonly と同様に become_user と become_password のコンテキストの下で実行されます。logon_flags フラグは、netcredentials_only にも設定する必要があります。このフラグは、プロセスが異なる認証情報セットを使用してネットワークリソース (SMB 共有など) にアクセスする必要がある場合に使用します。

• network: キャッシュされた認証情報なしで、ネットワークコンテキストでプロセスを実行します。これにより、認証情報の委譲を使用せずに通常の WinRM プロセスを実行するのと同じ種類のログオンセッションが実行され、同じ制限で動作します。

• network_cleartext: network ログオンタイプなのですが、代わりに認証情報をキャッシュするため、ネットワークリソースにアクセスできます。これは、認証情報の委譲を使用して通常の WinRM プロセスを実行するのと同じタイプのログオンセッションです。

詳細情報は、「dwLogonType」を参照してください。

logon_flags キーは、新規プロセスの作成時に Windows がユーザーをログに記録する方法を指定します。この値は、以下の複数の値に設定でき、値を設定しないこともできます。

• 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」を参照してください。

Windows タスクで become_flags を使用する例を以下に示します。

- 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=

Windows における become 制限

• Windows Server 2008、2008 R2、Windows 7 で async および become を使用してタスクを実行できるのは、Ansible 2.7 以降を使用している場合のみです。

• デフォルトでは、become ユーザーは対話型セッションでログオンするため、Windows ホストでこの権限を設定する必要があります。SeAllowLogOnLocally 特権を継承しない場合、または SeDenyLogOnLocally 特権を継承する場合は become プロセスに失敗します。特権を追加するか、logon_type フラグを設定して使用するログオンタイプを変更してください。

• Ansible バージョン 2.3 よりも前のバージョンでは、ansible_winrm_transport が basic または credssp のいずれかでのみ機能していました。この制限は、Windows Server 2008 (R2 バージョン以外) を除くすべてのホストで 2.4 リリース以降に取り込まれました。

• ansible_become_method: runas を使用するには、セカンダリーログオンサービス seclogon が実行している必要があります。

• runas を使用するには、接続ユーザーがすでに Windows ホストの管理者である必要があります。ターゲット become ユーザーは管理者である必要はありません。