View a markdown version of this page

Risoluzione dei problemi di integrazione multiutente con Active Directory - AWS ParallelCluster
Risoluzione dei problemi specifici per Active DirectoryAbilita la modalità di debugCome passare da LDAPS a LDAPCome disattivare la verifica dei certificati del server LDAPSCome accedere con una chiave SSH anziché con una passwordCome reimpostare una password utente e le password scaduteCome verificare il dominio aggiuntoCome risolvere i problemi relativi ai certificatiCome verificare che l'integrazione con Active Directory funzioniCome risolvere i problemi di accesso ai nodi di calcoloProblemi noti con i lavori SimCenter StarCCM+ in un ambiente multiutenteProblemi noti con la risoluzione del nome utenteCome risolvere i problemi di creazione della home directory

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risoluzione dei problemi di integrazione multiutente con Active Directory

Questa sezione è rilevante per i cluster integrati con un Active Directory.

Se la funzionalità di integrazione di Active Directory non funziona come previsto, i log SSSD possono fornire utili informazioni diagnostiche. Questi log si trovano nei nodi /var/log/sssd del cluster. Per impostazione predefinita, vengono anche archiviati nel gruppo di CloudWatch log Amazon di un cluster.

Risoluzione dei problemi specifici per Active Directory

Questa sezione è pertinente alla risoluzione dei problemi specifici di un tipo di Active Directory.

Simple AD

  • Il DomainReadOnlyUser valore deve corrispondere alla ricerca di base nella directory Simple AD per gli utenti:

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

    Nota cn perUsers.

  • L'utente amministratore predefinito èAdministrator.

  • Ldapsearchrichiede il nome NetBIOS prima del nome utente.

    Ldapsearchla sintassi deve essere la seguente:

    $ 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

  • Il DomainReadOnlyUser valore deve corrispondere alla ricerca in base alla AWS Managed Microsoft AD directory per gli utenti:

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

  • L'utente amministratore predefinito èAdmin.

  • Ldapsearchla sintassi deve essere la seguente:

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

Abilita la modalità di debug

I log di debug di SSSD possono essere utili per risolvere i problemi. Per abilitare la modalità di debug, è necessario aggiornare il cluster con le seguenti modifiche apportate alla configurazione del cluster:

DirectoryService:
  AdditionalSssdConfigs:
    debug_level: "0x1ff"

Come passare da LDAPS a LDAP

Il passaggio da LDAPS (LDAP con TLS/SSL) a LDAP è sconsigliato perché LDAP da solo non fornisce alcuna crittografia. Tuttavia, può essere utile per scopi di test e risoluzione dei problemi.

È possibile ripristinare la configurazione precedente del cluster aggiornando il cluster con la definizione di configurazione precedente.

Per passare da LDAPS a LDAP, è necessario aggiornare il cluster con le seguenti modifiche nella configurazione del cluster:

DirectoryService:
  LdapTlsReqCert: never
  AdditionalSssdConfigs:
    ldap_auth_disable_tls_never_use_in_production: True

Come disattivare la verifica dei certificati del server LDAPS

Può essere utile disabilitare temporaneamente la verifica dei certificati del server LDAPS sul nodo principale, per scopi di test o risoluzione dei problemi.

È possibile ripristinare la configurazione precedente del cluster aggiornando il cluster con la definizione di configurazione precedente.

Per disabilitare la verifica del certificato del server LDAPS, è necessario aggiornare il cluster con le seguenti modifiche nella configurazione del cluster:

DirectoryService:
  LdapTlsReqCert: never

Come accedere con una chiave SSH anziché con una password

La chiave SSH viene creata /home/$user/.ssh/id_rsa dopo il primo accesso con una password. Per accedere con la chiave SSH, è necessario accedere con la propria password, copiare la chiave SSH localmente e quindi utilizzarla in modalità SSH senza password come al solito:

$ ssh -i $LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip

Come reimpostare una password utente e le password scadute

Se un utente perde l'accesso a un cluster, la AWS Managed Microsoft AD password potrebbe essere scaduta.

Per reimpostare la password, esegui il comando seguente con un utente e un ruolo dotati dell'autorizzazione di scrittura sulla directory:

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

Se si reimposta la password per DirectoryService/DomainReadOnlyUser:

  1. Assicurati di aggiornare DirectoryService/PasswordSecretArnsecret con la nuova password.

  2. Aggiorna il cluster per il nuovo valore segreto:

    1. Arresta il parco computer con il pcluster update-compute-fleet comando.

    2. Esegui il comando seguente dall'interno del nodo principale del cluster.

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

