Solución de problemas de integración multiusuario con Active Directory - AWS ParallelCluster
Solución de problemas específicos de Active DirectoryCómo habilitar el modo de depuración¿Cómo pasar de a LDAPS LDAPCómo deshabilitar la verificación LDAPS del certificado del servidor¿Cómo iniciar sesión con una SSH clave en lugar de una contraseñaCómo restablecer una contraseña de usuario y contraseñas caducadas¿Cómo comprobar el dominio al que se ha unidoCómo solucionar los problemas con .Cómo comprobar que la integración con Active Directory funcionaCómo solucionar problemas al iniciar sesión en los nodos de cómputoProblemas conocidos con los trabajos de SimCenter Star CCM + en un entorno multiusuarioProblemas conocidos relacionados con la resolución del nombre de usuarioCómo resolver los problemas de creación del directorio principal

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Solución de problemas de integración multiusuario con Active Directory

Esta sección es relevante para los clústeres integrados en un Active Directory.

Si la función de integración de Active Directory no funciona según lo esperado, los SSSD registros pueden proporcionar información de diagnóstico útil. Estos registros se encuentran en el directorio /var/log/sssd de los nodos del clúster. De forma predeterminada, también se almacenan en el grupo de CloudWatch registros de Amazon de un clúster.

Solución de problemas específicos de Active Directory

Esta sección es relevante para la solución de problemas específicos de un tipo de Active Directory.

AD sencillo

  • El valor de DomainReadOnlyUser debe coincidir con la búsqueda base del directorio Simple AD para los usuarios:

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

    Nota cn paraUsers.

  • El usuario administrador predeterminado esAdministrator.

  • Ldapsearchrequiere el BIOS nombre de red antes del nombre de usuario.

    La sintaxis / debe ser la siguiente:

    $ 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

  • El DomainReadOnlyUser valor debe coincidir con la búsqueda base del AWS Managed Microsoft AD directorio para los usuarios:

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

  • El usuario administrador predeterminado esAdmin.

  • La sintaxis / debe ser la siguiente:

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

Cómo habilitar el modo de depuración

Los registros de depuración SSSD pueden resultar útiles para solucionar problemas. Para habilitar el modo de depuración, debe actualizar el clúster con los siguientes cambios realizados en la configuración del clúster:

DirectoryService:
  AdditionalSssdConfigs:
    debug_level: "0x1ff"

¿Cómo pasar de a LDAPS LDAP

No se LDAP recomienda pasar de LDAPS (LDAPconTLS/SSL) a porque por LDAP sí solo no proporciona ningún cifrado. Sin embargo, puede resultar útil para realizar pruebas y solucionar problemas.

Puede restaurar el clúster a su configuración anterior actualizándolo con la definición de configuración anterior.

Para pasar de LDAPS aLDAP, debe actualizar el clúster con los siguientes cambios en la configuración del clúster:

DirectoryService:
  LdapTlsReqCert: never
  AdditionalSssdConfigs:
    ldap_auth_disable_tls_never_use_in_production: True

Cómo deshabilitar la verificación LDAPS del certificado del servidor

Puede resultar útil deshabilitar temporalmente la verificación LDAPS del certificado del servidor en el nodo principal para realizar pruebas o solucionar problemas.

Puede restaurar el clúster a su configuración anterior actualizándolo con la definición de configuración anterior.

Para deshabilitar la verificación LDAPS del certificado del servidor, debe actualizar el clúster con los siguientes cambios en la configuración del clúster:

DirectoryService:
  LdapTlsReqCert: never

¿Cómo iniciar sesión con una SSH clave en lugar de una contraseña

La SSH clave se crea /home/$user/.ssh/id_rsa después de iniciar sesión por primera vez con una contraseña. Para iniciar sesión con la SSH clave, debe iniciar sesión con su contraseña, copiar la SSH clave localmente y, a continuación, utilizarla SSH sin contraseña como de costumbre:

$ ssh -i $LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip

Cómo restablecer una contraseña de usuario y contraseñas caducadas

Si un usuario pierde el acceso a un clúster, es posible que su AWS Managed Microsoft AD contraseña haya caducado.

Para restablecer la contraseña, ejecute el siguiente comando con un usuario y un rol que tengan permiso de escritura en el directorio:

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

Si restablece la contraseña de DirectoryService/DomainReadOnlyUser:

  1. Asegúrese de actualizar el PasswordSecretArnsecreto DirectoryService/con la nueva contraseña.

  2. Actualice el clúster para el nuevo valor secreto:

    1. Detenga la flota de computación con el comando pcluster update-compute-fleet.

    2. A continuación, ejecute el siguiente comando desde el nodo principal del clúster.

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

