Active Directory を使用したマルチユーザー統合のトラブルシューティング - AWS ParallelCluster
Active Directory 固有のトラブルシューティングデバッグモードを有効にするLDAPS から LDAP に移行する方法LDAPS サーバー証明書の検証を無効にする方法パスワードではなく SSH キーを使用してログインする方法ユーザーパスワードと失効しているパスワードをリセットする方法参加しているドメインを確認する方法証明書に関する問題をトラブルシューティングする方法Active Directory との統合が動作していることを確認する方法コンピューティングノードへのログインのトラブルシューティング方法マルチユーザー環境での SimCenter StarCCM + ジョブに関する既知の問題ユーザー名解決に関する既知の問題ホームディレクトリ作成の問題の解決方法

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Active Directory を使用したマルチユーザー統合のトラブルシューティング

このセクションは、Active Directory と統合されたクラスターに関連するものです。

Active Directory 統合機能が期待どおりに動作していない場合、SSSD ログは役立つ診断情報を提供します。これらのログは、クラスターノードの /var/log/sssd に配置されています。デフォルトでは、クラスターの Amazon CloudWatch ロググループにも保存されます。

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 パスワードが失効している可能性があります。

パスワードをリセットするには、ディレクトリの書き込みアクセス許可を持つユーザーとロールを使用し、次のコマンドを実行します。

$ aws ds reset-user-password \
  --directory-id "d-abcdef01234567890" \
  --user-name "USER_NAME" \
  --new-password "NEW_PASSWORD" \
  --region "region-id"

DirectoryService/DomainReadOnlyUser のパスワードをリセットする場合。

  1. 必ず新しいパスワードで DirectoryService/PasswordSecretArn シークレットを更新します。

  2. 新しいシークレット値にクラスターを更新します。

    1. pcluster update-compute-fleet コマンドを使用してコンピューティングフリートを停止します。

    2. クラスターヘッドノード内から、次のコマンドを実行します。

      $ sudo /opt/parallelcluster/scripts/directory_service/update_directory_service_password.sh

パスワードのリセットとクラスターの更新の後、ユーザーのクラスターアクセスは復元されています。

詳細については、「AWS Directory Service 管理ガイド」の「ユーザーパスワードをリセットする」を参照してください。

参加しているドメインを確認する方法

次のコマンドは、ヘッドノードではなく、ドメインに参加しているインスタンスから実行する必要があります。

$ 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

  2. 証明書の検証を確認します。

    ローカル CA 証明書バンドルがドメインコントローラから提供された証明書を検証できることを確認します。この手順が成功した場合、問題は証明書に関するものではなく、他のネットワークの問題に関係しています。

    この手順に失敗した場合は、次の検証に進みます。

    $ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE

  3. Active Directory ドメインコントローラーから提供された証明書を確認します。

    ドメインコントローラーから提供された証明書の内容が期待どおりのものであることを確認します。この手順が成功した場合、コントローラーの検証に使用した CA 証明書に問題がある可能性があります。次のトラブルシューティングの手順に進んでください。

    この手順に失敗した場合は、ドメインコントローラー用に発行された証明書を修正し、トラブルシューティングの手順を再実行する必要があります。

    $ openssl s_client -connect SERVER:PORT -showcerts

  4. 証明書の内容を確認します。

    ドメインコントローラーから提供された証明書の内容が期待どおりのものであることを確認します。この手順が成功した場合、コントローラーの検証に使用した CA 証明書に問題がある可能性があります。次のトラブルシューティングの手順に進んでください。

    この手順に失敗した場合は、ドメインコントローラー用に発行された証明書を修正し、トラブルシューティングの手順を再実行する必要があります。

    $ openssl s_client -connect SERVER:PORT -showcerts

  5. ローカル CA 証明書バンドルの内容を確認します。

    ドメインコントローラーの証明書の検証に使用されるローカル CA 証明書バンドルの内容が期待どおりのものであることを確認します。この手順が成功した場合、ドメインコントローラーから提供される証明書に問題がある可能性があります。

    この手順に失敗した場合は、ドメインコントローラー用に発行された CA 証明書バンドルを修正し、トラブルシューティングの手順を再実行する必要があります。

    $ openssl x509 -in PATH_TO_A_CERTIFICATE -text

