Windows ディスカバリーの概要 - Support and Troubleshooting

Windows ディスカバリーの概要 説明 このサポート技術情報の記事では、Windows 検出に関するいくつかの主要なトピックについて説明します。

サポートされている Windows バージョン、PowerShell の要件、収集されるデータ、および Windows でトリガーされるプローブ/パターンについては、ServiceNow インスタンスリリースの次の「Windows ディスカバリー」ドキュメントを参照してください。

Windows ディスカバリー 目次 説明 WMI と WinRM の比較 Shazzam Windows 分類 認証情報 資格情報テスト リモート機能テスト プロパティとパラメーター トラブルシューティング 一般的なエラー 追加情報 WMI と WinRM の比較 ServiceNow ディスカバリーは、複数のプロトコルを利用してターゲットデバイスと通信します。Windows 検出には、WMI または WinRM のいずれかを使用できます。Windows ディスカバリーに使用されるプロトコルは、MID サーバーパラメーター「mid.windows.management_protocol」を介して MID サーバーレベルで制御されます。このプロパティのデフォルト値は「WMI」です。

ネットワーク要件 WMI と WinRM では、ネットワーク/ファイアウォールの要件が異なります。

WMI WMI は DCOM/RPC に基づいています。これは、使用する動的ポートを決定するために、最初にポート 135 で接続が開始されることを意味します。その後、接続はネゴシエートされた動的ポートの使用に進みます。

次のMicrosoftのドキュメントには、このトピックの詳細が記載されています。

リモート WMI 接続の設定 ファイアウォールで動作するようにRPC動的ポート割り当てを構成する方法 拡張 Windows 検出では、ターゲット サーバー admin$ も使用されるため、ファイル共有ポート トラフィック (ポート 445) も許可する必要があります。拡張 Windows 検出の詳細については、以下を参照してください。

Windows PowerShell ディスカバリーと従来の Windows ディスカバリーの違い WinRM WinRM はポート 5985 (HTTP) または 5986 (HTTPS) を使用しますが、これはターゲットホストの構成によって異なります。次のMicrosoftのドキュメントには、WinRMの設定に関する詳細情報が記載されています。

Windows リモート管理のインストールと構成 HTTPS 用に WINRM を構成する方法 ネットワークの問題 サポートは、このような問題を解決するために最善の努力を提供します。ただし、WMI と WinRM のどちらの場合も、接続の問題を解決するために、ターゲット デバイスが配置されている環境を管理するネットワーク管理者およびシステム管理者に問い合わせることをお勧めします。

Shazzam Shazzam は検出の最初のフェーズです。このフェーズでは、デフォルト設定で、MID サーバーはポート 135、5985、および 5986 でターゲットサーバーに SYN 要求を送信します。ターゲット・デバイスがこれらのポートで応答すると、Windows分類がトリガーされます。次の画像では、Shazzam プローブのecc_queue入力がスキャンされたポートの結果を示しています。

Shazzam がポートが開いていることを正常に検出したからといって、すべてのネットワーク要件が満たされているとは限りません。ディスカバリーの後のフェーズでは、ディスカバリーが実際にターゲットサーバーへの接続を確立する場合、特に接続を完了するために動的ポートが必要な WMI の場合、接続の問題が発生する可能性があります。

Windows 分類 この Windows - WMIRunner 分類プローブは、Shazzam の直後の Windows ディスカバリーでトリガーされる最初のプローブです。このプローブは、MID サーバーの scripts\WMI フォルダーにあるスクリプト WMIRunner.js とWMIScanner.jsを実行します。このプローブは、WBEMTEST の接続方法と同様に、MID サーバーサービス認証情報を使用してターゲットデバイスと通信します。したがって、トラブルシューティングのために MID サーバーから WBEMTEST を使用できます。

ed O S ...N" width="480" height="470" />

WBEMTEST の概要 ただし、Fuji (2015) 以降、mid.use_powershellパラメーターはデフォルトで true になり、このプローブの動作が変更されます。mid.use_powershell = true の場合、ロジックは実質的に代わりに PowershellProbe ロジックに置き換えられます。これにより、MID サービスアカウントに制限されずにdiscovery_credentialsテーブルを使用できるなど、PowerShell を使用することの多くの利点が追加されます。このプローブは、WMI_FETCHDATAパラメーターがあるかどうかを確認し、ある場合は MID サーバーで WMIRunner.psm1 スクリプトを実行します。Windows 分類プローブの場合は、リモート機能テストを実行します。

リモート機能テストでは、以下がチェックされます。

リモート管理者共有アクセス PowerShell アクセス Powershell アクセスは、リモートアドミン共有アクセステストが成功した場合にのみテストされます。 これらのテストの結果は、次のパラメーターに入力されます。