Tras restablecer la contraseña y actualizar el clúster, se debe restablecer el acceso del usuario al clúster.

Para obtener más información, consulte Crear un usuario en la Guía de administración de AWS Directory Service .

¿Cómo comprobar el dominio al que se ha unido

El siguiente comando debe ejecutarse desde una instancia que esté unida al dominio, no desde el nodo 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

Cómo solucionar los problemas con .

Cuando LDAPS la comunicación no funciona, puede deberse a errores en la TLS comunicación, que a su vez pueden deberse a problemas con los certificados.

Notas acerca de los certificados:

  • El certificado especificado en la configuración del clúster LdapTlsCaCert debe ser un paquete de PEM certificados que contenga los certificados de toda la cadena de certificados de autoridad (CA) que emitió los certificados para los controladores de dominio.

  • Un paquete de PEM certificados es un archivo compuesto por la concatenación de certificados. PEM

  • Un certificado en PEM formato (normalmente utilizado en Linux) equivale a un certificado en DER formato base64 (normalmente exportado por Windows).

  • Si el certificado para los controladores de dominio lo emite una CA subordinada, el paquete de certificados debe contener el certificado de la CA subordinada y raíz.

Pasos de verificación para solucionar problemas:

En los siguientes pasos de verificación se supone que los comandos se ejecutan desde el nodo principal del clúster y que se puede acceder al controlador de dominio en SERVER:PORT él.

Para solucionar un problema relacionado con los certificados, siga estos pasos de verificación:

Pasos de verificación:

  1. Compruebe la conexión a los controladores de dominio de Active Directory:

    Comprobar que puede conectarse a un controlador de dominio. Si este paso se realiza correctamente, la SSL conexión al controlador de dominio se realiza correctamente y se verifica el certificado. El problema no está relacionado con los certificados.

    Si este paso no funciona, continúa con la siguiente verificación.

    $ openssl s_client -connect SERVER:PORT -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE

  2. Compruebe la verificación del certificado:

    Compruebe que el paquete de certificados de CA local pueda validar el certificado proporcionado por el controlador de dominio. Si este paso se realiza correctamente, el problema no está relacionado con los certificados, sino con otros problemas de red.

    Si este paso no funciona, continúa con la siguiente verificación.

    $ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE

  3. Compruebe el certificado proporcionado por los controladores de dominio de Active Directory:

    Compruebe que el contenido del certificado proporcionado por los controladores de dominio es el esperado. Si este paso se realiza correctamente, es probable que tenga problemas con el certificado de CA utilizado para verificar los controladores. Continúe con el siguiente paso de solución de problemas.

    Si este paso no funciona, debe corregir el certificado emitido para los controladores de dominio y volver a ejecutar los pasos de solución de problemas.

    $ openssl s_client -connect SERVER:PORT -showcerts

  4. Compruebe el contenido de un certificado:

    Compruebe que el contenido del certificado que proporcionan los controladores de dominio es el esperado. Si este paso se realiza correctamente, es probable que tenga problemas con el certificado de CA utilizado para verificar los controladores. Continúe con el siguiente paso de solución de problemas.

    Si este paso no funciona, debe corregir el certificado emitido para los controladores de dominio y volver a ejecutar los pasos de solución de problemas.

    $ openssl s_client -connect SERVER:PORT -showcerts

  5. Compruebe el contenido del paquete de certificados de CA local:

    Compruebe que el contenido del paquete de certificados de CA local utilizado para validar el certificado del controlador de dominio es el esperado. Si este paso se realiza correctamente, es probable que tenga problemas con el certificado proporcionado por los controladores de dominio.

    Si este paso no funciona, debe corregir el paquete de certificados de CA emitido para los controladores de dominio y volver a ejecutar los pasos de solución de problemas.

    $ openssl x509 -in PATH_TO_A_CERTIFICATE -text

Cómo comprobar que la integración con Active Directory funciona

Si las dos comprobaciones siguientes se realizan correctamente, la integración con Active Directory funciona.

verificaciones

  1. Puede detectar los usuarios definidos en el directorio:

    Desde el nodo principal del clúster, comoec2-user:

    $ getent passwd $ANY_AD_USER

  2. Puede SSH ingresar al nodo principal proporcionando la contraseña de usuario:

    $ ssh $ANY_AD_USER@$HEAD_NODE_IP

Si la primera comprobación falla, esperamos que la segunda también falle.

