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 liés à l'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 des certificats de 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\+ 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 liés à la création du répertoire personnel](#troubleshooting-v3-multi-home-directory)
## Résolution des problèmes spécifiques à Active Directory
Cette section concerne la résolution des problèmes spécifiques à un type d'Active Directory.
### Simple AD
+ La `DomainReadOnlyUser` valeur doit correspondre à la recherche de base de l'annuaire 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 d'utilisateurs dans la base de AWS Managed Microsoft AD répertoires :
`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 du SSSD peuvent être utiles pour résoudre les problèmes. Pour activer le mode débogage, vous devez mettre à jour le cluster en apportant les modifications suivantes à la configuration du cluster :
```
DirectoryService:
AdditionalSssdConfigs:
debug_level: "0x1ff"
```
## Comment passer de LDAPS à LDAP
Le passage du protocole LDAPS (LDAP avec TLS/SSL) au protocole LDAP est déconseillé car le protocole LDAP seul ne fournit aucun chiffrement. Néanmoins, il peut être utile à des fins de test et de dépannage.
Vous pouvez restaurer 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 des certificats de serveur LDAPS
Il peut être utile de désactiver temporairement la vérification des certificats de serveur LDAPS sur le nœud principal, à des fins de test ou de dépannage.
Vous pouvez restaurer 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 `/home/$user/.ssh/id_rsa` après la première connexion avec un mot de passe. 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 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 pour le [`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 le mot de passe d'un 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 à partir 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 peuvent à leur tour ê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 des certificats pour les contrôleurs de domaine.
+ Un ensemble 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 DER base64 (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 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 de tête du cluster et que le contrôleur de domaine est accessible à l'adresse`{{SERVER}}:{{PORT}}`.
Pour résoudre un problème lié aux certificats, procédez comme suit :
**É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 aboutit, la connexion SSL au contrôleur de domaine est établie 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 dépannage 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 rencontrez probablement des problèmes avec le certificat CA utilisé pour vérifier le contrôleur. Passez à l'étape de dépannage suivante.
Si cette étape échoue, vous devez corriger le certificat émis pour les contrôleurs de domaine et recommencer les étapes de dépannage.
```
$ 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 recommencer 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 réussissent, 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 dépannage supplémentaires :
+ Vérifiez que l'utilisateur existe dans l'annuaire.
+ Activez la journalisation [ du ](#troubleshooting-v3-multi-user-debug) débogage.
+ Envisagez de désactiver temporairement le chiffrement en [ passant du protocole LDAPS au protocole LDAP afin d'éliminer les problèmes liés ](#troubleshooting-v3-multi-user-ldaps-ldap) au protocole LDAPS.
## Comment résoudre les problèmes de connexion aux nœuds de calcul
Cette section concerne la connexion à des nœuds de calcul dans 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 elle [`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 utilisateur sudo passe à un utilisateur du nœud principal.
Si un utilisateur ne s'est pas connecté au nœud principal, aucune clé SSH n'est générée et l'utilisateur ne pourra pas se connecter aux nœuds de calcul.
## Problèmes connus liés aux tâches SimCenter StarCCM\+ dans un environnement multi-utilisateurs
Cette section concerne les offres d'emploi lancées dans un environnement multi-utilisateurs par le logiciel informatique de dynamique des fluides Simcenter StarCCM\+ de Siemens.
Si vous exécutez des tâches StarCCM\+ v16 configurées pour utiliser l'IntelMPI intégré, les processus MPI sont démarrés par défaut via SSH.
En raison d'un [Slurm bogue connu ](https://bugs.schedmd.com/show_bug.cgi?id=13385) 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 ne concerne que AWS ParallelCluster les versions 3.1.1 et 3.1.2.
Pour éviter cela, 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\+, 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 concerne la récupération des noms d'utilisateur dans les jobs.
En raison d'un [ bogue connu dans Slurm](https://bugs.schedmd.com/show_bug.cgi?id=13385), le nom d'utilisateur récupéré au cours d'un processus de travail peut être utilisé `nobody` si vous exécutez un travail sans. `srun` Ce bogue ne concerne 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 exécutez le `sbatch --wrap 'id'` en tant qu'utilisateur de l'annuaire, `nobody` il peut être renvoyé en tant que nom d'utilisateur.
Vous pouvez utiliser les solutions de contournement suivantes.
1. Lancez votre offre d'emploi avec `'srun'` plutôt `'sbatch'` que, 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 liés à la création du répertoire personnel
Cette section concerne les problèmes liés à la création d'un répertoire personnel.
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 personnel 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
{{Operating system login banner}}
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 causé par les `oddjob-mkhomedir` packages `oddjob` et installés sur le nœud principal du cluster.
Sans répertoire de base et sans clé SSH, l'utilisateur ne peut pas soumettre 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 personnel est 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 personnel est 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
```