Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Résolution des problèmes d'intégration multi-utilisateurs avec Active Directory
Cette section concerne les clusters intégrés à un Active Directory.
Si la fonctionnalité d'intégration d'Active Directory ne fonctionne pas comme prévu, les journaux SSSD peuvent fournir des informations de diagnostic utiles. Ces journaux se trouvent `/var/log/sssd` sur les nœuds du cluster. Par défaut, ils sont également stockés dans le groupe de CloudWatch journaux Amazon d'un cluster.
**Topics**
+ [Résolution des problèmes spécifiques à Active Directory](#troubleshooting-v3-multi-ad-specific)
+ [Activer le mode de débogage](#troubleshooting-v3-multi-user-debug)
+ [Comment passer de LDAPS à LDAP](#troubleshooting-v3-multi-user-ldaps-ldap)
+ [Comment désactiver la vérification du certificat du serveur LDAPS](#troubleshooting-v3-multi-user-ldaps-verify)
+ [Comment se connecter avec une clé SSH plutôt qu'un mot de passe](#troubleshooting-v3-multi-user-ssh-login)
+ [Comment réinitialiser le mot de passe d'un utilisateur et les mots de passe expirés](#troubleshooting-v3-multi-user-reset-passwd)
+ [Comment vérifier le domaine joint](#troubleshooting-v3-multi-user-domain-verify)
+ [Comment résoudre les problèmes liés aux certificats](#troubleshooting-v3-multi-user-certificates)
+ [Comment vérifier que l'intégration avec Active Directory fonctionne](#troubleshooting-v3-multi-user-ad-verify)
+ [Comment résoudre les problèmes de connexion aux nœuds de calcul](#troubleshooting-v3-multi-user-ad-compute-node-login)
+ [Problèmes connus liés aux tâches SimCenter StarCCM\$1 dans un environnement multi-utilisateurs](#troubleshooting-v3-multi-user-ad-starccm)
+ [Problèmes connus liés à la résolution des noms d'utilisateur](#troubleshooting-v3-multi-user-name-resolution)
+ [Comment résoudre les problèmes de création du répertoire de base](#troubleshooting-v3-multi-home-directory)
## Résolution des problèmes spécifiques à Active Directory
Cette section concerne le dépannage spécifique à un type d'Active Directory.
### Simple AD
+ La `DomainReadOnlyUser` valeur doit correspondre à la recherche de base d'annuaires Simple AD pour les utilisateurs :
`cn=ReadOnlyUser,cn=Users,dc=corp,dc=example,dc=com`
Remarque `cn` pour`Users`.
+ L'utilisateur administrateur par défaut est`Administrator`.
+ `Ldapsearch`nécessite le nom NetBIOS avant le nom d'utilisateur.
`Ldapsearch`la syntaxe doit être la suivante :
```
$ 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
+ La `DomainReadOnlyUser` valeur doit correspondre à la recherche dans la base de AWS Managed Microsoft AD répertoires pour les utilisateurs :
`cn=ReadOnlyUser,ou=Users,ou=CORP,dc=corp,dc=example,dc=com`
+ L'utilisateur administrateur par défaut est`Admin`.
+ `Ldapsearch`la syntaxe doit être la suivante :
```
$ ldapsearch -x -D "Admin" -w "Password" -H ldap://192.0.2.103 \
-b "ou=Users,ou=CORP,dc=corp,dc=example,dc=com"
```
## Activer le mode de débogage
Les journaux de débogage de SSSD peuvent être utiles pour résoudre les problèmes. Pour activer le mode de débogage, vous devez mettre à jour le cluster avec les modifications suivantes apportées à la configuration du cluster :
```
DirectoryService:
AdditionalSssdConfigs:
debug_level: "0x1ff"
```
## Comment passer de LDAPS à LDAP
Il est déconseillé de passer du protocole LDAPS (LDAP avec TLS/SSL) au protocole LDAP, car le protocole LDAP seul ne fournit aucun chiffrement. Néanmoins, cela peut être utile à des fins de test et de dépannage.
Vous pouvez rétablir la configuration précédente du cluster en le mettant à jour avec la définition de configuration précédente.
Pour passer de LDAPS à LDAP, vous devez mettre à jour le cluster en apportant les modifications suivantes à la configuration du cluster :
```
DirectoryService:
LdapTlsReqCert: never
AdditionalSssdConfigs:
ldap_auth_disable_tls_never_use_in_production: True
```
## Comment désactiver la vérification du certificat du serveur LDAPS
Il peut être utile de désactiver temporairement la vérification du certificat du serveur LDAPS sur le nœud principal, à des fins de test ou de dépannage.
Vous pouvez rétablir la configuration précédente du cluster en le mettant à jour avec la définition de configuration précédente.
Pour désactiver la vérification du certificat du serveur LDAPS, vous devez mettre à jour le cluster en apportant les modifications suivantes à la configuration du cluster :
```
DirectoryService:
LdapTlsReqCert: never
```
## Comment se connecter avec une clé SSH plutôt qu'un mot de passe
La clé SSH est créée lorsque vous vous connectez pour la première fois avec un mot de passe. `/home/$user/.ssh/id_rsa` Pour vous connecter avec la clé SSH, vous devez vous connecter avec votre mot de passe, copier la clé SSH localement, puis l'utiliser pour utiliser le protocole SSH sans mot de passe, comme d'habitude :
```
$ ssh -i $LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip
```
## Comment réinitialiser le mot de passe d'un utilisateur et les mots de passe expirés
Si un utilisateur perd l'accès à un cluster, son [AWS Managed Microsoft AD mot de passe a peut-être expiré](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_password_policies.html).
Pour réinitialiser le mot de passe, exécutez la commande suivante avec un utilisateur et un rôle autorisés à écrire sur le répertoire :
```
$ aws ds reset-user-password \
--directory-id "d-abcdef01234567890" \
--user-name "USER_NAME" \
--new-password "NEW_PASSWORD" \
--region "region-id"
```
Si vous réinitialisez le mot de passe du [`DirectoryService`](DirectoryService-v3.md)/[`DomainReadOnlyUser`](DirectoryService-v3.md#yaml-DirectoryService-DomainReadOnlyUser):
1. Assurez-vous de mettre à jour le [`DirectoryService`](DirectoryService-v3.md)/[`PasswordSecretArn`](DirectoryService-v3.md#yaml-DirectoryService-PasswordSecretArn)secret avec le nouveau mot de passe.
1. Mettez à jour le cluster pour la nouvelle valeur secrète :
1. Arrêtez le parc informatique à l'aide de la `pcluster update-compute-fleet` commande.
1. Exécutez la commande suivante depuis le nœud principal du cluster.
```
$ sudo /opt/parallelcluster/scripts/directory_service/update_directory_service_password.sh
```
Après la réinitialisation du mot de passe et la mise à jour du cluster, l'accès au cluster de l'utilisateur doit être rétabli.
Pour plus d'informations, voir [Réinitialiser un mot de passe utilisateur](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_reset_password.html) dans le *Guide d'Directory Service administration*.
## Comment vérifier le domaine joint
La commande suivante doit être exécutée à partir d'une instance jointe au domaine, et non du nœud principal.
```
$ 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
```
## Comment résoudre les problèmes liés aux certificats
Lorsque la communication LDAPS ne fonctionne pas, cela peut être dû à des erreurs dans la communication TLS, qui à leur tour peuvent être dues à des problèmes liés aux certificats.
**Remarques concernant les certificats :**
+ Le certificat spécifié dans la configuration du cluster `LdapTlsCaCert` doit être un ensemble de certificats PEM contenant les certificats de l'ensemble de la chaîne de certificats d'autorité (CA) qui a émis les certificats pour les contrôleurs de domaine.
+ Un bundle de certificats PEM est un fichier constitué de la concaténation de certificats PEM.
+ Un certificat au format PEM (généralement utilisé sous Linux) est équivalent à un certificat au format Base64 DER (généralement exporté par Windows).
+ Si le certificat pour les contrôleurs de domaine est émis par une autorité de certification subordonnée, le bundle de certificats doit contenir le certificat de l'autorité de certification subordonnée et celui de l'autorité de certification racine.
**Étapes de vérification du dépannage :**
Les étapes de vérification suivantes supposent que les commandes sont exécutées depuis le nœud principal du cluster et que le contrôleur de domaine est accessible à l'adresse`SERVER:PORT`.
Pour résoudre un problème lié aux certificats, suivez les étapes de vérification suivantes :
**Étapes de vérification :**
1. **Vérifiez la connexion aux contrôleurs de domaine Active Directory :**
Vérifiez que vous pouvez vous connecter à un contrôleur de domaine. Si cette étape réussit, la connexion SSL au contrôleur de domaine aboutit et le certificat est vérifié. Votre problème n'est pas lié aux certificats.
Si cette étape échoue, passez à la prochaine vérification.
```
$ openssl s_client -connect SERVER:PORT -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE
```
1. **Vérifiez la vérification du certificat :**
Vérifiez que le bundle de certificats CA local peut valider le certificat fourni par le contrôleur de domaine. Si cette étape aboutit, votre problème n'est pas lié aux certificats, mais à d'autres problèmes de réseau.
Si cette étape échoue, passez à la prochaine vérification.
```
$ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE
```
1. **Vérifiez le certificat fourni par les contrôleurs de domaine Active Directory :**
Vérifiez que le contenu du certificat fourni par les contrôleurs de domaine est conforme aux attentes. Si cette étape aboutit, vous rencontrez probablement des problèmes avec le certificat CA utilisé pour vérifier les contrôleurs. Passez à l'étape de résolution des problèmes suivante.
Si cette étape échoue, vous devez corriger le certificat émis pour les contrôleurs de domaine et réexécuter les étapes de dépannage.
```
$ openssl s_client -connect SERVER:PORT -showcerts
```
1. **Vérifiez le contenu d'un certificat :**
Vérifiez que le contenu du certificat fourni par les contrôleurs de domaine est conforme aux attentes. Si cette étape aboutit, vous avez probablement des problèmes avec le certificat CA utilisé pour vérifier le contrôleur. Passez à l'étape de résolution des problèmes suivante.
Si cette étape échoue, vous devez corriger le certificat émis pour les contrôleurs de domaine et réexécuter les étapes de résolution des problèmes.
```
$ openssl s_client -connect SERVER:PORT -showcerts
```
1. **Vérifiez le contenu du bundle de certificats CA local :**
Vérifiez que le contenu du bundle de certificats CA local utilisé pour valider le certificat des contrôleurs de domaine est conforme aux attentes. Si cette étape aboutit, vous rencontrez probablement des problèmes avec le certificat fourni par les contrôleurs de domaine.
Si cette étape échoue, vous devez corriger le bundle de certificats CA émis pour les contrôleurs de domaine et réexécuter les étapes de dépannage.
```
$ openssl x509 -in PATH_TO_A_CERTIFICATE -text
```
## Comment vérifier que l'intégration avec Active Directory fonctionne
Si les deux vérifications suivantes aboutissent, l'intégration avec Active Directory fonctionne.
**Contrôles :**
1. **Vous pouvez découvrir les utilisateurs définis dans l'annuaire :**
Depuis le nœud principal du cluster, en tant que `ec2-user` :
```
$ getent passwd $ANY_AD_USER
```
1. **Vous pouvez vous connecter par SSH au nœud principal en fournissant le mot de passe utilisateur :**
```
$ ssh $ANY_AD_USER@$HEAD_NODE_IP
```
Si le premier contrôle échoue, nous nous attendons à ce que le contrôle deux échoue également.
Contrôles de résolution des problèmes supplémentaires :
+ Vérifiez que l'utilisateur existe dans l'annuaire.
+ Activez la [journalisation du débogage](#troubleshooting-v3-multi-user-debug).
+ Envisagez de désactiver temporairement le chiffrement en [passant du protocole LDAPS au protocole LDAP afin d'éliminer les problèmes liés au protocole LDAPS](#troubleshooting-v3-multi-user-ldaps-ldap).
## Comment résoudre les problèmes de connexion aux nœuds de calcul
Cette section concerne la connexion aux nœuds de calcul des clusters intégrés à Active Directory.
Avec AWS ParallelCluster, les connexions par mot de passe aux nœuds de calcul du cluster sont désactivées par conception.
Tous les utilisateurs doivent utiliser leur propre clé SSH pour se connecter aux nœuds de calcul.
Les utilisateurs peuvent récupérer leur clé SSH dans le nœud principal après la première authentification (par exemple, connexion), si cette option [`GenerateSshKeysForUsers`](DirectoryService-v3.md#yaml-DirectoryService-GenerateSshKeysForUsers)est activée dans la configuration du cluster.
Lorsque les utilisateurs s'authentifient sur le nœud principal pour la première fois, ils peuvent récupérer les clés SSH qui sont automatiquement générées pour eux en tant qu'utilisateurs de l'annuaire. Des répertoires personnels pour l'utilisateur sont également créés. Cela peut également se produire la première fois qu'un sudo-utilisateur passe à un utilisateur du nœud principal.
Si un utilisateur ne s'est pas connecté au nœud principal, les clés SSH ne sont pas générées et l'utilisateur ne pourra pas se connecter aux nœuds de calcul.
## Problèmes connus liés aux tâches SimCenter StarCCM\$1 dans un environnement multi-utilisateurs
Cette section concerne les tâches lancées dans un environnement multi-utilisateurs par le logiciel de dynamique des fluides Simcenter StarCCM\$1 de Siemens.
Si vous exécutez des tâches StarCCM\$1 v16 configurées pour utiliser l'IntelMPI intégré, les processus MPI sont initialisés par défaut à l'aide de SSH.
En raison d'un [Slurmbogue](https://bugs.schedmd.com/show_bug.cgi?id=13385) connu qui entraîne une mauvaise résolution du nom d'utilisateur, les tâches peuvent échouer avec une erreur telle que`error setting up the bootstrap proxies`. Ce bogue n'affecte que AWS ParallelCluster les versions 3.1.1 et 3.1.2.
Pour éviter que cela ne se produise, forcez IntelMPI à l'utiliser Slurm comme méthode d'amorçage MPI. Exportez la variable d'environnement `I_MPI_HYDRA_BOOTSTRAP=slurm` dans le script de tâche qui lance StarCCM\$1, comme décrit dans la documentation officielle d'[IntelMPI](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/hydra-environment-variables.html).
## Problèmes connus liés à la résolution des noms d'utilisateur
Cette section est pertinente pour récupérer les noms d'utilisateur dans les tâches.
En raison d'un [bogue connu dans Slurm](https://bugs.schedmd.com/show_bug.cgi?id=13385), le nom d'utilisateur récupéré dans un processus de travail peut être le `nobody` cas si vous exécutez un travail sans. `srun` Ce bogue n'affecte que AWS ParallelCluster les versions 3.1.1 et 3.1.2.
Par exemple, si vous exécutez la commande `sbatch --wrap 'srun id'` en tant qu'utilisateur de l'annuaire, le nom d'utilisateur correct est renvoyé. Toutefois, si vous l'exécutez `sbatch --wrap 'id'` en tant qu'utilisateur d'annuaire, `nobody` il peut être renvoyé sous forme de nom d'utilisateur.
Vous pouvez utiliser les solutions suivantes.
1. Lancez votre travail avec `'srun'` au lieu de`'sbatch'`, si possible.
1. Activez l'énumération SSSD en définissant la [AdditionalSssdConfigs](DirectoryService-v3.md#yaml-DirectoryService-AdditionalSssdConfigs)configuration du cluster comme suit.
```
AdditionalSssdConfigs:
enumerate: true
```
## Comment résoudre les problèmes de création du répertoire de base
Cette section concerne les problèmes liés à la création du répertoire de base.
Si vous voyez des erreurs comme celle illustrée dans l'exemple suivant, aucun répertoire personnel n'a été créé pour vous lorsque vous vous êtes connecté pour la première fois au nœud principal. Ou bien, aucun répertoire de base n'a été créé pour vous lorsque vous êtes passé pour la première fois d'un sudoer à un utilisateur Active Directory dans le nœud principal.
```
$ 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'échec de création du répertoire de base peut être dû aux `oddjob-mkhomedir` packages `oddjob` et installés dans le nœud principal du cluster.
Sans répertoire de base et clé SSH, l'utilisateur ne peut pas envoyer de tâches ou de SSH aux nœuds du cluster.
Si vous avez besoin des `oddjob` packages dans votre système, vérifiez que le `oddjobd` service est en cours d'exécution et actualisez les fichiers de configuration PAM pour vous assurer que le répertoire de base a été créé. Pour ce faire, exécutez les commandes dans le nœud principal comme indiqué dans l'exemple suivant.
```
sudo systemctl start oddjobd
sudo authconfig --enablemkhomedir --updateall
```
Si vous n'avez pas besoin des `oddjob` packages dans votre système, désinstallez-les et actualisez les fichiers de configuration PAM pour vous assurer que le répertoire de base a été créé. Pour ce faire, exécutez les commandes dans le nœud principal comme indiqué dans l'exemple suivant.
```
sudo yum remove -y oddjob oddjob-mkhomedir
sudo authconfig --enablemkhomedir --updateall
```