admin_share_access target_powershell_access これらのパラメーターは、分類プローブと分類後プローブの両方で使用されます。このパラメーターは、プローブがターゲットから情報を収集する方法と、両方のテストに合格する必要があるプローブを自動的にスキップする方法を決定します。リモート機能チェックのために PowerShell または WindowsCommand プローブがスキップされた場合、次のいずれかのメッセージがディスカバリーステータス履歴に記録されます。

リモート PowerShell プローブにはターゲットでアドミン共有アクセスと PowerShell が必要なため、プローブを起動できません。 ターゲットのアドミン共有に MID サーバーからアクセスできないため、プローブを起動できません。 WMI 属性を収集するプローブ (Windows 分類プローブはその一例です) は、アドミン共有と PowerShell アクセスの両方がターゲットで利用可能な場合にコードパスを実行すると、パフォーマンス上の利点が得られます。次のドキュメントでは、これらの改善点について詳しく説明します。

Windows PowerShell ディスカバリーと従来の Windows ディスカバリーの違い 認証情報 認証情報テーブルの認証情報を使用して Windows コンピューターを検出するには、mid.powershell.use_credentialsパラメーターを true に設定します。認証情報テーブルの認証情報を使用することがデフォルトの動作です。 (mid.powershell.use_credentialsのデフォルトは true です)。

ディスカバリーとサービスマッピングで MID サーバーサービスユーザーの認証情報を強制的に使用するには、MID サーバーで mid.powershell.use_credentials パラメーターを false に設定します。

権限の詳細については、次のドキュメントを参照してください。

Windows 認証情報 Windows プローブと権限 資格情報テスト テストは PowerShell を使用して実行できます。

WMI # ユーザーと変数のセットアップ: $userName = " " $userPassword = " " $targetIP = $securePasswd = ConvertTo-SecureString $userPassword -AsPlainText –Force $cred = New-Object System.Management.Automation.PSCredential ($userName, $securePasswd) $so = New-CimSessionOption -Protocol Dcom

# 認証情報をテスト $session = New-CimSession -ComputerName $targetIP -SessionOption $so -Credential $cred WinRM # ユーザーと変数のセットアップ: $userName = " " $userPassword = " " $securePasswd = ConvertTo-SecureString $userPassword -AsPlainText –Force $cred = New-Object System.Management.Automation.PSCredential ($userName, $securePasswd)

# 認証情報をテスト New-PSSession -ConnectionUri http:// :5985/wsman -Credential $cred リモート機能テスト 管理者共有 MID サーバーにログインします。 ターゲットデバイスの検出に使用したアカウントで PowerShell を開きます。 次を実行します。Test-Path -Path "\\\admin$" を実行します。 Test-Path -Path "\\ \admin$" ターゲット PowerShell アクセス $target = " " $userName = " " $userPassword = " " $securePasswd = ConvertTo-SecureString $userPassword -AsPlainText –Force $cred = New-Object System.Management.Automation.PSCredential ($userName, $securePasswd) $session = New-PSSession -ComputerName $target -Credential $cred -ConfigurationName Microsoft.PowerShell32

Enter-PSSession $session Invoke-Command -Session $session -FilePath c:\file_path\file_Name.ps1 Exit-PSSession プロパティとパラメーター PowerShell の MID サーバーパラメーター MID サーバーパラメーター トラブルシューティング 全体的なトラブルシューティング Shazzam ターゲットサーバーで次のポートが開いていることを確認します。 WMIの場合:135 WinRMの場合(HTTP):5985 WinRMの場合(HTTPS):5986 ターゲットサーバーで次のコマンドを実行して、ポートのステータスを確認します。 "netstat -ano |findstr " ファイアウォールが MID からターゲットへの接続をブロックしていないことを確認する。 MID サーバーで次を実行します。 "telnet " 分類 資格情報がターゲットに対して認証可能であることを確認します。。 MID サーバーにログインします。 「Windows PowerShell ISE」を開きます。 次のいずれかの認証情報テストスクリプトを実行します。 WMIの のWinRMの 資格情報のテストは成功しましたか? はい：続行します いいえ: ネットワークおよび Windows チームと協力してエラーを解決します Windows 管理プロトコルは WMI (mid.windows.management_protocol) ですか? はい: を実行する リモート機能テスト いいえ：続行します MID サーバーと Powershell をデバッグに設定する MID サーバーパラメーターの設定 mid.log.level = debug MID サーバープロパティの設定 mid.property.powershell.log_info = true 問題の再現 MID サーバーログを確認します。 一般的なエラー RPC サーバーを使用できません アクセスが拒否されました。(Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) Get-CimClass:アクセスが拒否されました 追加情報 Powershell スクリプトへの署名 ディスカバリー用 Microsoft Just Enough Administration (JEA)