Dopo la reimpostazione della password e l'aggiornamento del cluster, l'accesso al cluster dell'utente dovrebbe essere ripristinato.

Per ulteriori informazioni, vedere Reimpostare una password utente nella Guida all'Servizio di directory amministrazione.

Come verificare il dominio aggiunto

Il comando seguente deve essere eseguito da un'istanza unita al dominio, non dal nodo principale.

$ 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

Come risolvere i problemi relativi ai certificati

Quando la comunicazione LDAPS non funziona, può essere dovuto a errori nella comunicazione TLS, che a loro volta possono essere dovuti a problemi con i certificati.

Note sui certificati:

  • Il certificato specificato nella configurazione del cluster LdapTlsCaCert deve essere un pacchetto di certificati PEM contenente i certificati per l'intera catena di certificati di autorità (CA) che ha emesso i certificati per i controller di dominio.

  • Un pacchetto di certificati PEM è un file costituito dalla concatenazione di certificati PEM.

  • Un certificato in formato PEM (tipicamente utilizzato in Linux) è equivalente a un certificato in formato DER base64 (in genere esportato da Windows).

  • Se il certificato per i controller di dominio viene rilasciato da una CA subordinata, il pacchetto di certificati deve contenere il certificato sia della CA subordinata che di quella radice.

Risoluzione dei problemi relativi alle fasi di verifica:

Le seguenti fasi di verifica presuppongono che i comandi vengano eseguiti dall'interno del nodo principale del cluster e che il controller di dominio sia raggiungibile all'indirizzo. SERVER:PORT

Per risolvere un problema relativo ai certificati, segui questi passaggi di verifica:

Passaggi di verifica:

  1. Verifica la connessione ai controller di dominio Active Directory:

    Verifica di poterti connettere a un controller di dominio. Se questo passaggio ha esito positivo, la connessione SSL al controller di dominio ha esito positivo e il certificato viene verificato. Il problema non è correlato ai certificati.

    Se questo passaggio non va a buon fine, procedi con la verifica successiva.

    $ openssl s_client -connect SERVER:PORT -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE

  2. Controlla la verifica del certificato:

    Verifica che il pacchetto di certificati CA locale sia in grado di convalidare il certificato fornito dal controller di dominio. Se questo passaggio ha esito positivo, il problema non è correlato ai certificati, ma ad altri problemi di rete.

    Se questo passaggio non riesce, procedi con la verifica successiva.

    $ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE

  3. Controlla il certificato fornito dai controller di dominio Active Directory:

    Verifica che il contenuto del certificato fornito dai controller di dominio sia quello previsto. Se questo passaggio ha esito positivo, probabilmente hai problemi con il certificato CA utilizzato per verificare i controller, vai al passaggio successivo per la risoluzione dei problemi.

    Se questo passaggio ha esito negativo, è necessario correggere il certificato emesso per i controller di dominio ed eseguire nuovamente la procedura di risoluzione dei problemi.

    $ openssl s_client -connect SERVER:PORT -showcerts

  4. Controlla il contenuto di un certificato:

    Verifica che il contenuto del certificato fornito dai controller di dominio sia quello previsto. Se questo passaggio ha esito positivo, probabilmente hai problemi con il certificato CA utilizzato per verificare il controller, vai al passaggio successivo per la risoluzione dei problemi.

    Se questo passaggio ha esito negativo, è necessario correggere il certificato emesso per i controller di dominio ed eseguire nuovamente la procedura di risoluzione dei problemi.

    $ openssl s_client -connect SERVER:PORT -showcerts

  5. Controlla il contenuto del pacchetto di certificati CA locale:

    Verifica che il contenuto del pacchetto di certificati CA locale utilizzato per convalidare il certificato dei controller di dominio sia quello previsto. Se questo passaggio ha esito positivo, probabilmente hai problemi con il certificato fornito dai controller di dominio.

    Se questo passaggio ha esito negativo, è necessario correggere il pacchetto di certificati CA emesso per i controller di dominio ed eseguire nuovamente la procedura di risoluzione dei problemi.

    $ openssl x509 -in PATH_TO_A_CERTIFICATE -text

Come verificare che l'integrazione con Active Directory funzioni

Se i due controlli seguenti hanno esito positivo, l'integrazione con Active Directory funziona.

Controlli:

  1. Puoi scoprire gli utenti definiti nella directory:

    Dall'interno del nodo principale del cluster, comeec2-user:

    $ getent passwd $ANY_AD_USER

  2. È possibile accedere tramite SSH al nodo principale fornendo la password utente: 

    $ ssh $ANY_AD_USER@$HEAD_NODE_IP

Se il primo controllo fallisce, ci aspettiamo che anche il controllo due fallisca.