Active Directory との統合が動作していることを確認する方法

次の 2 つのチェックが成功すれば、Active Directory との統合は動作しています。

チェック:

  1. ディレクトリに定義されているユーザーを検出できる。

    クラスターヘッドノード内から、ec2-user として次のようにします。

    $ getent passwd $ANY_AD_USER

  2. ユーザーパスワードを指定してヘッドノードに SSH 接続できる。

    $ ssh $ANY_AD_USER@$HEAD_NODE_IP

チェック 1 が失敗すると、チェック 2 も失敗することが予想されます。

その他のトラブルシューティングの確認。

  • ユーザーがディレクトリに存在することを確認します。

  • デバッグログを有効にします。

  • LDAPS の問題を除外するために、LDAPS から LDAP に移行して暗号化を一時的に無効にすることを検討します。

コンピューティングノードへのログインのトラブルシューティング方法

このセクションは、Active Directory と統合されたクラスターのコンピューティングノードへのログインに関連するものです。

では AWS ParallelCluster、クラスターコンピューティングノードへのパスワードログインは設計上無効になっています。

すべてのユーザーは、独自の SSH キーを使用してコンピューティングノードにログインする必要があります。

クラスター設定で GenerateSshKeysForUsers が有効になっている場合、ユーザーは初回認証 (ログインなど) の後にヘッドノードで SSH キーを取得できます。

ユーザーはヘッドノードで初めて認証されるとき、ディレクトリユーザーとして自動的に生成された SSH キーを取得できます。ユーザーのホームディレクトリも作成されます。これは sudo ユーザーが初めてヘッドノードのユーザーに切り替えたときにも生じます。

ユーザーがヘッドノードにログインしたことがない場合、SSH キーは生成されず、ユーザーはコンピューティングノードにログインすることはできません。

マルチユーザー環境での SimCenter StarCCM + ジョブに関する既知の問題

このセクションは、Siemens の計算流体力学ソフトウェア Simcenter StarCCM+ がマルチユーザー環境で起動したジョブに関連するものです。

埋め込みの IntelMPI を使用するように設定された StarCCM+ v16 ジョブを実行すると、デフォルトで SSH を使用して MPI プロセスがブートストラップされます。

ユーザー名解決が間違っている原因となる既知のSlurmバグにより、ジョブは などのエラーで失敗する可能性がありますerror setting up the bootstrap proxies。このバグは、 AWS ParallelCluster バージョン 3.1.1 および 3.1.2 にのみ影響します。

これを防ぐには、IntelMPI を MPI ブートストラップメソッドSlurmとして使用するように強制します。「IntelMPI 公式ドキュメント」で説明されているように、StarCCM+ を起動するジョブスクリプトに環境変数 I_MPI_HYDRA_BOOTSTRAP=slurm をエクスポートします。

ユーザー名解決に関する既知の問題

このセクションは、ジョブ内でのユーザー名の取得に関連するものです。

既知の Slurm のバグにより、srun なしでジョブを実行する場合、ジョブプロセス内で取得されるユーザー名は、nobody になることがあります。このバグは、 AWS ParallelCluster バージョン 3.1.1 および 3.1.2 にのみ影響します。

例えば、ディレクトリユーザーとして sbatch --wrap 'srun id' コマンドを実行すると、正しいユーザー名が返されます。ただし、sbatch --wrap 'id' をディレクトリユーザーとして実行すると、nobody がユーザー名として返されることがあります。

次の回避策を使用できます。

  1. 可能であれば、'sbatch' の代わりに 'srun' を使用してジョブを起動します。

  2. クラスター設定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