Memecahkan masalah integrasi multi-pengguna dengan Active Directory

Bagian ini relevan dengan cluster yang terintegrasi dengan Active Directory.

Jika fitur integrasi Active Directory tidak berfungsi seperti yang diharapkan, log SSSD dapat memberikan informasi diagnostik yang berguna. Log ini terletak di /var/log/sssd pada node cluster. Secara default, mereka juga disimpan dalam grup CloudWatch log Amazon cluster.

Pemecahan masalah khusus Active Directory

Bagian ini relevan untuk pemecahan masalah khusus untuk jenis Active Directory.

Simple AD

• DomainReadOnlyUserNilai harus cocok dengan pencarian basis direktori Simple AD untuk pengguna:

  cn=ReadOnlyUser,cn=Users,dc=corp,dc=example,dc=com

  Catatan cn untukUsers.

• Pengguna admin default adalahAdministrator.

• Ldapsearchmembutuhkan nama NetBIOS sebelum nama pengguna.

  Ldapsearchsintaks harus sebagai berikut:

  $ 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

• DomainReadOnlyUserNilai harus sesuai dengan pencarian basis AWS Managed Microsoft AD direktori untuk pengguna:

  cn=ReadOnlyUser,ou=Users,ou=CORP,dc=corp,dc=example,dc=com

• Pengguna admin default adalahAdmin.

• Ldapsearchsintaks harus sebagai berikut:

  $ ldapsearch -x -D "Admin" -w "Password" -H ldap://192.0.2.103 \
     -b "ou=Users,ou=CORP,dc=corp,dc=example,dc=com"

Aktifkan mode debug

Log debug dari SSSD dapat berguna untuk memecahkan masalah. Untuk mengaktifkan mode debug, Anda harus memperbarui cluster dengan perubahan berikut yang dibuat pada konfigurasi cluster:

DirectoryService:
  AdditionalSssdConfigs:
    debug_level: "0x1ff"

Cara pindah dari LDAPS ke LDAP

Pindah dari LDAP (LDAP dengan TLS/SSL) ke LDAP tidak disarankan karena LDAP saja tidak menyediakan enkripsi apa pun. Namun demikian, ini dapat berguna untuk tujuan pengujian dan pemecahan masalah.

Anda dapat mengembalikan cluster ke konfigurasi sebelumnya dengan memperbarui cluster dengan definisi konfigurasi sebelumnya.

Untuk berpindah dari LDAPS ke LDAP, Anda harus memperbarui cluster dengan perubahan berikut dalam konfigurasi cluster:

DirectoryService:
  LdapTlsReqCert: never
  AdditionalSssdConfigs:
    ldap_auth_disable_tls_never_use_in_production: True

Cara menonaktifkan verifikasi sertifikat server LDAPS

Ini dapat berguna untuk menonaktifkan sementara verifikasi sertifikat server LDAPS pada node kepala, untuk tujuan pengujian atau pemecahan masalah.

Anda dapat mengembalikan cluster ke konfigurasi sebelumnya dengan memperbarui cluster dengan definisi konfigurasi sebelumnya.

Untuk menonaktifkan verifikasi sertifikat server LDAPS, Anda harus memperbarui cluster dengan perubahan berikut dalam konfigurasi cluster:

DirectoryService:
  LdapTlsReqCert: never

Cara masuk dengan kunci SSH daripada kata sandi

Kunci SSH dibuat /home/$user/.ssh/id_rsa setelah pertama kali Anda masuk dengan kata sandi. Untuk masuk dengan kunci SSH, Anda harus masuk dengan kata sandi Anda, menyalin kunci SSH secara lokal, dan kemudian menggunakannya ke SSH tanpa kata sandi seperti biasa:

$ ssh -i $LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip

Cara mengatur ulang kata sandi pengguna dan kata sandi yang kedaluwarsa

Jika pengguna kehilangan akses ke cluster, AWS Managed Microsoft AD kata sandi mereka mungkin telah kedaluwarsa.

Untuk mengatur ulang kata sandi, jalankan perintah berikut dengan pengguna dan peran yang memiliki izin tulis di direktori:

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

Jika Anda mengatur ulang kata sandi untuk DirectoryService/DomainReadOnlyUser:

1. Pastikan untuk memperbarui PasswordSecretArnrahasia DirectoryService/dengan kata sandi baru.

2. Perbarui cluster untuk nilai rahasia baru:

   1. Hentikan armada komputasi dengan pcluster update-compute-fleet perintah.

   2. Jalankan perintah berikut dari dalam node kepala cluster.

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

Setelah reset kata sandi dan pembaruan cluster, akses cluster pengguna harus dipulihkan.

Untuk informasi selengkapnya, lihat Mengatur ulang kata sandi pengguna di Panduan AWS Directory Service Administrasi.

Cara memverifikasi domain yang bergabung

Perintah berikut harus dijalankan dari instance yang bergabung ke domain, bukan node kepala.

$ 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

Cara memecahkan masalah dengan sertifikat

