Problembehandlung bei der Mehrbenutzerintegration mit Active Directory - AWS ParallelCluster

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Problembehandlung bei der Mehrbenutzerintegration mit Active Directory

Dieser Abschnitt ist relevant für Cluster, die in ein Active Directory integriert sind.

Wenn die Active Directory-Integrationsfunktion nicht wie erwartet funktioniert, können die SSSD-Protokolle nützliche Diagnoseinformationen liefern. Diese Protokolle befinden sich /var/log/sssd auf Clusterknoten. Standardmäßig werden sie auch in der CloudWatch Amazon-Protokollgruppe eines Clusters gespeichert.

Active Directory-spezifische Fehlerbehebung

Dieser Abschnitt ist relevant für die Problembehandlung, die für einen Active Directory-Typ spezifisch ist.

Simple AD

  • Der DomainReadOnlyUser Wert muss mit der Basissuche im Simple AD AD-Verzeichnis für Benutzer übereinstimmen:

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

    Hinweis cn fürUsers.

  • Der Standard-Admin-Benutzer istAdministrator.

  • Ldapsearcherfordert den NetBIOS-Namen vor dem Benutzernamen.

    LdapsearchDie Syntax muss wie folgt lauten:

    $ 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

  • Der DomainReadOnlyUser Wert muss mit der Basissuche im AWS Managed Microsoft AD Verzeichnis für Benutzer übereinstimmen:

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

  • Der Standard-Admin-Benutzer istAdmin.

  • LdapsearchDie Syntax muss wie folgt lauten:

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

Aktivieren Sie den Debug-Modus

Debug-Protokolle von SSSD können nützlich sein, um Probleme zu beheben. Um den Debug-Modus zu aktivieren, müssen Sie den Cluster mit den folgenden Änderungen an der Clusterkonfiguration aktualisieren:

DirectoryService: AdditionalSssdConfigs: debug_level: "0x1ff"

Wie wechselt man von LDAPS zu LDAP

Von der Umstellung von LDAPS (LDAP mit TLS/SSL) auf LDAP wird abgeraten, da LDAP allein keine Verschlüsselung bietet. Dennoch kann es für Testzwecke und zur Fehlerbehebung nützlich sein.

Sie können die vorherige Konfiguration des Clusters wiederherstellen, indem Sie den Cluster mit der vorherigen Konfigurationsdefinition aktualisieren.

Um von LDAPS zu LDAP zu wechseln, müssen Sie den Cluster mit den folgenden Änderungen in der Clusterkonfiguration aktualisieren:

DirectoryService: LdapTlsReqCert: never AdditionalSssdConfigs: ldap_auth_disable_tls_never_use_in_production: True

Wie deaktiviere ich die Überprüfung von LDAPS-Serverzertifikaten

Zu Test- oder Fehlerbehebungszwecken kann es nützlich sein, die Überprüfung des LDAPS-Serverzertifikats auf dem Hauptknoten vorübergehend zu deaktivieren.

Sie können die vorherige Konfiguration des Clusters wiederherstellen, indem Sie den Cluster mit der vorherigen Konfigurationsdefinition aktualisieren.

Um die Überprüfung des LDAPS-Serverzertifikats zu deaktivieren, müssen Sie den Cluster mit den folgenden Änderungen in der Clusterkonfiguration aktualisieren:

DirectoryService: LdapTlsReqCert: never

Wie melde ich mich mit einem SSH-Schlüssel statt mit einem Passwort an

Der SSH-Schlüssel wird erstellt, /home/$user/.ssh/id_rsa nachdem Sie sich zum ersten Mal mit einem Passwort angemeldet haben. Um sich mit dem SSH-Schlüssel anzumelden, müssen Sie sich mit Ihrem Passwort anmelden, den SSH-Schlüssel lokal kopieren und ihn dann wie gewohnt passwortlos für SSH verwenden:

$ ssh -i $LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip

Wie setze ich ein Benutzerpasswort und abgelaufene Passwörter zurück

Wenn ein Benutzer den Zugriff auf einen Cluster verliert, ist sein AWS Managed Microsoft AD Passwort möglicherweise abgelaufen.