Controlli aggiuntivi per la risoluzione dei problemi:

Come risolvere i problemi di accesso ai nodi di calcolo

Questa sezione è rilevante per l'accesso ai nodi di calcolo nei cluster integrati con Active Directory.

Con AWS ParallelCluster, gli accessi tramite password ai nodi di calcolo del cluster sono disabilitati in base alla progettazione.

Tutti gli utenti devono utilizzare la propria chiave SSH per accedere ai nodi di calcolo.

Gli utenti possono recuperare la propria chiave SSH nel nodo principale dopo la prima autenticazione (ad esempio il login), se GenerateSshKeysForUsers è abilitata nella configurazione del cluster.

Quando gli utenti si autenticano sul nodo principale per la prima volta, possono recuperare le chiavi SSH che vengono generate automaticamente per loro come utenti della directory. Vengono inoltre create le home directory per l'utente. Questo può accadere anche la prima volta che un sudo-user passa a un utente nel nodo principale.

Se un utente non ha effettuato l'accesso al nodo principale, le chiavi SSH non vengono generate e l'utente non sarà in grado di accedere ai nodi di calcolo.

Problemi noti con i lavori SimCenter StarCCM+ in un ambiente multiutente

Questa sezione è pertinente ai lavori avviati in un ambiente multiutente dal software di fluidodinamica computazionale Simcenter StarCCM+ di Siemens.

Se si eseguono processi StarCCM+ v16 configurati per utilizzare l'Intel MPI integrato, per impostazione predefinita i processi MPI vengono avviati tramite SSH.

A causa di un Slurm bug noto che causa un'errata risoluzione del nome utente, i processi potrebbero fallire con un errore del tipo. error setting up the bootstrap proxies Questo bug riguarda solo le AWS ParallelCluster versioni 3.1.1 e 3.1.2.

Per evitare che ciò accada, forzate IntelMPI a utilizzare come metodo bootstrap MPI. Slurm Esporta la variabile di ambiente I_MPI_HYDRA_BOOTSTRAP=slurm nello script di lavoro che avvia StarCCM+, come descritto nella documentazione ufficiale di IntelMPI. https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/hydra-environment-variables.html

Problemi noti con la risoluzione del nome utente

Questa sezione è rilevante per il recupero dei nomi utente all'interno dei lavori.

A causa di un bug noto in Slurm, il nome utente recuperato durante un processo di lavoro potrebbe essere nobody quello di eseguire un lavoro senza. srun Questo bug riguarda solo le AWS ParallelCluster versioni 3.1.1 e 3.1.2.

Ad esempio, se si esegue il comando sbatch --wrap 'srun id' come utente della directory, viene restituito il nome utente corretto. Tuttavia, se si esegue il comando sbatch --wrap 'id' come utente della directory, nobody potrebbe essere restituito come nome utente.

È possibile utilizzare le seguenti soluzioni alternative.

  1. Avvia il tuo lavoro con 'srun' invece di'sbatch', se possibile.

  2. Abilita l'enumerazione SSSD impostando la configurazione AdditionalSssdConfigs in cluster come segue.

    AdditionalSssdConfigs:
  enumerate: true

Come risolvere i problemi di creazione della home directory

Questa sezione è pertinente ai problemi di creazione della home directory.

Se vedi errori come quello mostrato nell'esempio seguente, significa che non è stata creata automaticamente una home directory quando hai effettuato il primo accesso al nodo principale. Oppure, quando sei passato per la prima volta da un utente sudoer a un utente di Active Directory nel nodo principale non è stata creata automaticamente.

$ ssh AD_USER@$HEAD_NODE_IP
/opt/parallelcluster/scripts/generate_ssh_key.sh failed: exit code 1

Operating system login banner
Could not chdir to home directory /home/PclusterUser85: No such file or directory

L'errore di creazione della home directory può essere causato dai oddjob-mkhomedir pacchetti oddjob and installati nel nodo principale del cluster.

Senza una home directory e una chiave SSH, l'utente non può inviare job o SSH nei nodi del cluster.

Se hai bisogno dei oddjob pacchetti nel tuo sistema, verifica che il oddjobd servizio sia in esecuzione e aggiorna i file di configurazione PAM per assicurarti che venga creata la home directory. Per fare ciò, esegui i comandi nel nodo principale come mostrato nell'esempio seguente.

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

Se non avete bisogno dei oddjob pacchetti nel vostro sistema, disinstallateli e aggiornate i file di configurazione PAM per assicurarvi che venga creata la home directory. Per fare ciò, esegui i comandi nel nodo head come mostrato nell'esempio seguente.

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