Ketika komunikasi LDAPS tidak berfungsi, itu bisa disebabkan oleh kesalahan dalam komunikasi TLS, yang pada gilirannya dapat disebabkan oleh masalah dengan sertifikat.

Catatan tentang sertifikat:

• Sertifikat yang ditentukan dalam konfigurasi cluster LdapTlsCaCert harus berupa bundel sertifikat PEM yang berisi sertifikat untuk seluruh rantai sertifikat otoritas (CA) yang mengeluarkan sertifikat untuk pengontrol domain.

• Bundel sertifikat PEM adalah file yang terbuat dari rangkaian sertifikat PEM.

• Sertifikat dalam format PEM (biasanya digunakan di Linux) setara dengan sertifikat dalam format DER base64 (biasanya diekspor oleh Windows).

• Jika sertifikat untuk pengontrol domain dikeluarkan oleh CA bawahan, maka bundel sertifikat harus berisi sertifikat bawahan dan root CA.

Langkah verifikasi pemecahan masalah:

Langkah-langkah verifikasi berikut mengasumsikan bahwa perintah dijalankan dari dalam node kepala cluster dan bahwa pengontrol domain dapat dijangkau di. SERVER:PORT

Untuk memecahkan masalah yang terkait dengan sertifikat, ikuti langkah-langkah verifikasi berikut:

Langkah verifikasi:

1. Periksa koneksi ke pengontrol domain Active Directory:

   Verifikasi bahwa Anda dapat terhubung ke pengontrol domain. Jika langkah ini berhasil, maka koneksi SSL ke pengontrol domain berhasil dan sertifikat diverifikasi. Masalah Anda tidak terkait dengan sertifikat.

   Jika langkah ini gagal, lanjutkan dengan verifikasi berikutnya.

   $ openssl s_client -connect SERVER:PORT -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE

2. Periksa verifikasi sertifikat:

   Verifikasi bahwa bundel sertifikat CA lokal dapat memvalidasi sertifikat yang disediakan oleh pengontrol domain. Jika langkah ini berhasil, maka masalah Anda tidak terkait dengan sertifikat, tetapi masalah jaringan lainnya.

   Jika langkah ini gagal, lanjutkan dengan verifikasi berikutnya.

   $ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE

3. Periksa sertifikat yang disediakan oleh pengontrol domain Active Directory:

   Verifikasi bahwa konten sertifikat yang disediakan oleh pengontrol domain adalah seperti yang diharapkan. Jika langkah ini berhasil, Anda mungkin memiliki masalah dengan sertifikat CA yang digunakan untuk memverifikasi pengontrol, lanjutkan ke langkah pemecahan masalah berikutnya.

   Jika langkah ini gagal, Anda harus memperbaiki sertifikat yang dikeluarkan untuk pengontrol domain dan menjalankan kembali langkah-langkah pemecahan masalah.

   $ openssl s_client -connect SERVER:PORT -showcerts

4. Periksa konten sertifikat:

   Verifikasi bahwa konten sertifikat yang disediakan oleh pengontrol domain adalah seperti yang diharapkan. Jika langkah ini berhasil, Anda mungkin memiliki masalah dengan sertifikat CA yang digunakan untuk memverifikasi controller, lanjutkan ke langkah pemecahan masalah berikutnya.

   Jika langkah ini gagal, Anda harus memperbaiki sertifikat yang dikeluarkan untuk pengontrol domain dan menjalankan kembali langkah-langkah pemecahan masalah.

   $ openssl s_client -connect SERVER:PORT -showcerts

5. Periksa konten bundel sertifikat CA lokal:

   Verifikasi bahwa konten bundel sertifikat CA lokal yang digunakan untuk memvalidasi sertifikat pengontrol domain adalah seperti yang diharapkan. Jika langkah ini berhasil, Anda mungkin memiliki masalah dengan sertifikat yang disediakan oleh pengontrol domain.

   Jika langkah ini gagal, Anda harus memperbaiki paket sertifikat CA yang dikeluarkan untuk pengontrol domain dan menjalankan kembali langkah-langkah pemecahan masalah.

   $ openssl x509 -in PATH_TO_A_CERTIFICATE -text

Cara memverifikasi bahwa integrasi dengan Active Directory berfungsi

Jika dua pemeriksaan berikut berhasil, integrasi dengan Active Directory berfungsi.

Cek:

1. Anda dapat menemukan pengguna yang ditentukan dalam direktori:

   Dari dalam node kepala cluster, sebagaiec2-user:

   $ getent passwd $ANY_AD_USER

2. Anda dapat SSH ke node kepala yang menyediakan kata sandi pengguna:

   $ ssh $ANY_AD_USER@$HEAD_NODE_IP

Jika cek satu gagal, kami berharap cek dua gagal juga.

Pemeriksaan pemecahan masalah tambahan:

• Verifikasi bahwa pengguna ada di direktori.

• Aktifkan logging debug.

• Pertimbangkan untuk menonaktifkan enkripsi sementara dengan berpindah dari LDAPS ke LDAP untuk mengesampingkan masalah LDAPS.