Um das Passwort zurückzusetzen, führen Sie den folgenden Befehl mit einem Benutzer und einer Rolle aus, die über Schreibberechtigungen für das Verzeichnis verfügen:

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

Wenn Sie das Passwort für DirectoryService/zurücksetzen DomainReadOnlyUser:

  1. Achten Sie darauf, das DirectoryService/PasswordSecretArnSecret mit dem neuen Passwort zu aktualisieren.

  2. Aktualisieren Sie den Cluster für den neuen geheimen Wert:

    1. Stoppen Sie die Rechenflotte mit dem pcluster update-compute-fleet Befehl.

    2. Führen Sie den folgenden Befehl innerhalb des Cluster-Hauptknotens aus.

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

Nach dem Zurücksetzen des Kennworts und dem Cluster-Update sollte der Clusterzugriff des Benutzers wiederhergestellt werden.

Weitere Informationen finden Sie unter Benutzerpasswort zurücksetzen im AWS Directory Service Administratorhandbuch.

Wie verifiziert man die beigetretene Domäne

Der folgende Befehl muss von einer Instanz aus ausgeführt werden, die mit der Domäne verknüpft ist, nicht vom Hauptknoten aus.

$ 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

Wie behebt man Probleme mit Zertifikaten

Wenn die LDAPS-Kommunikation nicht funktioniert, kann dies an Fehlern in der TLS-Kommunikation liegen, die wiederum auf Probleme mit Zertifikaten zurückzuführen sein können.

Hinweise zu Zertifikaten:
  • Das in der Clusterkonfiguration angegebene Zertifikat LdapTlsCaCert muss ein Paket von PEM-Zertifikaten sein, das die Zertifikate für die gesamte Zertifizierungskette (CA) enthält, die Zertifikate für die Domänencontroller ausgestellt hat.

  • Ein Paket von PEM-Zertifikaten ist eine Datei, die aus der Verkettung von PEM-Zertifikaten besteht.

  • Ein Zertifikat im PEM-Format (normalerweise in Linux verwendet) entspricht einem Zertifikat im Base64-DER-Format (normalerweise von Windows exportiert).

  • Wenn das Zertifikat für Domänencontroller von einer untergeordneten Zertifizierungsstelle ausgestellt wird, muss das Zertifikatspaket das Zertifikat sowohl der untergeordneten Zertifizierungsstelle als auch der Stammzertifizierungsstelle enthalten.

Schritte zur Fehlerbehebung bei der Überprüfung:

Bei den folgenden Überprüfungsschritten wird davon ausgegangen, dass die Befehle vom Cluster-Hauptknoten aus ausgeführt werden und dass der Domänencontroller unter erreichbar istSERVER:PORT.

Gehen Sie wie folgt vor, um ein Problem im Zusammenhang mit Zertifikaten zu beheben:

Schritte zur Überprüfung:
  1. Überprüfen Sie die Verbindung zu den Active Directory-Domänencontrollern:

    Stellen Sie sicher, dass Sie eine Verbindung zu einem Domänencontroller herstellen können. Wenn dieser Schritt erfolgreich ist, ist die SSL-Verbindung zum Domänencontroller erfolgreich und das Zertifikat wird überprüft. Ihr Problem hat nichts mit Zertifikaten zu tun.

    Wenn dieser Schritt fehlschlägt, fahren Sie mit der nächsten Überprüfung fort.

    $ openssl s_client -connect SERVER:PORT -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE
  2. Überprüfen Sie die Überprüfung des Zertifikats:

    Stellen Sie sicher, dass das lokale Zertifizierungsstellenzertifikatpaket das vom Domänencontroller bereitgestellte Zertifikat validieren kann. Wenn dieser Schritt erfolgreich ist, hängt Ihr Problem nicht mit Zertifikaten zusammen, sondern mit anderen Netzwerkproblemen.

    Wenn dieser Schritt fehlschlägt, fahren Sie mit der nächsten Überprüfung fort.

    $ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE
  3. Überprüfen Sie das von den Active Directory-Domänencontrollern bereitgestellte Zertifikat:

    Stellen Sie sicher, dass der Inhalt des von den Domänencontrollern bereitgestellten Zertifikats den Erwartungen entspricht. Wenn dieser Schritt erfolgreich ist, haben Sie wahrscheinlich Probleme mit dem CA-Zertifikat, das zur Überprüfung der Controller verwendet wird. Fahren Sie mit dem nächsten Schritt zur Fehlerbehebung fort.

    Schlägt dieser Schritt fehl, müssen Sie das für die Domänencontroller ausgestellte Zertifikat korrigieren und die Schritte zur Fehlerbehebung erneut ausführen.

    $ openssl s_client -connect SERVER:PORT -showcerts
  4. Überprüfen Sie den Inhalt eines Zertifikats:

    Stellen Sie sicher, dass der Inhalt des von den Domänencontrollern bereitgestellten Zertifikats den Erwartungen entspricht. Wenn dieser Schritt erfolgreich ist, haben Sie wahrscheinlich Probleme mit dem CA-Zertifikat, das zur Überprüfung der Controller verwendet wird. Fahren Sie mit dem nächsten Schritt zur Fehlerbehebung fort.

    Schlägt dieser Schritt fehl, müssen Sie das für die Domänencontroller ausgestellte Zertifikat korrigieren und die Schritte zur Fehlerbehebung erneut ausführen.

    $ openssl s_client -connect SERVER:PORT -showcerts
  5. Überprüfen Sie den Inhalt des lokalen CA-Zertifikatspakets:

    Stellen Sie sicher, dass der Inhalt des lokalen Zertifizierungsstellenzertifikatpakets, das zur Überprüfung des Zertifikats der Domänencontroller verwendet wird, den Erwartungen entspricht. Wenn dieser Schritt erfolgreich ist, haben Sie wahrscheinlich Probleme mit dem Zertifikat, das von den Domänencontrollern bereitgestellt wird.

    Wenn dieser Schritt fehlschlägt, müssen Sie das für die Domänencontroller ausgestellte CA-Zertifikatspaket korrigieren und die Schritte zur Fehlerbehebung erneut ausführen.

    $ openssl x509 -in PATH_TO_A_CERTIFICATE -text

Wie kann überprüft werden, ob die Integration mit Active Directory funktioniert

Wenn die folgenden beiden Prüfungen erfolgreich sind, funktioniert die Integration mit dem Active Directory.

Prüfungen:

  1. Sie können Benutzer finden, die im Verzeichnis definiert sind:

    Aus dem Hauptknoten des Clusters heraus, alsec2-user:

    $ getent passwd $ANY_AD_USER
  2. Sie können per SSH auf den Hauptknoten zugreifen und das Benutzerpasswort angeben:

    $ ssh $ANY_AD_USER@$HEAD_NODE_IP

Wenn Prüfung eins fehlschlägt, gehen wir davon aus, dass auch Prüfung zwei fehlschlägt.

Zusätzliche Prüfungen zur Fehlerbehebung:

Wie behebt man Probleme bei der Anmeldung bei Rechenknoten

Dieser Abschnitt ist relevant für die Anmeldung bei Rechenknoten in Clustern, die in Active Directory integriert sind.

Mit AWS ParallelCluster sind Kennwortanmeldungen an Cluster-Rechenknoten standardmäßig deaktiviert.

Alle Benutzer müssen ihren eigenen SSH-Schlüssel verwenden, um sich bei Rechenknoten anzumelden.

Benutzer können ihren SSH-Schlüssel nach der ersten Authentifizierung (z. B. Anmeldung) im Hauptknoten abrufen, sofern dies in der Clusterkonfiguration aktiviert GenerateSshKeysForUsersist.

Wenn sich Benutzer zum ersten Mal auf dem Hauptknoten authentifizieren, können sie SSH-Schlüssel abrufen, die automatisch für sie als Verzeichnisbenutzer generiert werden. Home-Verzeichnisse für den Benutzer werden ebenfalls erstellt. Dies kann auch passieren, wenn ein Sudo-Benutzer zum ersten Mal zu einem Benutzer im Hauptknoten wechselt.

Wenn sich ein Benutzer nicht am Hauptknoten angemeldet hat, werden keine SSH-Schlüssel generiert und der Benutzer kann sich nicht bei Rechenknoten anmelden.

