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 característica de integración de Active Directory no funciona como se esperaba, los registros SSSD 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 nombre de NetBIOS 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 de SSSD pueden ser ú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 LDAPS a LDAP

No se recomienda pasar del LDAPS (LDAP con TLS/SSL) al LDAP porque el LDAP por sí solo no proporciona ningún tipo de 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 a LDAP, 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 del certificado del servidor LDAPS

Puede resultar útil deshabilitar temporalmente la verificación del certificado del servidor LDAPS 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 del certificado del servidor LDAPS, 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 clave SSH en lugar de una contraseña?

La clave SSH 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 clave SSH, debe iniciar sesión con su contraseña, copiar la clave SSH localmente y, a continuación, utilizarla para realizar 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 la comunicación LDAPS no funciona, puede deberse a errores en la comunicación TLS, 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 certificados PEM 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 certificados PEM es un archivo compuesto por la concatenación de certificados PEM.

• Un certificado en formato PEM (normalmente utilizado en Linux) equivale a un certificado en formato DER 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 conexión SSL 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 acceder mediante SSH 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 a LDAP para descartar problemas con el LDAPS.

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 clave SSH para iniciar sesión en los nodos de procesamiento.

Los usuarios pueden recuperar su clave SSH en el nodo principal tras la primera autenticación (por ejemplo, al 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 las claves SSH 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, las claves SSH no se generan y el usuario no podrá iniciar sesión en los nodos de cálculo.

Problemas conocidos con los trabajos de SimCenter StarCCM+ 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 StarCCM+ de Siemens.

Si ejecuta tareas de StarCCM+ v16 configuradas para utilizar el IntelMPI integrado, los procesos del MPI se iniciarán de forma predeterminada mediante SSH.

Debido a un Slurmerror conocido que hace que la resolución del nombre de usuario sea incorrecta, es posible que los trabajos fallen y se produzca un error similar. error 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 IntelMPI a utilizar Slurm como método de arranque MPI. Exporte la variable de entorno I_MPI_HYDRA_BOOTSTRAP=slurm al script de trabajo que lanza StarCCM+, tal y como se describe en la documentación oficial de IntelMPI.

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 las AWS ParallelCluster 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 la enumeración de SSSD configurando la configuración en el clúster de la AdditionalSssdConfigssiguiente 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 clave SSH, el usuario no puede enviar trabajos o 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 configuración de PAM 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 configuración de PAM 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