Cara memecahkan masalah masuk untuk menghitung node

Bagian ini relevan untuk masuk untuk menghitung node dalam cluster yang terintegrasi dengan Active Directory.

Dengan AWS ParallelCluster, login kata sandi ke node komputasi cluster dinonaktifkan berdasarkan desain.

Semua pengguna harus menggunakan kunci SSH mereka sendiri untuk masuk untuk menghitung node.

Pengguna dapat mengambil kunci SSH mereka di node kepala setelah otentikasi pertama (misalnya login), jika GenerateSshKeysForUsersdiaktifkan dalam konfigurasi cluster.

Ketika pengguna mengautentikasi pada node kepala untuk pertama kalinya, mereka dapat mengambil kunci SSH yang secara otomatis dihasilkan untuk mereka sebagai pengguna direktori. Direktori rumah untuk pengguna juga dibuat. Ini juga bisa terjadi saat pertama kali sudo-user beralih ke pengguna di head node.

Jika pengguna belum masuk ke node kepala, kunci SSH tidak dihasilkan dan pengguna tidak akan dapat masuk untuk menghitung node.

Masalah yang diketahui dengan pekerjaan SimCenter StarCCM+ di lingkungan multi-pengguna

Bagian ini relevan dengan pekerjaan yang diluncurkan di lingkungan multi-pengguna oleh Simcenter StarCCM+ perangkat lunak dinamika fluida komputasi dari Siemens.

Jika Anda menjalankan pekerjaan starCCM+v16 yang dikonfigurasi untuk menggunakan IntelMPI yang disematkan, secara default proses MPI di-bootstrap menggunakan SSH.

Karena bug Slurm yang diketahui yang menyebabkan resolusi nama pengguna salah, pekerjaan mungkin gagal dengan kesalahan seperti. error setting up the bootstrap proxies Bug ini hanya memengaruhi AWS ParallelCluster versi 3.1.1 dan 3.1.2.

Untuk mencegah hal ini terjadi, paksa IntelMpi untuk menggunakan Slurm sebagai metode bootstrap MPI. Ekspor variabel lingkungan I_MPI_HYDRA_BOOTSTRAP=slurm ke dalam skrip pekerjaan yang meluncurkan starCCM+, seperti yang dijelaskan dalam dokumentasi resmi IntelMpi.

Masalah yang diketahui dengan resolusi nama pengguna

Bagian ini relevan untuk mengambil nama pengguna dalam pekerjaan.

Karena bug yang diketahui di Slurm, nama pengguna yang diambil dalam proses pekerjaan mungkin nobody jika Anda menjalankan pekerjaan tanpa. srun Bug ini hanya memengaruhi AWS ParallelCluster versi 3.1.1 dan 3.1.2.

Misalnya, jika Anda menjalankan perintah sbatch --wrap 'srun id' sebagai pengguna direktori, nama pengguna yang benar dikembalikan. Namun, jika Anda menjalankan sbatch --wrap 'id' sebagai direktori pengguna, nobody mungkin dikembalikan sebagai nama pengguna.

Anda dapat menggunakan solusi berikut.

1. Luncurkan pekerjaan Anda dengan 'srun' alih-alih'sbatch', jika memungkinkan.

2. Aktifkan enumerasi SSSD dengan menyetel AdditionalSssdKonfigurasi dalam konfigurasi cluster sebagai berikut.

   AdditionalSssdConfigs:
     enumerate: true

Cara mengatasi masalah pembuatan direktori home

Bagian ini relevan dengan masalah pembuatan direktori home.

Jika Anda melihat kesalahan seperti yang ditunjukkan pada contoh berikut, direktori home tidak dibuat untuk Anda saat pertama kali masuk ke node kepala. Atau, direktori home tidak dibuat untuk Anda saat pertama kali beralih dari sudoer ke pengguna Active Directory di node kepala.

$ 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

Kegagalan pembuatan direktori home dapat disebabkan oleh oddjob-mkhomedir paket oddjob dan yang diinstal di node kepala cluster.

Tanpa direktori home dan kunci SSH, pengguna tidak dapat mengirimkan pekerjaan atau SSH ke node cluster.

Jika Anda memerlukan oddjob paket di sistem Anda, verifikasi bahwa oddjobd layanan sedang berjalan dan segarkan file konfigurasi PAM untuk memastikan bahwa direktori home dibuat. Untuk melakukan ini, jalankan perintah di node kepala seperti yang ditunjukkan pada contoh berikut.

sudo systemctl start oddjobd
sudo authconfig --enablemkhomedir --updateall

Jika Anda tidak memerlukan oddjob paket di sistem Anda, hapus instalannya dan segarkan file konfigurasi PAM untuk memastikan bahwa direktori home dibuat. Untuk melakukan ini, jalankan perintah di node kepala seperti yang ditunjukkan pada contoh berikut.

sudo yum remove -y oddjob oddjob-mkhomedir
sudo authconfig --enablemkhomedir --updateall