私自身はwmicに不慣れで、デフォルトのエージェントクエリアプローチで長い間試行を続けています。
wmicは、Windows WMIエージェントと通信するLinuxベースのWMIツールです。 nt(WMIサービスが実行されているwin7)からwmicを使用してデータをフェッチしようとしているときに、すべてのケースでアクセスが拒否されたことを示しています。
考えられる理由は何ですか、それはファイアウォールポート、WMIグループ、ファイルまたはユーザーのアクセス許可などですか?どんな種類のヒントも非常に役立ちます。
[root@rhel6 wmic]# wmic -U nt-login-name% //nt-primary-ip "select caption, name, parentprocessid, processid from win32_process"
[librpc/rpc/dcerpc_util.c:1290:dcerpc_pipe_auth_recv()] Failed to bind to uuid 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57 - NT_STATUS_NET_WRITE_FAULT
[librpc/rpc/dcerpc_connect.c:790:dcerpc_pipe_connect_b_recv()] failed NT status (c0000022) in dcerpc_pipe_connect_b_recv
[wmi/wmic.c:196:main()] ERROR: Login to remote object.
NTSTATUS: NT_STATUS_ACCESS_DENIED - Access denied
私は同じ問題のデバッグに何時間も費やし、セキュリティ設定Network security: LAN Manager authentication level
が問題の核心であることがわかりました。これは、問題のあるサーバーではSend NTLMv2 response only\refuse LM & NTLM
に設定されていました。これをSend LM & NTLM - use NTLMv2 session security if negotiated
に変更すると、問題が修正され、wmic
が接続できるようになります。
-U
スイッチで完全な認証情報を使用し、パスワードに %?
wmic -U [domain/]adminuser%
パスワード//Host "select caption, name, parentprocessid, processid from win32_process""
私にとってうまくいくクエリはこれです:
wmic -U NTDOMAIN/administrator%password //192.168.0.73 "select username from Win32_Computersystem"
私はまだコメントする評判がありませんでしたが、私自身がこれに遭遇した後、問題は、AdrianFrühwirthが言及しているように、Linux WMICエージェントがGPOに必要なNTLMv2ではなく、LM認証要求を送信していたことがわかりました。セキュリティポリシーの制限を緩和する代わりに、WMICコマンドラインに以下を追加するアプローチを採用しました。
--option="client ntlmv2 auth"=Yes
。
これで問題が解決し、サーバーがLMでサポートされている安全性の低い認証交換を受け入れるように強制されませんでした。
役立つ可能性のあるリファレンス: https://support.nagios.com/forum/viewtopic.php?t=5029&p=22405