Solución de problemas adicionales

  • Compruebe que el usuario existe en el directorio.

  • Habilitación del registro de depuración de

  • Considere la posibilidad de deshabilitar temporalmente el cifrado pasando de LDAPS LDAP a para descartar LDAPS problemas.

Cómo solucionar problemas al iniciar sesión en los nodos de cómputo

Esta sección es relevante para iniciar sesión en los nodos de cómputo de los clústeres integrados con Active Directory.

Con AWS ParallelCluster, los inicios de sesión con contraseña en los nodos de cómputo del clúster están deshabilitados por diseño.

Todos los usuarios deben usar su propia SSH clave para iniciar sesión en los nodos de procesamiento.

Los usuarios pueden recuperar su SSH clave en el nodo principal tras la primera autenticación (por ejemplo, iniciar sesión), si GenerateSshKeysForUsersestá habilitada en la configuración del clúster.

Cuando los usuarios se autentican en el nodo principal por primera vez, pueden recuperar SSH las claves que se generan automáticamente para ellos como usuarios del directorio. También se crean los directorios principales para el usuario. Esto también puede ocurrir la primera vez que un sudo-usuario cambia a un usuario del nodo principal.

Si un usuario no ha iniciado sesión en el nodo principal, SSH las claves no se generan y el usuario no podrá iniciar sesión en los nodos de cálculo.

Problemas conocidos con los trabajos de SimCenter Star CCM + en un entorno multiusuario

Esta sección es relevante para los trabajos lanzados en un entorno multiusuario por el software de dinámica de fluidos computacional Simcenter Star CCM + de Siemens.

Si ejecuta tareas Star CCM + v16 configuradas para utilizar la tecnología Intel integradaMPI, los MPI procesos se iniciarán de forma predeterminada con la tecnología Intel. SSH

Debido a un conocido Slurm error que hace que la resolución del nombre de usuario sea incorrecta, los trabajos pueden fallar con un error comoerror setting up the bootstrap proxies. Este error solo afecta a AWS ParallelCluster las versiones 3.1.1 y 3.1.2.

Para evitar que esto ocurra, obligue a Intel MPI a usar Slurm como método MPI de arranque. Exporte la variable de entorno I_MPI_HYDRA_BOOTSTRAP=slurm al script de trabajo que lanza Star CCM +, tal y como se describe en la documentación MPI oficial de Intel.

Problemas conocidos relacionados con la resolución del nombre de usuario

Esta sección es relevante para recuperar los nombres de usuario en los trabajos.

Debido a un error conocido en Slurm, el nombre de usuario que se recupera en un proceso de trabajo puede ser el de ejecutar un trabajo nobody sin él. srun Este error solo afecta a AWS ParallelCluster las versiones 3.1.1 y 3.1.2.

Por ejemplo, si ejecuta el comando sbatch --wrap 'srun id' como usuario del directorio, se devuelve el nombre de usuario correcto. Sin embargo, si lo ejecuta sbatch --wrap 'id' como usuario del directorio, nobody es posible que se devuelva como nombre de usuario.

Puede utilizar las siguientes soluciones alternativas.

  1. Inicie su trabajo con, 'srun' en lugar de'sbatch', si es posible.

  2. Habilite SSSD la enumeración configurando la configuración AdditionalSssdConfigsen el clúster de la siguiente manera.

    AdditionalSssdConfigs:
  enumerate: true

Cómo resolver los problemas de creación del directorio principal

Esta sección es relevante para los problemas de creación del directorio principal.

Si ve errores como el que se muestra en el siguiente ejemplo, significa que no se creó un directorio principal para usted cuando inició sesión por primera vez en el nodo principal. O bien, no se creó un directorio principal para usted cuando cambió por primera vez de usuario de sudoer a usuario de Active Directory en el nodo 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

El error al crear el directorio principal puede deberse a los oddjob-mkhomedir paquetes oddjob y instalados en el nodo principal del clúster.

Sin un directorio principal y una SSH clave, el usuario no puede enviar trabajos ni acceder SSH a los nodos del clúster.

Si necesita los oddjob paquetes en su sistema, compruebe que el oddjobd servicio se esté ejecutando y actualice los archivos de PAM configuración para asegurarse de que se ha creado el directorio principal. Para ello, ejecute los comandos en el nodo principal como se muestra en el siguiente ejemplo.

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

Si no necesita los oddjob paquetes en su sistema, desinstálelos y actualice los archivos de PAM configuración para asegurarse de que se ha creado el directorio principal. Para ello, ejecute los comandos en el nodo principal como se muestra en el siguiente ejemplo.

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