ディスカバリー、サービスマッピング、オーケストレーションの資格情報と権限の問題をトラブルシューティングする方法Issue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Discovery、Service Mapping、Orchestration の一般的な認証情報と権限の問題をトラブルシューティングします。この記事では、一般的なトラブルシューティング手順、認証情報のテスト、および Windows、SSH、SNMP、VMware 認証情報の具体的なガイダンスについて説明します。 Discovery で認証情報の問題をトラブルシューティングする方法のビデオチュートリアルについては、Discovery アプリの起動時の一般的な問題のトラブルシューティング (YouTube) を参照してください。 Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } サポートされているすべてのリリース Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 認証情報 デバイスを検出したり、オーケストレーションアクティビティを実行したりするには、認証情報テーブルに認証情報を追加します。認証情報レコードでは、ユーザー名、パスワード、認証情報タイプ (Windows、SSH、SNMP、VMware)、および認証情報の使用が許可されている MID Server を指定します。 MID Server が起動するとき、または認証情報が変更されると、MID Server は利用可能なすべての認証情報をダウンロードしてキャッシュします。 Discovery、Service Mapping、Orchestration の認証情報はすべて同じ認証情報テーブルを使用します。 注：認証情報の失敗に対するエラーメッセージは、「Adding target to blacklist. No valid credential found for types...」から「Could not find any valid credentials to authenticate the target for types...」に更新されました。動作の変更はありません。 一般的なトラブルシューティング 一般的なトラブルシューティングには、認証情報のテスト、デバイスへの ping、認証情報テストに使用されるポートへの telnet という 3 つの主なアクションが含まれます。各アクションの詳細については、次のセクションを参照してください。 認証情報のテスト 認証情報テーブルに移動します。認証情報を選択します。[認証情報をテスト] を選択します。認証情報テストのフォームフィールドに入力します。[OK] を選択します。 認証情報のテストが失敗した場合は、ユーザー名とパスワードが正しいことを確認してください。認証情報の失敗の原因は、多くの場合、入力ミスです。認証情報が正しく、エラーが続く場合は、さらに調査するために MID Server でデバッグログを有効にしてください。デバッグを有効にして問題を再現した後、MID Server ログを確認してください。デバッグを有効にする前に、次の手順を使用して MID Server がターゲットと通信できることを確認してください。 デバイスに ping を実行 ping により、デバイスがネットワーク上で利用可能であることが確認されます。 MID Server ホストにログインし、コマンドプロンプトを開きます。次のコマンドを実行します：ping <ip_address> ping が成功しない場合は、ターゲットデバイスの管理者に連絡してください。 注：一部の環境では ICMP 要求が無効になっている場合があり、ping が失敗する可能性があります。 ポートへ telnet ping が成功した場合、デバイスはネットワーク上で利用可能であり、MID Server ホストから到達可能です。ただし、ターゲットホストとの通信に使用されるプロトコルは、指定されたポートに接続します。ポートがターゲットホスト上またはネットワークパス上で開いていない可能性があります。 次の telnet コマンドを実行して、ポートが開いているかどうかを確認します： telnet <ip_address> <port_number> 以下は、いくつかのデフォルトポートです。システム管理者がこれらのポートを変更する場合があります。 WMI：135SSH：22VCenter：443WinRM：5985WBEM：5989LDAP：389 telnet テストが失敗した場合は、ターゲットデバイスの管理者とネットワーク管理者に連絡して、次のことを確認してください： デバイス上のファイアウォールが、telnet でテストされたポートでのトラフィックを許可しているMID Server からターゲットホストへのテスト済みポートでのトラフィックをブロックしているネットワークファイアウォールがない 注：Telnet は TCP プロトコルを使用します。UDP 接続は telnet を使用してテストできません。 MID Server デバッグログの収集 MID Server でデバッグログを有効にするには： [MID Server] > [サーバー] に移動します。失敗した Discovery または Orchestration アクティビティに使用された MID Server を選択します。構成パラメータ関連リストで、[新規] を選択します。パラメータ名を mid.log.level に設定し、値を debug に設定します。 デバッグが完了したら、値を info に戻してください。 MID Server ログを収集するには： MID Server レコードで、[MID ログを取得] を選択します。表示された入力レコードを選択します。 Windows 認証情報 MID Server からリモートマシンへの PowerShell WMI クエリにより、アクセスと権限をテストできます。 MID Server ホストで PowerShell コマンドラインを開きます。次のコマンドを実行します。LOCALDOMAIN\mid をテストする認証情報に、192.168.200.14 をターゲット IP アドレスに置き換えます： gwmi win32_operatingsystem -computer 192.168.200.14 -credential 'LOCALDOMAIN\mid' 期待される結果は次のようになります： SystemDirectory : C:\Windows\system32 Organization : BuildNumber : 6001 RegisteredUser : Windows User SerialNumber : 12345-OEM-1234567-12345 Version : 6.0.6001 WMI コマンドが失敗した場合、認証情報が正しくないか、必要な権限がありません。Windows 管理チームに連絡して、さらに調査してください。MID Server からターゲットホストへの基本的な WMI クエリが失敗した場合、Discovery および Orchestration アクティビティは成功しません。 ServiceNow Windows 認証情報に関する詳細ドキュメント 次の記事では、Windows 認証情報エラーの詳細なトラブルシューティングを提供します： KB0549834 - MID サーバー：WMI/PowerShell の問題のトラブルシューティング：資格情報KB0549830 - リモートマシンでの WMI/Powershell の問題のトラブルシューティングリモートサーバーアクセス用に Windows Firewall でポートを開く方法 - WMI、PowerShell、および Windows ファイアウォール 次の製品ドキュメントでは、Windows 認証情報の権限要件について説明します： Permission requirements for Windows credentials (Windows 認証情報の権限要件)Discovery Windows probes and permissions (Discovery の Windows プローブと権限)Additional Discovery probe permissions (追加の Discovery プローブ権限) SSH 認証情報 認証を確認 SH 認証情報エラーのトラブルシューティングを行うには、SSH クライアント (PuTTY など) を使用して、MID Server ホストからターゲット IP アドレスに接続します。認証情報テーブルで構成されているものと同じユーザー名とパスワードの組み合わせを使用します。ターゲットシステムへのアクセスは、すべての Discovery または Orchestration アクティビティに必要です。 認可と権限を確認 ユーザーはターゲットシステムにログインできても、Discovery または Orchestration が試行するコマンドを実行する権限を持っていない場合があります。ユーザーが要件を満たしていることを確認するには、次のドキュメントを参照してください： 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 Server パラメータ mid.ssh.use_snc は、個々の MID Server で ServiceNow SSH クライアント (SNCSSH) を有効にします。SNCSSH は ServiceNow による SSH クライアントの実装であり、新しいインスタンスのすべての MID Server でデフォルトでアクティブです。ServiceNow SSH クライアントを有効にすると、レガシー J2SSH クライアントが無効になります。 重要：同じインスタンスに接続されている MID Server で SSH クライアントタイプを混在させないでください。 デフォルト値は、Eureka リリース以降の新しいインスタンスでは true、それ以前の既存のインスタンスでは false です。 秘密鍵認証情報 場合によっては、sudo コマンドに提供するパスワードがないため、sudo コマンドが秘密鍵認証情報で機能しません。これを解決するには、sudo 構成に NOPASSWD オプションを追加するか、認証情報にパスワードを提供します。例： disco ALL=(root) NOPASSWD:/usr/sbin/dmidecode,/usr/sbin/lsof,/sbin/ifconfig この例では、ユーザー disco はパスワードを提供せずに sudo を介して dmidecode を実行できます。秘密鍵認証情報を使用するときにコマンドが失敗した場合は、ユーザーがパスワードを提供せずにコマンドを実行できることを確認してください。 アカウントがターゲットへのログインに成功し、プローブまたは Orchestration アクティビティで使用されるコマンドを実行できても、MID Server を使用すると失敗する場合は、MID Server デバッグログの収集のセクションに従ってください。詳細については、パラメータ mid.ssh.debug = true を追加してください。 SNMP 認証情報 SNMP は UDP を使用します。UDP は、TCP のようにターゲットホストへの仮想接続を作成しません。認証情報が正しくないか、認可されていない場合、使用されている SNMP バージョンによっては応答が返されない可能性があります。無効な認証情報を使用すると、Discovery ログにタイムアウトが表示される場合があります。 タイムアウトの一般的な理由は次のとおりです： 認証情報が有効でないネットワークまたはターゲットサーバーがビジー状態で、タイムアウト内に OID を返さない ターゲットに SNMP クエリを実行 MID Server から SNMP ツールを使用して、OID 1.3.6.1.2.1.1.1 (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%Failed to get value of SNMP variable. Timedout. 認証情報の失敗エラーは返されません。代わりに、クエリがタイムアウトします。 次の例では、コミュニティ文字列が「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 コミュニティ文字列を修正すると、タイムアウトする代わりに sysDescr 値が返されました。 SNMP パラメータ SNMP 要求のタイムアウトは、timeout プローブパラメータを使用して増やすことができます。デフォルト値は 1500 (1.5 秒) です。認証情報が正しいことがわかっているが OID が返されない場合は、タイムアウトを増やしてみてください。表形式データの場合は、use_getbulk パラメータを使用して効率を向上させてみてください。 SNMP プローブパラメータの詳細については、SNMP probes を参照してください。 プローブから結果が返されない 場合によっては、Discovery ログに「No result returned from probe」という警告が表示されることがあります。これは、プローブによってクエリされた OID の入力が空を返す場合に発生します。デバイスには、指定された OID に対して返す結果がなく、この動作は想定されています。Discovery が正しくない可能性があると思われる場合は、同じ OID に対するクエリをターゲット IP アドレスに対して実行して、出力を確認してください。 SNMP 認証情報の詳細ドキュメント Discovery、Service Mapping、Orchestration の MID Server SNMP の問題をトラブルシューティングする方法 VMware 認証情報 認証を確認 認証情報テーブルで構成されているのと同じアカウントが VCenter ターゲットにログインできることを確認します： MID Server ホストにログインします。ブラウザを開き、次の URL に移動します。<V-Center_IP_Address> を VCenter サーバーの IP アドレスに置き換えます： https://<V-Center_IP_Address>/mob 認証情報テーブルレコードで構成されているものと同じユーザー名、パスワード、形式を使用します。 テストが失敗した場合は、VMware チームに連絡して、トラブルシューティングを行うか、認証情報へのアクセスを提供してください。テストが成功しても Discovery が失敗する場合は、さらに調査するために MID Server デバッグログの収集のセクションに従ってください。 詳細ドキュメント vCenter Discovery プロセスとトラブルシューティングを理解する認証およびセッション失敗のための UCS-HD Discovery エラー 551 および 555 を解決する方法