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 Active Directory.
Se la funzionalità di integrazione di Active Directory non funziona come previsto, i log SSSD possono fornire informazioni diagnostiche utili. Questi registri si trovano nei nodi del cluster`/var/log/sssd`. Per impostazione predefinita, vengono archiviati anche nel gruppo di CloudWatch log Amazon di un cluster.
**Topics**
+ [Risoluzione dei problemi specifici di Active Directory](#troubleshooting-v3-multi-ad-specific)
+ [Abilita la modalità di debug](#troubleshooting-v3-multi-user-debug)
+ [Come passare da LDAPS a LDAP](#troubleshooting-v3-multi-user-ldaps-ldap)
+ [Come disabilitare la verifica dei certificati del server LDAPS](#troubleshooting-v3-multi-user-ldaps-verify)
+ [Come accedere con una chiave SSH anziché una password](#troubleshooting-v3-multi-user-ssh-login)
+ [Come reimpostare una password utente e le password scadute](#troubleshooting-v3-multi-user-reset-passwd)
+ [Come verificare il dominio aggiunto](#troubleshooting-v3-multi-user-domain-verify)
+ [Come risolvere i problemi relativi ai certificati](#troubleshooting-v3-multi-user-certificates)
+ [Come verificare che l'integrazione con Active Directory funzioni](#troubleshooting-v3-multi-user-ad-verify)
+ [Come risolvere i problemi di accesso ai nodi di calcolo](#troubleshooting-v3-multi-user-ad-compute-node-login)
+ [Problemi noti con i job SimCenter StarCCM\+ in un ambiente multiutente](#troubleshooting-v3-multi-user-ad-starccm)
+ [Problemi noti relativi alla risoluzione dei nomi utente](#troubleshooting-v3-multi-user-name-resolution)
+ [Come risolvere i problemi di creazione della home directory](#troubleshooting-v3-multi-home-directory)
## Risoluzione dei problemi specifici di Active Directory
Questa sezione è rilevante per la risoluzione dei problemi specifici di un tipo di Active Directory.
### Simple AD
+ Il `DomainReadOnlyUser` valore deve corrispondere alla ricerca di base della directory Simple AD per gli utenti:
`cn=ReadOnlyUser,cn=Users,dc={{corp}},dc={{example}},dc={{com}}`
Nota `cn` per`Users`.
+ L'utente amministratore predefinito è`Administrator`.
+ `Ldapsearch`richiede il nome NetBIOS prima del nome utente.
`Ldapsearch`la 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 degli utenti AWS Managed Microsoft AD nella base della directory:
`cn=ReadOnlyUser,ou=Users,ou=CORP,dc={{corp}},dc={{example}},dc={{com}}`
+ L'utente amministratore predefinito è`Admin`.
+ `Ldapsearch`la 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 da 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 disabilitare la verifica dei certificati del server LDAPS
Può essere utile disabilitare temporaneamente la verifica del certificato del server LDAPS sul nodo principale, a scopo di test o risoluzione dei problemi.
È possibile ripristinare il cluster alla configurazione precedente 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é 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 password, copiare la chiave SSH localmente e quindi utilizzarla senza password SSH 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, [AWS Managed Microsoft AD la sua password potrebbe essere scaduta](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_password_policies.html).
Per reimpostare la password, esegui il comando seguente con un utente e un ruolo con 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`](DirectoryService-v3.md)/[`DomainReadOnlyUser`](DirectoryService-v3.md#yaml-DirectoryService-DomainReadOnlyUser):
1. Assicurati di aggiornare [`DirectoryService`](DirectoryService-v3.md)/[`PasswordSecretArn`](DirectoryService-v3.md#yaml-DirectoryService-PasswordSecretArn)secret con la nuova password.
1. Aggiorna il cluster per il nuovo valore segreto:
1. Arresta la flotta di calcolo con il `pcluster update-compute-fleet` comando.
1. 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, è necessario ripristinare l'accesso al cluster dell'utente.
Per ulteriori informazioni, vedere [Reimpostazione di una password utente](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_reset_password.html) nella *Guida all'Directory Service amministrazione*.
## Come verificare il dominio aggiunto
Il comando seguente deve essere eseguito da un'istanza aggiunta 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 composto dalla concatenazione di certificati PEM.
+ Un certificato in formato PEM (generalmente utilizzato in Linux) è equivalente a un certificato in formato DER base64 (in genere esportato da Windows).
+ Se il certificato per i controller di dominio è emesso da una CA subordinata, il pacchetto di certificati deve contenere il certificato sia della CA subordinata che della CA principale.
**Fasi di verifica della risoluzione dei problemi:**
I seguenti passaggi 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 tuo problema non è correlato ai certificati.
Se questo passaggio fallisce, procedi con la verifica successiva.
```
$ openssl s_client -connect {{SERVER}}:{{PORT}} -CAfile {{PATH_TO_CA_BUNDLE_CERTIFICATE}}
```
1. **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 fallisce, procedi con la verifica successiva.
```
$ openssl verify -verbose -CAfile {{PATH_TO_CA_BUNDLE_CERTIFICATE}} {{PATH_TO_A_SERVER_CERTIFICATE}}
```
1. **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 non riesce, è necessario correggere il certificato emesso per i controller di dominio e rieseguire la procedura di risoluzione dei problemi.
```
$ openssl s_client -connect {{SERVER}}:{{PORT}} -showcerts
```
1. **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 non riesce, è 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
```
1. **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 non riesce, è 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, come`ec2-user`:
```
$ getent passwd {{$ANY_AD_USER}}
```
1. **È possibile accedere al nodo principale tramite SSH fornendo la password dell'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:
+ Verifica che l'utente esista nella directory.
+ Abilita la [registrazione di debug](#troubleshooting-v3-multi-user-debug).
+ Valuta la possibilità di disabilitare temporaneamente la crittografia [passando da LDAPS a LDAP per escludere problemi LDAPS](#troubleshooting-v3-multi-user-ldaps-ldap).
## 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`](DirectoryService-v3.md#yaml-DirectoryService-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. Ciò 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 job SimCenter StarCCM\+ in un ambiente multiutente
Questa sezione è relativa 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'IntelMPI integrato, per impostazione predefinita i processi MPI vengono avviati tramite SSH.
A causa di un [Slurmbug](https://bugs.schedmd.com/show_bug.cgi?id=13385) noto che causa una risoluzione errata 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, forza IntelMPI a utilizzare IntelMPI come metodo di 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 relativi alla risoluzione dei nomi utente
Questa sezione è rilevante per il recupero dei nomi utente all'interno dei job.
A causa di un [bug noto in Slurm](https://bugs.schedmd.com/show_bug.cgi?id=13385), il nome utente recuperato all'interno di un processo di lavoro potrebbe essere `nobody` se si esegue un lavoro senza. `srun` Questo bug riguarda solo AWS ParallelCluster le 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 lo si esegue `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.
1. Abilita l'enumerazione SSSD impostando la configurazione [AdditionalSssdConfigs](DirectoryService-v3.md#yaml-DirectoryService-AdditionalSssdConfigs)nel cluster come segue.
```
AdditionalSssdConfigs:
enumerate: true
```
## Come risolvere i problemi di creazione della home directory
Questa sezione è rilevante per i problemi di creazione della home directory.
Se vedi errori come quello mostrato nell'esempio seguente, significa che non è stata creata una home directory quando hai effettuato il primo accesso al nodo principale. Oppure, una home directory non è stata creata automaticamente quando sei passato per la prima volta da un sudoer a un utente di Active Directory nel nodo principale.
```
$ 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
```
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 la home directory sia stata creata. A tale scopo, eseguite i comandi nel nodo head, come illustrato 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 la home directory venga creata. 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
```