翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Active Directory を使用したマルチユーザー統合のトラブルシューティング
このセクションは、Active Directory と統合されたクラスターに関連するものです。
Active Directory 統合機能が期待どおりに動作していない場合、SSSD ログは役立つ診断情報を提供します。これらのログは、クラスターノードの `/var/log/sssd` に配置されています。デフォルトでは、クラスターの Amazon CloudWatch ロググループにも保存されます。
**Topics**
+ [Active Directory 固有のトラブルシューティング](#troubleshooting-v3-multi-ad-specific)
+ [デバッグモードを有効にする](#troubleshooting-v3-multi-user-debug)
+ [LDAPS から LDAP に移行する方法](#troubleshooting-v3-multi-user-ldaps-ldap)
+ [LDAPS サーバー証明書の検証を無効にする方法](#troubleshooting-v3-multi-user-ldaps-verify)
+ [パスワードではなく SSH キーを使用してログインする方法](#troubleshooting-v3-multi-user-ssh-login)
+ [ユーザーパスワードと失効しているパスワードをリセットする方法](#troubleshooting-v3-multi-user-reset-passwd)
+ [参加しているドメインを確認する方法](#troubleshooting-v3-multi-user-domain-verify)
+ [証明書に関する問題をトラブルシューティングする方法](#troubleshooting-v3-multi-user-certificates)
+ [Active Directory との統合が動作していることを確認する方法](#troubleshooting-v3-multi-user-ad-verify)
+ [コンピューティングノードへのログインのトラブルシューティング方法](#troubleshooting-v3-multi-user-ad-compute-node-login)
+ [マルチユーザー環境での SimCenter StarCCM\$1 ジョブに関する既知の問題](#troubleshooting-v3-multi-user-ad-starccm)
+ [ユーザー名解決に関する既知の問題](#troubleshooting-v3-multi-user-name-resolution)
+ [ホームディレクトリ作成の問題の解決方法](#troubleshooting-v3-multi-home-directory)
## Active Directory 固有のトラブルシューティング
このセクションは、Active Directory タイプ固有のトラブルシューティングに関連するものです。
### Simple AD
+ `DomainReadOnlyUser` 値は、ユーザーの Simple AD ディレクトリベース検索と一致している必要があります。
`cn=ReadOnlyUser,cn=Users,dc=corp,dc=example,dc=com`
`Users` の `cn` に注意してください。
+ デフォルトの管理者ユーザーは `Administrator` です。
+ `Ldapsearch` ユーザー名の前に NetBIOS 名が必要です。
`Ldapsearch` の構文は次のようである必要があります。
```
$ ldapsearch -x -D "corp\\Administrator" -w "Password" -H ldap://192.0.2.103 \
-b "cn=Users,dc=corp,dc=example,dc=com"
```
### AWS Managed Microsoft AD
+ `DomainReadOnlyUser` 値は、ユーザーの AWS Managed Microsoft AD ディレクトリベース検索と一致する必要があります。
`cn=ReadOnlyUser,ou=Users,ou=CORP,dc=corp,dc=example,dc=com`
+ デフォルトの管理者ユーザーは `Admin` です。
+ `Ldapsearch` の構文は次のようである必要があります。
```
$ ldapsearch -x -D "Admin" -w "Password" -H ldap://192.0.2.103 \
-b "ou=Users,ou=CORP,dc=corp,dc=example,dc=com"
```
## デバッグモードを有効にする
SSSD からのデバッグログは問題をトラブルシューティングするのに役立ちます。デバッグモードを有効にするには、クラスター設定に次の変更を加えてクラスターを更新する必要があります。
```
DirectoryService:
AdditionalSssdConfigs:
debug_level: "0x1ff"
```
## LDAPS から LDAP に移行する方法
LDAP だけでは暗号化を提供できないため、LDAPS (TLS/SSL を使用する LDAP) から LDAP への移行は推奨されていません。それでも、テスト目的やトラブルシューティングに役立ちます。
クラスターを以前の設定定義で更新することにより、クラスターを以前の設定に復元できます。
LDAPS から LDAP に移行するには、クラスター設定に次の変更を加えてクラスターを更新する必要があります。
```
DirectoryService:
LdapTlsReqCert: never
AdditionalSssdConfigs:
ldap_auth_disable_tls_never_use_in_production: True
```
## LDAPS サーバー証明書の検証を無効にする方法
テストまたはトラブルシューティングの目的でヘッドノードでの LDAPS サーバー証明書の検証を一時的に無効にすることは役立ちます。
クラスターを以前の設定定義で更新することにより、クラスターを以前の設定に復元できます。
LDAPS サーバー証明書の検証を無効にするには、クラスター設定に次の変更を加えてクラスターを更新する必要があります。
```
DirectoryService:
LdapTlsReqCert: never
```
## パスワードではなく SSH キーを使用してログインする方法
SSH キーは、パスワードを使用して初めてログインした後、`/home/$user/.ssh/id_rsa` に作成されます。SSH キーを使用してログインするには、パスワードを使用してログインし、SSH キーをローカルにコピーしてから、通常どおりパスワードなしで SSH キーを使用する必要があります。
```
$ ssh -i $LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip
```
## ユーザーパスワードと失効しているパスワードをリセットする方法
ユーザーがクラスターにアクセスできなくなった場合、[AWS Managed Microsoft AD パスワードが失効している可能性があります](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_password_policies.html)。
パスワードをリセットするには、ディレクトリの書き込みアクセス許可を持つユーザーとロールを使用し、次のコマンドを実行します。
```
$ aws ds reset-user-password \
--directory-id "d-abcdef01234567890" \
--user-name "USER_NAME" \
--new-password "NEW_PASSWORD" \
--region "region-id"
```
[`DirectoryService`](DirectoryService-v3.md)/[`DomainReadOnlyUser`](DirectoryService-v3.md#yaml-DirectoryService-DomainReadOnlyUser) のパスワードをリセットする場合。
1. 必ず新しいパスワードで [`DirectoryService`](DirectoryService-v3.md)/[`PasswordSecretArn`](DirectoryService-v3.md#yaml-DirectoryService-PasswordSecretArn) シークレットを更新します。
1. 新しいシークレット値にクラスターを更新します。
1. `pcluster update-compute-fleet` コマンドを使用してコンピューティングフリートを停止します。
1. クラスターヘッドノード内から、次のコマンドを実行します。
```
$ sudo /opt/parallelcluster/scripts/directory_service/update_directory_service_password.sh
```
パスワードのリセットとクラスターの更新の後、ユーザーのクラスターアクセスは復元されています。
詳細については、「Directory Service 管理ガイド**」の「[ユーザーパスワードをリセットする](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_reset_password.html)」を参照してください。
## 参加しているドメインを確認する方法
次のコマンドは、ヘッドノードではなく、ドメインに参加しているインスタンスから実行する必要があります。
```
$ realm list corp.example.com \
type: kerberos \
realm-name: CORP.EXAMPLE.COM \
domain-name: corp.example.com \
configured: kerberos-member \
server-software: active-directory \
client-software: sssd \
required-package: oddjob \
required-package: oddjob-mkhomedir \
required-package: sssd \
required-package: adcli \
required-package: samba-common-tools \
login-formats: %U \
login-policy: allow-realm-logins
```
## 証明書に関する問題をトラブルシューティングする方法
LDAPS 通信が動作していない場合、TLS 通信のエラーが原因である可能性があり、それは証明書の問題である可能性があります。
**証明書に関する注意事項。**
+ クラスターの設定 `LdapTlsCaCert` で指定する証明書は、ドメインコントローラーの証明書を発行した認証局 (CA) チェーンの証明書全体を含む PEM 証明書のバンドルである必要があります。
+ PEM 証明書のバンドルとは PEM 証明書を連結したファイルのことです。
+ PEM 形式の証明書 (通常 Linux で使用) は base64 DER 形式の証明書 (通常 Windows でエクスポート) と同等です。
+ ドメインコントローラーの証明書が下位 CA によって発行された場合、証明書バンドルには下位およびルート CA の両方の証明書が含まれている必要があります。
**トラブルシューティングの検証手順:**
次の検証手順は、コマンドがクラスターヘッドノード内から実行されていて、ドメインコントローラーに `SERVER:PORT` でアクセスできることを前提としています。
証明書に関連する問題をトラブルシューティングするには、次の検証手順に従ってください。
**検証手順:**
1. **Active Directory ドメインコントローラーへの接続を確認します。**
ドメインコントローラーに接続できることを確認します。この手順が成功したら、ドメインコントローラーへの SSL 接続は成功し、証明書が検証されます。問題は証明書とは関係ありません。
この手順に失敗した場合は、次の検証に進みます。
```
$ openssl s_client -connect SERVER:PORT -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE
```
1. **証明書の検証を確認します。**
ローカル CA 証明書バンドルがドメインコントローラから提供された証明書を検証できることを確認します。この手順が成功した場合、問題は証明書に関するものではなく、他のネットワークの問題に関係しています。
この手順に失敗した場合は、次の検証に進みます。
```
$ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE
```
1. **Active Directory ドメインコントローラーから提供された証明書を確認します。**
ドメインコントローラーから提供された証明書の内容が期待どおりのものであることを確認します。この手順が成功した場合、コントローラーの検証に使用した CA 証明書に問題がある可能性があります。次のトラブルシューティングの手順に進んでください。
この手順に失敗した場合は、ドメインコントローラー用に発行された証明書を修正し、トラブルシューティングの手順を再実行する必要があります。
```
$ openssl s_client -connect SERVER:PORT -showcerts
```
1. **証明書の内容を確認します。**
ドメインコントローラーから提供された証明書の内容が期待どおりのものであることを確認します。この手順が成功した場合、コントローラーの検証に使用した CA 証明書に問題がある可能性があります。次のトラブルシューティングの手順に進んでください。
この手順に失敗した場合は、ドメインコントローラー用に発行された証明書を修正し、トラブルシューティングの手順を再実行する必要があります。
```
$ openssl s_client -connect SERVER:PORT -showcerts
```
1. **ローカル CA 証明書バンドルの内容を確認します。**
ドメインコントローラーの証明書の検証に使用されるローカル CA 証明書バンドルの内容が期待どおりのものであることを確認します。この手順が成功した場合、ドメインコントローラーから提供される証明書に問題がある可能性があります。
この手順に失敗した場合は、ドメインコントローラー用に発行された CA 証明書バンドルを修正し、トラブルシューティングの手順を再実行する必要があります。
```
$ openssl x509 -in PATH_TO_A_CERTIFICATE -text
```
## Active Directory との統合が動作していることを確認する方法
次の 2 つのチェックが成功すれば、Active Directory との統合は動作しています。
**チェック:**
1. **ディレクトリに定義されているユーザーを検出できる。**
クラスターヘッドノード内から、`ec2-user` として次のようにします。
```
$ getent passwd $ANY_AD_USER
```
1. **ユーザーパスワードを指定してヘッドノードに SSH 接続できる。**
```
$ ssh $ANY_AD_USER@$HEAD_NODE_IP
```
チェック 1 が失敗すると、チェック 2 も失敗することが予想されます。
その他のトラブルシューティングの確認。
+ ユーザーがディレクトリに存在することを確認します。
+ [デバッグログ](#troubleshooting-v3-multi-user-debug)を有効にします。
+ LDAPS の問題を除外するために、[LDAPS から LDAP に移行](#troubleshooting-v3-multi-user-ldaps-ldap)して暗号化を一時的に無効にすることを検討します。
## コンピューティングノードへのログインのトラブルシューティング方法
このセクションは、Active Directory と統合されたクラスターのコンピューティングノードへのログインに関連するものです。
では AWS ParallelCluster、クラスターコンピューティングノードへのパスワードログインは設計上無効になっています。
すべてのユーザーは、独自の SSH キーを使用してコンピューティングノードにログインする必要があります。
クラスター設定で [`GenerateSshKeysForUsers`](DirectoryService-v3.md#yaml-DirectoryService-GenerateSshKeysForUsers) が有効になっている場合、ユーザーは初回認証 (ログインなど) の後にヘッドノードで SSH キーを取得できます。
ユーザーはヘッドノードで初めて認証されるとき、ディレクトリユーザーとして自動的に生成された SSH キーを取得できます。ユーザーのホームディレクトリも作成されます。これは sudo ユーザーが初めてヘッドノードのユーザーに切り替えたときにも生じます。
ユーザーがヘッドノードにログインしたことがない場合、SSH キーは生成されず、ユーザーはコンピューティングノードにログインすることはできません。
## マルチユーザー環境での SimCenter StarCCM\$1 ジョブに関する既知の問題
このセクションは、Siemens の計算流体力学ソフトウェア Simcenter StarCCM\$1 がマルチユーザー環境で起動したジョブに関連するものです。
埋め込みの IntelMPI を使用するように設定された StarCCM\$1 v16 ジョブを実行すると、デフォルトで SSH を使用して MPI プロセスがブートストラップされます。
ユーザー名の解決エラーを起こす既知の [Slurm のバグ](https://bugs.schedmd.com/show_bug.cgi?id=13385)により、ジョブは `error setting up the bootstrap proxies` などのエラーで失敗することがあります。このバグは、 AWS ParallelCluster バージョン 3.1.1 と 3.1.2 にのみ影響します。
これを防ぐには、MPI ブートストラップ方式として Slurm を使用するよう IntelMPI を強制します。「[IntelMPI 公式ドキュメント](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/hydra-environment-variables.html)」で説明されているように、StarCCM\$1 を起動するジョブスクリプトに環境変数 `I_MPI_HYDRA_BOOTSTRAP=slurm` をエクスポートします。
## ユーザー名解決に関する既知の問題
このセクションは、ジョブ内でのユーザー名の取得に関連するものです。
既知の [Slurm のバグ](https://bugs.schedmd.com/show_bug.cgi?id=13385)により、`srun` なしでジョブを実行する場合、ジョブプロセス内で取得されるユーザー名は、`nobody` になることがあります。このバグは、 AWS ParallelCluster バージョン 3.1.1 と 3.1.2 にのみ影響します。
例えば、ディレクトリユーザーとして `sbatch --wrap 'srun id'` コマンドを実行すると、正しいユーザー名が返されます。ただし、`sbatch --wrap 'id'` をディレクトリユーザーとして実行すると、`nobody` がユーザー名として返されることがあります。
次の回避策を使用できます。
1. 可能であれば、`'sbatch'` の代わりに `'srun'` を使用してジョブを起動します。
1. クラスター設定で [AdditionalSssdConfigs](DirectoryService-v3.md#yaml-DirectoryService-AdditionalSssdConfigs) を次のように設定して、SSSD 列挙を有効にします。
```
AdditionalSssdConfigs:
enumerate: true
```
## ホームディレクトリ作成の問題の解決方法
このセクションは、ホームディレクトリ作成の問題に関連するものです。
次の例に示されるようなエラーが表示される場合は、ヘッドノードに初めてログインしたときにホームディレクトリが作成されていません。または、ヘッドノードで初めて sudoer から Active Directory ユーザーに切り替えたときに、ホームディレクトリが作成されませんでした。
```
$ ssh AD_USER@$HEAD_NODE_IP
/opt/parallelcluster/scripts/generate_ssh_key.sh failed: exit code 1
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
Could not chdir to home directory /home/PclusterUser85: No such file or directory
```
ホームディレクトリの作成の失敗は、クラスターヘッドノードにインストールされている `oddjob` および `oddjob-mkhomedir` パッケージにより発生することがあります。
ホームディレクトリと SSH キーがない場合、ユーザーはジョブや SSH をクラスターノードに送信できません。
システムに `oddjob` パッケージが必要な場合、`oddjobd` サービスが実行中であることを確認し、PAM 設定ファイルを更新してホームディレクトリが作成されていることを確認します。これを行うには、次の例に示されるようにヘッドノードでコマンドを実行します。
```
sudo systemctl start oddjobd
sudo authconfig --enablemkhomedir --updateall
```
システムに `oddjob` パッケージが必要でない場合、アンインストールし、PAM 設定ファイルを更新してホームディレクトリが作成されていることを確認します。これを行うには、次の例に示されるようにヘッドノードでコマンドを実行します。
```
sudo yum remove -y oddjob oddjob-mkhomedir
sudo authconfig --enablemkhomedir --updateall
```