Issue
この記事では、特定の資格情報の種類と、ディスカバリー、サービスマッピング、オーケストレーションにおける認証情報/権限のトラブルシューティング この記事では、特定の資格情報の種類と、ディスカバリー、オーケストレーション、サービス マッピングの一般的な資格情報と権限の問題のトラブルシューティング手順について説明します。 ディスカバリーでの資格情報の問題のトラブルシューティングに関するチュートリアルについては、以下のビデオをご覧ください。 デバイスを検出したり、オーケストレーションアクティビティを実行したりするには、認証情報テーブルに認証情報を追加します。 これらの認証情報レコードでは、ユーザー名、パスワード、認証情報の種類 (Windows、SSH など)、およびこの認証情報を使用できる MID サーバーを指定します。 MID サーバーが起動するか、認証情報が変更されると、MID サーバーは利用可能なすべての認証情報をダウンロードしてキャッシュします。 ディスカバリー、サービスマッピング、およびオーケストレーションの認証情報はすべて、同じ認証情報テーブルを指します。 一般的なトラブルシューティングには、資格情報のテスト、デバイスへの ping、資格情報テストに使用されるポートへの Telnet という 3 つの主なアクションが含まれます。 各アクションとそれらを正しく実行する手順については、以下の各セクションを参照してください。 認証情報テストが失敗した場合は、認証情報に正しいユーザー名とパスワードが入力されていることを確認します。多くの場合、誤入力が認証情報エラーの原因です。認証情報フィールドが正しいことを確認した後も認証情報エラーが続く場合は、MID サーバーでデバッグをオンにしてさらに調査できます。デバッグをオンにして問題が再現された場合、MID サーバーのログを確認します。ただし、デバッグをオンにする前に、次のステップに従って、MID サーバーがターゲットと通信できることを確認してください。 ping によって、デバイスがネットワークで使用可能であることを確認します。 ping が成功しない場合は、ターゲットデバイスの管理者に問い合わせてください。 Obs:一部の環境では ICMP 要求が無効になっており、ping が失敗する場合があります。 ping が成功した場合、デバイスはネットワーク内で利用可能であり、MID サーバーホストから到達可能です。しかし、ターゲットホストとの通信に使用されるプロトコルは、指定されたポートに接続する必要があります。デバイスに到達するために使用されるターゲットホストまたはネットワークパスで、そのようなポートが開かれていないかもしれません。telnet テストでは、ポートが開いているかどうかを確認します。 以下は、初期設定で使用されるポートの一部ですが、システム管理者はこれらのポートを変更できます。 WMI:135 telnet テストに失敗した場合、エラーメッセージが表示されます。ターゲットデバイスの管理者およびネットワーク管理者に問い合わせて、次のことを確認してください。 注:Telnet は、TCP プロトコルを使用して動作するアプリケーションです。UDP 接続の場合、Telnet を使用してテストすることはできません。 MID サーバーでデバッグをオンにするには、以下の手順に従います。 MID サーバーのログを収集するには、以下の手順に従います。 MID サーバーからリモートマシンに直接、簡単な Powershell WMI クエリを使用して、アクセスと権限をテストできます。 MID サーバーを使用しているホストで PowerShell コマンドラインを開き、次のコマンドを実行します。 LOCALDOMAIN\\mid をテスト対象の認証情報に置き換え、192.168.200.14 をターゲット IP アドレスに置き換えます。期待される結果は次のようになります。 上記の WMI コマンドが失敗した場合は、認証情報が正しくないか、アクセス許可がありません。この問題をさらに調査するために、Windows 管理者チームに連絡してください。MID サーバーからターゲットホストへの基本的な WMI クエリが失敗した場合、ディスカバリーおよびオーケストレーションのアクティビティは成功しません。 以下は、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 クライアントを使用し、使用されている MID サーバーからターゲット IP アドレスに接続し、アカウントがターゲットホスト (puty など) に正常にログインできることを確認します。認証情報テーブルで設定されているものと同じユーザー名とパスワードの組み合わせを使用してください。ディスカバリーまたはオーケストレーションのアクティビティを機能させるには、ターゲットシステムへのアクセスが必要です。 ユーザーはターゲットシステムにログインできても、ディスカバリーまたはオーケストレーションによって試行されるコマンドを実行する権限を持っていない場合があります。次のリンクを参照して、ユーザーが要件を満たしているかどうかを確認してください。 Access Requirements for Non-Root Credentials (ルート以外の認証情報のアクセス要件) Unix ベースのデバイスでユーザーが実行できるコマンドを確認するには、そのユーザーでターゲットホストにログインし、次のコマンドを実行します。 出力には、ユーザーが sudo を使用して実行できる特権コマンドが示されます。 mid.ssh.use_snc は、個々の MID Server 上の ServiceNow SSH クライアント (SNCSSH) を有効にします。SNCSSH は ServiceNow により実装された SSH クライアントであり、mid.ssh.use_snc によって新しいインスタンスのすべての MID サーバーに対してデフォルトで有効になっています。ServiceNow SSH クライアントを有効にすると、従来の J2SSH クライアントは無効になります。 SNMP は UDP を使用します。UDP はターゲットホストへの仮想接続を TCP として作成しないため、使用するバージョンによっては、認証情報が正しくないか許可されない場合、応答が返されないことがあります。無効な認証情報を使用すると、ディスカバリーログにタイムアウトが記録されることがあります。 タイムアウトが発生する理由には、次のようなものがあります。 ターゲットに対して SNMP クエリを実行します。 SNMP ツールを使用して、MID サーバーから OID 1.3.6.1.2.1.1.1 にクエリを実行します。この OID は sysDescr であり、デバイスの説明を返します。 次の例では SnmpWalk.exe を使用していますが、「publi」は正しいコミュニティ文字列ではないため、この例の正しいパブリック文字列として「public」とする必要があります。 上記のように、認証情報の失敗エラーはありません。エラーの代わりに、クエリは最終的にタイムアウトします。 次の例では、 public 文字列が「public」に修正されました。 上記のように、public 文字列が修正されると、sysDescr が返され、その一部のみが上に示されます。 SNMP パラメーター: SNMP 要求の「タイムアウト」は、「timeout」プローブパラメーターを使用して増やすことができます。デフォルト値は 1500 (1.5 秒) です。認証情報が正しいことがわかっていても OID が返されない場合は、タイムアウトを増やしてみてください。表形式のデータの場合は、効率を向上させるために「use_getbulk」パラメーターを試してください。 SNMP プローブパラメーターの詳細については、SNMP probes (SNMP プローブ) を参照してください。 場合によっては、ディスカバリーログに「プローブから結果が返されません」という警告が記録されることがあります。これは、プローブによってクエリされた OID に対して入力が空で返された場合に表示されます。これは、指定された OID に対して返す結果をデバイスが持っていないために発生します。ディスカバリーが間違っている可能性がある場合は、ターゲット IP アドレスに対して同じ OID のクエリを実行して、出力を確認します。 認証の確認: 認証情報テーブルで設定された同じアカウントが vCenter ターゲットにログインできることを確認します。 上記のテストが失敗した場合は、vmware チームにトラブルシューティングを依頼するか、認証情報へのアクセスを提供してください。上記のテストが成功してもディスカバリーが失敗する場合は、MID サーバーのデバッグログの収集の手順に従ってさらに調査してください。 Issue
認証情報
\r\n一般的なトラブルシューティング
\r\n認証情報のテスト:
\r\n
\r\nデバイスに対して ping を実行:
\r\n
\r\nping <ip_address>
\r\n認証情報テストに使用するポートに Telnet で接続:
\r\ntelnet <ip_address> <port_number>
\r\n
SSH:22
VCenter:443
WinRM:5985
WBEM:5989
LDAP:389
\r\nMID サーバーのデバッグログの収集
\r\n
\r\n
\r\nWindows 認証情報
\r\ngwmi win32_operatingsystem -computer 192.168.200.14 -credential 'LOCALDOMAIN\\mid'
\r\nSystemDirectory : C:\\Windows\\system32 Organization : BuildNumber : 6001 RegisteredUser : Windows User SerialNumber : 12345-OEM-1234567-12345 Version : 6.0.6001
\r\nServiceNow Windows 資格情報に関する詳細ドキュメント
\r\nSSH 認証情報
\r\n認証の確認:
\r\n認証/許可の確認:
\r\n
UNIX and Linux commands requiring root privileges for Discovery and Orchestration (ディスカバリーとオーケストレーションのためにルート権限が必要な UNIX コマンドと Linux コマンド)sudo -l
\r\nSSH のどの実装が使用されているかを確認します。
\r\nプライベートキー認証情報:
\r\ndisco ALL=(root) NOPASSWD:/usr/sbin/dmidecode,/usr/sbin/lsof,/sbin/ifconfig.
\r\n最後に:
\r\nSNMP 認証情報
\r\n
\r\nC:\\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
\r\n
%SNMP 変数の値の取得に失敗しました。タイムアウトしました。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.0
\r\n
OID=.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プローブから結果が返されません。
\r\nSNMP 認証情報に関する追加ドキュメント
\r\n\r\nVMware 認証情報
\r\n
\r\n詳細なドキュメント
\r\n\r\nその他の認証情報
\r\n