ディスカバリー、サービスマッピング、オーケストレーションにおける認証情報/権限のトラブルシューティングDescriptionこの記事では、特定の資格情報の種類と、ディスカバリー、オーケストレーション、サービス マッピングの一般的な資格情報と権限の問題のトラブルシューティング手順について説明します。 ディスカバリーでの資格情報の問題のトラブルシューティングに関するチュートリアルについては、以下のビデオをご覧ください。 認証情報 デバイスを検出したり、オーケストレーションアクティビティを実行したりするには、認証情報テーブルに認証情報を追加します。 これらの認証情報レコードでは、ユーザー名、パスワード、認証情報の種類 (Windows、SSH など)、およびこの認証情報を使用できる MID サーバーを指定します。 MID サーバーが起動するか、認証情報が変更されると、MID サーバーは利用可能なすべての認証情報をダウンロードしてキャッシュします。 ディスカバリー、サービスマッピング、およびオーケストレーションの認証情報はすべて、同じ認証情報テーブルを指します。 注：認証情報に問題があった場合、エラーメッセージは「ブラックリストにターゲットを追加しています。タイプの有効な認証情報が見つかりません...」から「タイプのターゲットを認証するための有効な認証情報が見つかりませんでした...」に変わりますが、動作に変更はありません。 一般的なトラブルシューティング 一般的なトラブルシューティングには、資格情報のテスト、デバイスへの ping、資格情報テストに使用されるポートへの Telnet という 3 つの主なアクションが含まれます。 各アクションとそれらを正しく実行する手順については、以下の各セクションを参照してください。 認証情報のテスト： 認証情報テーブルに移動します。 認証情報を選択します。[認証情報をテスト] をクリックします。 認証情報テストのフォームフィールドに入力します。[OK] をクリックします。 認証情報テストが失敗した場合は、認証情報に正しいユーザー名とパスワードが入力されていることを確認します。多くの場合、誤入力が認証情報エラーの原因です。認証情報フィールドが正しいことを確認した後も認証情報エラーが続く場合は、MID サーバーでデバッグをオンにしてさらに調査できます。デバッグをオンにして問題が再現された場合、MID サーバーのログを確認します。ただし、デバッグをオンにする前に、次のステップに従って、MID サーバーがターゲットと通信できることを確認してください。 デバイスに対して ping を実行： ping によって、デバイスがネットワークで使用可能であることを確認します。 MID サーバーホストにログインし、コマンドプロンプトを開いて次のコマンドを実行します。 ping <ip_address> ping が成功しない場合は、ターゲットデバイスの管理者に問い合わせてください。 Obs：一部の環境では ICMP 要求が無効になっており、ping が失敗する場合があります。 認証情報テストに使用するポートに Telnet で接続： ping が成功した場合、デバイスはネットワーク内で利用可能であり、MID サーバーホストから到達可能です。しかし、ターゲットホストとの通信に使用されるプロトコルは、指定されたポートに接続する必要があります。デバイスに到達するために使用されるターゲットホストまたはネットワークパスで、そのようなポートが開かれていないかもしれません。telnet テストでは、ポートが開いているかどうかを確認します。 telnet <ip_address> <port_number> 以下は、初期設定で使用されるポートの一部ですが、システム管理者はこれらのポートを変更できます。 WMI：135SSH：22VCenter：443WinRM：5985WBEM：5989LDAP：389 telnet テストに失敗した場合、エラーメッセージが表示されます。ターゲットデバイスの管理者およびネットワーク管理者に問い合わせて、次のことを確認してください。 デバイスのファイアウォールが、telnet によってテストしたポートでのトラフィックを許可していることテストしたポート上での MID サーバーからターゲットホストへのトラフィックをブロックしているネットワークファイアウォールがないこと 注：Telnet は、TCP プロトコルを使用して動作するアプリケーションです。UDP 接続の場合、Telnet を使用してテストすることはできません。 MID サーバーのデバッグログの収集 MID サーバーでデバッグをオンにするには、以下の手順に従います。 [MID サーバーリスト] > [MID サーバー] > [サーバー] に移動します。 失敗したディスカバリーまたはオーケストレーションのアクティビティに使用した MID サーバーを選択します。[設定パラメーター] 関連リストを選択し、[新規] をクリックします。 [パラメーター名 = mid.log.level] を選択し、値を「debug」に設定します。 デバッグが完了したら、この値を「info」に戻します。 MID サーバーのログを収集するには、以下の手順に従います。 MID サーバーレコードで、[MID ログの入手] をクリックします。 表示された入力レコードをクリックします。 Windows 認証情報 MID サーバーからリモートマシンに直接、簡単な Powershell WMI クエリを使用して、アクセスと権限をテストできます。 MID サーバーを使用しているホストで PowerShell コマンドラインを開き、次のコマンドを実行します。 gwmi win32_operatingsystem -computer 192.168.200.14 -credential 'LOCALDOMAIN\mid' LOCALDOMAIN\mid をテスト対象の認証情報に置き換え、192.168.200.14 をターゲット IP アドレスに置き換えます。期待される結果は次のようになります。 SystemDirectory : C:\Windows\system32 Organization : BuildNumber : 6001 RegisteredUser : Windows User SerialNumber : 12345-OEM-1234567-12345 Version : 6.0.6001 上記の WMI コマンドが失敗した場合は、認証情報が正しくないか、アクセス許可がありません。この問題をさらに調査するために、Windows 管理者チームに連絡してください。MID サーバーからターゲットホストへの基本的な WMI クエリが失敗した場合、ディスカバリーおよびオーケストレーションのアクティビティは成功しません。 ServiceNow Windows 資格情報に関する詳細ドキュメント 以下は、Windows 資格情報エラーに関する詳細なトラブルシューティング記事のコレクションです。 KB0549834 - MID サーバー：WMI/PowerShell の問題のトラブルシューティング：資格情報 KB0549830 - リモートマシンでの WMI/Powershell の問題のトラブルシューティング KB0549828 - WMI、PowerShell、および Windows ファイアウォール 以下は、Windows 資格情報の権限要件に関する詳細情報を含む製品ドキュメントの記事のコレクションです。 Permission requirements for Windows credentials (Windows 認証情報の権限要件) Discovery Windows probes and permissions (Discovery の Windows プローブと権限) Additional Discovery probe permissions (追加の Discovery プローブ権限) SSH 認証情報 認証の確認： SSH 認証情報エラーのトラブルシューティングを行うには、任意の SSH クライアントを使用し、使用されている MID サーバーからターゲット IP アドレスに接続し、アカウントがターゲットホスト (puty など) に正常にログインできることを確認します。認証情報テーブルで設定されているものと同じユーザー名とパスワードの組み合わせを使用してください。ディスカバリーまたはオーケストレーションのアクティビティを機能させるには、ターゲットシステムへのアクセスが必要です。 認証/許可の確認： ユーザーはターゲットシステムにログインできても、ディスカバリーまたはオーケストレーションによって試行されるコマンドを実行する権限を持っていない場合があります。次のリンクを参照して、ユーザーが要件を満たしているかどうかを確認してください。 Access Requirements for Non-Root Credentials (ルート以外の認証情報のアクセス要件)UNIX and Linux commands requiring root privileges for Discovery and Orchestration (ディスカバリーとオーケストレーションのためにルート権限が必要な UNIX コマンドと Linux コマンド) Unix ベースのデバイスでユーザーが実行できるコマンドを確認するには、そのユーザーでターゲットホストにログインし、次のコマンドを実行します。 sudo -l 出力には、ユーザーが sudo を使用して実行できる特権コマンドが示されます。 SSH のどの実装が使用されているかを確認します。 mid.ssh.use_snc は、個々の MID Server 上の ServiceNow SSH クライアント (SNCSSH) を有効にします。SNCSSH は ServiceNow により実装された SSH クライアントであり、mid.ssh.use_snc によって新しいインスタンスのすべての MID サーバーに対してデフォルトで有効になっています。ServiceNow SSH クライアントを有効にすると、従来の J2SSH クライアントは無効になります。 重要：同じインスタンスに接続されている複数の MID サーバーの SSH クライアントタイプを混在させることは良い方法ではありません。 Eureka 以降の新しいインスタンスのデフォルトは「有効」、以前の既存のインスタンスのデフォルトは「無効」です。 プライベートキー認証情報： sudo コマンドに入力するパスワードがないため、sudo コマンドはプライベートキー認証情報で動作しないことがあります。解決策は、NOPASSWD オプションを sudo 構成に追加するか、認証情報にパスワードを入力することです。たとえば、次のように入力します。 disco ALL=(root) NOPASSWD:/usr/sbin/dmidecode,/usr/sbin/lsof,/sbin/ifconfig. 上記の例では、ユーザー disco は、パスワードを入力せずに sudo を介して dmidecode を実行できます。プライベートキー認証情報を使用しているときにコマンドが失敗した場合は、ユーザーがパスワードを入力せずにコマンドを実行できることを確認します。 最後に： アカウントがターゲットに正常にログインし、実行中のプローブまたはオーケストレーションで使用されるコマンドを実行できても、MID サーバーの使用時に失敗する場合は、「MID サーバーログの収集」セクションに従ってさらにトラブルシューティングを行います。 さらに詳しく調べるには、パラメーター mid.ssh.debug = true を追加してください。 SNMP 認証情報 SNMP は UDP を使用します。UDP はターゲットホストへの仮想接続を TCP として作成しないため、使用するバージョンによっては、認証情報が正しくないか許可されない場合、応答が返されないことがあります。無効な認証情報を使用すると、ディスカバリーログにタイムアウトが記録されることがあります。 タイムアウトが発生する理由には、次のようなものがあります。 認証情報が有効ではないネットワークまたはターゲットサーバーがビジー状態であり、タイムアウト内に OID を返さない ターゲットに対して SNMP クエリを実行します。 SNMP ツールを使用して、MID サーバーから OID 1.3.6.1.2.1.1.1 にクエリを実行します。この OID は sysDescr であり、デバイスの説明を返します。 次の例では SnmpWalk.exe を使用していますが、「publi」は正しいコミュニティ文字列ではないため、この例の正しいパブリック文字列として「public」とする必要があります。 C:\SNMPWalk>.\SnmpWalk.exe -r:10.127.212.181 -c:"publi" -os:.1.3.6.1.2.1.1 -op:.1.3.6.1.2.1.1.1.0%SNMP 変数の値の取得に失敗しました。タイムアウトしました。 上記のように、認証情報の失敗エラーはありません。エラーの代わりに、クエリは最終的にタイムアウトします。 次の例では、 public 文字列が「public」に修正されました。 C:\SNMPWalk>.\SnmpWalk.exe -r:10.127.212.181 -c:"public" -os:.1.3.6.1.2.1.1 -op:.1.3.6.1.2.1.1.1.0OID=.1.3.6.1.2.1.1.1.0, Type=OctetString, Value=Linux Linux-Tomcat 3.10.0-327.el7.x86_64 31 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 上記のように、public 文字列が修正されると、sysDescr が返され、その一部のみが上に示されます。 SNMP パラメーター： SNMP 要求の「タイムアウト」は、「timeout」プローブパラメーターを使用して増やすことができます。デフォルト値は 1500 (1.5 秒) です。認証情報が正しいことがわかっていても OID が返されない場合は、タイムアウトを増やしてみてください。表形式のデータの場合は、効率を向上させるために「use_getbulk」パラメーターを試してください。 SNMP プローブパラメーターの詳細については、SNMP probes (SNMP プローブ) を参照してください。 プローブから結果が返されません。 場合によっては、ディスカバリーログに「プローブから結果が返されません」という警告が記録されることがあります。これは、プローブによってクエリされた OID に対して入力が空で返された場合に表示されます。これは、指定された OID に対して返す結果をデバイスが持っていないために発生します。ディスカバリーが間違っている可能性がある場合は、ターゲット IP アドレスに対して同じ OID のクエリを実行して、出力を確認します。 SNMP 認証情報に関する追加ドキュメント KB0696727: MID Server SNMP Troubleshooting (MID サーバー SNMP のトラブルシューティング) VMware 認証情報 認証の確認： 認証情報テーブルで設定された同じアカウントが vCenter ターゲットにログインできることを確認します。 MID サーバーホストにログインします。ブラウザを開いて https://<V-Center_IP_Address>/mob に移動し、アドレスを vCenter サーバの IP アドレスに置き換えます 認証情報テーブルのレコードと全く同じユーザー名とパスワードの組み合わせ、および同じ形式を使用してください。 上記のテストが失敗した場合は、vmware チームにトラブルシューティングを依頼するか、認証情報へのアクセスを提供してください。上記のテストが成功してもディスカバリーが失敗する場合は、MID サーバーのデバッグログの収集の手順に従ってさらに調査してください。 詳細なドキュメント VCenter Discovery (vCenter ディスカバリー) その他の認証情報 UCS-HD