# トラブルシューティング
## バージョン2.20.0以降におけるRBIの問題について RBIセッションが黒い画面のまま表示されたり、エラーが発生したりする場合は、AppArmorおよびSeccompのファイル設定を更新する必要があります。 バージョン2.20.0以降では、リモートブラウザ分離 (RBI) をサポートするための設定変更が必須となっています。手順の詳細は、[バージョン2.20.0のリリースノートページ](https://docs.keeper.io/release-notes/enterprise/keeper-connection-manager/kcm-version-2.20.0)に記載されています。 *** ## ログを確認 動作が想定どおりでない場合は、最初に必ずログを確認することをお勧めします。Guacamoleやguacdがログに記録したメッセージの中には、障害の内容を正確に説明している情報や、少なくとも問題解決に向けた正しい方向を示してくれる情報があるはずです。 ### Dockerの自動インストールメソッド Dockerの自動インストールメソッドを使用してKeeperコネクションマネージャーをインストールした場合は、`kcm-setup.run`スクリプトを使用してログファイルを確認できます。 すべてのコンテナの最近のログをすべて表示するには以下を実行します。 ``` sudo ./kcm-setup.run logs ``` ログをリアルタイムで追跡するには、`-f`フラグを使用します。 ``` sudo ./kcm-setup.run logs -f ``` 以下で解説するように、コンテナ固有のログを監視して特定の問題をトラブルシューティングできます。 **guacdログ** * コマンド: `sudo ./kcm-setup.run logs guacd` * 用途 * 接続の問題のトラブルシューティング * プロトコル固有のエラーのデバッグ (RDP、VNC、SSH) * セッションの詳細とパフォーマンス指標の分析 * 接続の試行と結果の調査 * guacdに関連するエラーとスタックトレースの確認 **guacamoleログ** * コマンド: `sudo ./kcm-setup.run logs guacamole` * 用途 * ユーザー認証の問題のデバッグ * ユーザーセッションでの操作の監視 * ウェブリクエストの処理と応答のトラブルシューティング * 構成の読み込みと解析結果の調査 * ウェブアプリケーションに関連するエラーとスタックトレースの確認 * HTTP クエストとレスポンスのログの確認 **dbログ** * コマンド: `sudo ./kcm-setup.run logs db` * 用途 * データベース接続の問題のトラブルシューティング * クエリ実行の問題のデバッグ * トランザクション管理の監視 * データベースの起動とシャットダウンのログの調査 * データベースのユーザー認証結果の確認 * パフォーマンス指標の分析 * バックアップと復元操作の確認 * データベースに関連するエラーとスタックトレースの確認 **sslログ** * コマンド: `sudo ./kcm-setup.run logs ssl` * 用途 * SSL/TLS 接続の問題のトラブルシューティング * SSL証明書の読み込みと検証のデバッグ * 安全な接続の確立と終了の調査 * HTTPからHTTPSへのリダイレクトログの確認 * ハンドシェイクと暗号化の詳細の表示 * SSL/TLS に関連するエラーとスタック トレースの確認 * 構成結果の分析 * クライアントとサーバーの接続の詳細を確認 個々のログファイルを確認するには、以下のようにログ出力のタイプを指定してください。 ``` sudo ./kcm-setup.run logs guacd sudo ./kcm-setup.run logs guacamole sudo ./kcm-setup.run logs db sudo ./kcm-setup.run logs ssl ``` Dockerイメージをくまなく調べたい場合は、以下のコマンドで始めます。 ``` sudo docker-compose -p "kcm" -f /etc/kcm-setup/docker-compose.yml ps sudo docker ps sudo docker exec -it /bin/bash etc... ``` #### **Dockerカスタムインストールメソッド** Dockerカスタムインストールメソッドを使用してインストールした場合は、組み込みのdockerおよびdocker-composeのログコマンドを使用できます。 例えば、docker-composeを使用する場合は以下のとおりです。 ``` sudo docker-compose logs guacd sudo docker-compose logs guacamole sudo docker-compose logs db sudo docker-compose logs ssl ``` 通常のdockerコマンドを使用し、「docker ps」でコンテナIDを見つけます。 ``` sudo docker ps CONTAINER ID IMAGE ... 2aca97c20f5c keeper/guacamole-ssl-nginx ... 73538e4af0b7 keeper/guacamole-db-mysql ... 44ab1b150bc9 keeper/guacd ... 85e79b62f058 keeper/guacamole ... ``` 続いて、特定のコンテナを参照してログを取得できます。 ``` sudo docker logs 44ab1b150bc9 sudo docker logs 85e79b62f058 sudo docker logs 73538e4af0b7 sudo docker logs 2aca97c20f5c ``` ## 接続の問題 Keeperコネクションマネージャーが起動中に異常停止している場合、またはどのホストにも接続できない場合は、Linuxマシンが乱数生成に十分なエントロピーを生成できるかどうかを直ちに確認する必要があります。この問題を解決するために、`haveged` パッケージのインストールをお勧めします。 これらのパッケージは、以下のコマンドを使用してインストールできます (CentOS/RHEL)。 ``` sudo yum install epel-release sudo yum install haveged sudo systemctl start haveged sudo systemctl enable haveged ``` ## Docker自動インストールのデバッグ `kcm-setup.run` スクリプトで、`KCM_SETUP_DEBUG` 環境変数がサポートされるようになりました。この変数を有効にすると、詳細モードが有効になり、実行されたすべてのコマンドとその出力が表示されます。このデバッグ出力は `KCM_SETUP_DEBUG` の値に応じてターミナルに直接表示したりファイルに保存したりできます。 ``` export KCM_SETUP_DEBUG=/path/to/file sudo -E ./kcm-setup.run ``` ## 詳細ログ **`LOG_LEVEL`** この変数はオプションであり、表示されるログメッセージの最低レベルを指定します。詳細度の昇順で、有効な値は「error」、「warn」、「info」、「debug」、「trace」です。 デフォルトのログ レベルは「info」です。 ## 管理 ### LDAPとデータベースを連携する場合、LDAPユーザーのリストを取得できない #### ご利用の (管理用) Keeperコネクションマネージャーユーザーカウントに、LDAPユーザーのリストを取得する権限があることを確認します KeeperのLDAPサポートは、LDAPディレクトリ側で適用されているアクセス制御 (パーミッション) を迂回することはできません。つまり、Keeperコネクションマネージャーの管理画面上でLDAPユーザーを一覧表示できるかどうかは、Keeperの「検索用」LDAPユーザーにその権限があるかどうかや、データベースユーザーにその管理権限があるかどうかに関係なく、実際にログインしているLDAPユーザー自身が、その一覧表示権限を持っているかどうかによって決まります。 自分のLDAPアカウントにその権限があるか不明な場合は、実際にそのアカウントを使ってLDAPディレクトリにバインドし、検索クエリを実行してみるのが有効です。このような検索には、標準的なツールである`ldapsearch`を使用するのが一般的です。 {% code overflow="wrap" %} ``` $ ldapsearch -x -LLL -H ldap://YOUR_LDAP_SERVER -D "YOUR_LDAP_DN" -W -b USER_BASE_DN "(objectClass=*)" ``` {% endcode %} ここで、`YOUR_LDAP_SERVER` はLDAPサーバーのホスト名またはIPアドレス、`YOUR_LDAP_DN` はLDAP内における自身のアカウントの完全なDN、`USER_BASE_DN` は対象となるユーザーが格納されているLDAPディレクトリのベースDNを指します（これは、`docker-compose.yml` ファイルの `LDAP_USER_BASE_DN` プロパティ、またはコンテナ内の `/etc/guacamole/guacamole.properties` にある `ldap-user-base-dn` プロパティで指定されている値です）。 #### Keeperコネクションマネージャーへのサインインにデータベース認証情報ではなく、LDAP認証情報を使用していることを確認します データベース内のユーザーアカウントにパスワードが設定されており、そのパスワードをLDAPアカウントのものではなく使用した場合、認証はデータベース側でのみ成功します。これは有効な認証結果ですが、そのセッションではLDAPオブジェクトへのアクセス権がありません。LDAP内のユーザーなどのオブジェクトにアクセスするには、LDAPディレクトリが受け入れる認証情報でログインする必要があります。 #### LDAP関連のプロパティの後に空白が付いていないか確認します Javaの `.properties` ファイルでは、プロパティ値の前にある空白には特別な意味はありませんが、最初の空白以外の文字以降は、たとえ空白であってもすべてプロパティ値の一部として扱われます。 `docker-compose` ファイル内のLDAP関連のプロパティ (結果としてコンテナ内の `/etc/guacamole/guacamole.properties` に反映される内容) がすべて正しく見える場合でも、値の末尾に不要な空白が紛れ込んでいないかを必ず確認してください。 LDAP関連プロパティの末尾に空白が含まれていると、クエリが失敗したり、成功しているように見えるクエリの結果をGuacamoleが誤って解釈する原因となる可能性があります。 ### 「guacadmin」 (または現在のユーザー) のパスワードを変更できない #### 自分のパスワードの変更には、管理ユーザーエディタではなく、\[ユーザ設定] インターフェースを使用します Keeperコネクションマネージャーでは、ユーザーのパスワードを変更する方法が2つ用意されています。1つは他のユーザーのパスワードを変更するためのユーザー編集画面、もう1つは自分の現在のパスワードを確認したうえで変更する **\[ユーザ設定]** 画面です。 このうち、現在のパスワードを確認する機能があるのは **\[ユーザ設定]** のみであるため、自分自身のパスワードを変更する場合、Keeperが許可するのはこの方法だけです。**\[User Editor]** 画面から自分のパスワードを変更しようとすると、権限が拒否されます。 管理者が **\[ユーザ設定]** 画面にアクセスするには、**\[設定]** を開いて **\[ユーザ設定]** を選択してください。 #### 問題のユーザーが自分のパスワードを変更する権限を持っていることを確認します Keeperコネクションマネージャーデータベース内で定義されたユーザーアカウントには、自分自身のパスワードを変更する権限が最初から付与されているとは限りません。自分のパスワードを更新する権限は、管理者によって明示的に付与される必要があります。 管理者として新しく作成したユーザーに自分のパスワードを変更させたい場合は、ユーザー編集画面内で **\[自身のパスワードの変更:]** の権限にチェックを入れてください。 ## リモートデスクトップの到達性と動作 ### RDPでWindowsに接続できない場合 #### セキュリティ方式を指定する 最近のWindowsでは、標準でNLA (Network Level Authentication) が有効になっており、これはRDP専用のセキュリティ方式で、より強力な暗号化を使用し、デスクトップセッションを開始する前に認証を行います。 WindowsのRDPサーバーへの接続が失敗する場合は、接続設定で **\[セキュリティモード:]** に **\[NLA]** または **\[TLS]** を選択してみてください。また、ユーザー名、パスワード、ドメイン (必要な場合) をあらかじめ入力していない場合、接続時にKeeperから入力を求められます。 一方、古いバージョンのWindowsではNLAやTLSがサポートされていないことがあり、その場合は **\[RDP]** を選ばないと接続時のセキュリティ交渉が失敗する可能性があります。 #### RDPサーバー証明書の検証を無効にする NLA (Network Level Authentication) と TLS のセキュリティモードは、どちらもクライアント側でRDPサーバーの証明書を検証する仕組みを備えています。しかし、多くのWindowsサーバーでは自己署名証明書が使用されており、これらは信頼された認証局によって署名されていないため、検証が行えません。 証明書を信頼された認証局で検証できない場合、KeeperはRDP接続を拒否します。 この問題を回避するには、接続設定内の **\[サーバ証明書を無視:]** オプションを有効にすることで、証明書の検証をスキップするよう個別に設定することができます。 #### WindowsファイアウォールのルールによってguacdからのRDP接続がブロックされているか確認します Windowsファイアウォールは、ローカル設定やグループポリシー (GPO) によって、RDP接続の受信をブロックするよう構成されている場合があります。対象のWindowsマシンが過去にRDP経由でアクセスされていた場合でも、特定のサブネットからの接続のみ許可されており、Keeperコネクションマネージャーサーバーがそのサブネット外にあると、RDP接続がブロックされることがあります。 このような場合は、Keeperコネクションマネージャーサーバー (またはその所属するサブネット) からのRDP接続を許可するように、Windowsファイアウォールの設定を見直す必要があります。なお、**Windowsサーバーをインターネット上に公開する必要はありません。** ### RDPでドライブのリダイレクトを使用したファイル転送が機能していない #### ドライブのパスが、「guacd」ユーザーまたは「guacd」グループが書き込み可能なディレクトリを指していることを確認します Keeperコネクションマネージャーのパッケージは、`guacd`のみにアクセスを許可すべきファイルの制御を行うために、[`guacd`ユーザーおよびグループ](https://docs.keeper.io/glyptodon-1.x/security)を作成します。 RDPのドライブリダイレクト機能を構成する場合、指定したドライブパスのディレクトリに対して、このユーザー (またはグループ) に書き込み権限が付与されていないと、`guacd` はそのディレクトリ内のファイルを読み書きできません。これは、`guacd` がリダイレクトされたドライブをエミュレートするために必要です。 RDP接続用のドライブパスとして使用する任意のディレクトリには、適切なアクセス権と所有者の設定を行ってください。 ``` $ sudo chown -R root:guacd /path/to/directory $ sudo chmod 770 /path/to/directory ``` ### HTTPプロキシ使用時におけるKeeperコネクションマネージャー (KSM) への接続問題 [CATALINA\_OPTSを](https://docs.keeper.io/keeper-connection-manager/installation/docker-compose-install/keeper-guacamole#id-.glyptodon-guacamolev2.x-context_path-3)参照