Bekannte Probleme mit SimCenter StarCCM+-Jobs in einer Mehrbenutzerumgebung

Dieser Abschnitt bezieht sich auf Jobs, die mit der Computational Fluid Dynamics Software Simcenter StarCCM+ von Siemens in einer Mehrbenutzerumgebung gestartet wurden.

Wenn Sie StarCCM+ v16-Jobs ausführen, die für die Verwendung des eingebetteten IntelMPI konfiguriert sind, werden die MPI-Prozesse standardmäßig mithilfe von SSH gebootet.

Aufgrund eines bekannten Slurm-Fehlers, der dazu führt, dass die Benutzernamen-Auflösung falsch ist, können Jobs mit einem Fehler wie fehlschlagen. error setting up the bootstrap proxies Dieser Fehler betrifft nur die AWS ParallelCluster Versionen 3.1.1 und 3.1.2.

Um dies zu verhindern, zwingen Sie IntelMPI, Slurm als MPI-Bootstrap-Methode zu verwenden. Exportieren Sie die Umgebungsvariable I_MPI_HYDRA_BOOTSTRAP=slurm in das Job-Skript, das StarCCM+ startet, wie in der offiziellen IntelMPI-Dokumentation beschrieben.

Bekannte Probleme bei der Benutzernamenauflösung

Dieser Abschnitt ist relevant für das Abrufen von Benutzernamen innerhalb von Jobs.

Aufgrund eines bekannten Fehlers in Slurm könnte der innerhalb eines Jobprozesses abgerufene Nutzername lauten, nobody wenn Sie einen Job ohne ausführen. srun Dieser Fehler betrifft nur die AWS ParallelCluster Versionen 3.1.1 und 3.1.2.

Wenn Sie den Befehl beispielsweise sbatch --wrap 'srun id' als Verzeichnisbenutzer ausführen, wird der richtige Benutzername zurückgegeben. Wenn Sie den jedoch sbatch --wrap 'id' als Verzeichnisbenutzer ausführen, wird nobody möglicherweise der Benutzername zurückgegeben.

Sie können die folgenden Problemumgehungen verwenden.

  1. Starten Sie Ihren Job'sbatch', wenn möglich, mit 'srun' statt mit.

  2. Aktivieren Sie die SSSD-Enumeration, indem Sie die AdditionalSssdKonfigurationen in der Clusterkonfiguration wie folgt festlegen.

    AdditionalSssdConfigs: enumerate: true

Wie löst man Probleme beim Erstellen von Home-Verzeichnissen

Dieser Abschnitt ist relevant für Probleme bei der Erstellung von Home-Verzeichnissen.

Wenn Sie Fehler wie den im folgenden Beispiel gezeigten sehen, wurde kein Home-Verzeichnis für Sie erstellt, als Sie sich zum ersten Mal am Hauptknoten angemeldet haben. Oder es wurde kein Home-Verzeichnis für Sie erstellt, als Sie zum ersten Mal von einem Sudoer zu einem Active Directory-Benutzer im Hauptknoten wechselten.

$ 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

Der Fehler beim Erstellen des Home-Verzeichnisses kann durch die oddjob im oddjob-mkhomedir Cluster-Hauptknoten installierten UND-Pakete verursacht werden.

Ohne ein Home-Verzeichnis und einen SSH-Schlüssel kann der Benutzer keine Jobs oder SSH an die Clusterknoten senden.

Wenn Sie die oddjob Pakete in Ihrem System benötigen, stellen Sie sicher, dass der oddjobd Dienst ausgeführt wird, und aktualisieren Sie die PAM-Konfigurationsdateien, um sicherzustellen, dass das Home-Verzeichnis erstellt wurde. Führen Sie dazu die Befehle im Hauptknoten aus, wie im folgenden Beispiel gezeigt.

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

Wenn Sie die oddjob Pakete in Ihrem System nicht benötigen, deinstallieren Sie sie und aktualisieren Sie die PAM-Konfigurationsdateien, um sicherzustellen, dass das Home-Verzeichnis erstellt wird. Führen Sie dazu die Befehle im Hauptknoten aus, wie im folgenden Beispiel gezeigt.

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