Solução de problemas de integração de vários usuários com o Active Directory

Esta seção é relevante para clusters integrados a um Active Directory.

Se o recurso de integração do Active Directory não estiver funcionando conforme o esperado, os registros do SSSD podem fornecer informações úteis de diagnóstico. Esses logs estão localizados em /var/log/sssd nos nós do cluster. Por padrão, eles também são armazenados no grupo de CloudWatch logs da Amazon de um cluster.

Solução de problemas específicos do Active Directory

Esta seção é relevante para a solução de problemas específicos de um tipo de Active Directory.

Simple AD

• O valor DomainReadOnlyUser deve corresponder à pesquisa básica do diretório Simple AD para usuários:

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

  Anote cn para Users.

• O usuário administrador padrão é Administrator.

• Ldapsearch requer o nome NetBIOS antes do nome de usuário.

  A sintaxe Ldapsearch deve ser a seguinte:

  $ 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

• O valor DomainReadOnlyUser deve corresponder à pesquisa básica do diretório AWS Managed Microsoft AD para usuários:

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

• O usuário administrador padrão é Admin.

• A sintaxe Ldapsearch deve ser a seguinte:

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

Habilitar modo de depuração

Os registros de depuração do SSSD podem ser úteis para solucionar problemas. Para ativar o modo de depuração, você deve atualizar o cluster com as seguintes alterações feitas na configuração do cluster:

DirectoryService:
  AdditionalSssdConfigs:
    debug_level: "0x1ff"

Como passar do LDAPS para o LDAP

A mudança do LDAPS (LDAP com TLS/SSL) para o LDAP é desencorajada porque o LDAP sozinho não fornece nenhuma criptografia. No entanto, ele pode ser útil para fins de teste e solução de problemas.

Você pode restaurar a configuração anterior do cluster atualizando o cluster com a definição de configuração anterior.

Para migrar do LDAPS para o LDAP, você deve atualizar o cluster com as seguintes alterações na configuração do cluster:

DirectoryService:
  LdapTlsReqCert: never
  AdditionalSssdConfigs:
    ldap_auth_disable_tls_never_use_in_production: True

Como desabilitar a verificação do certificado do servidor LDAPS

Pode ser útil desativar temporariamente a verificação do certificado do servidor LDAPS no nó principal, para fins de teste ou solução de problemas.

Você pode restaurar a configuração anterior do cluster atualizando o cluster com a definição de configuração anterior.

Para desativar a verificação do certificado do servidor LDAPS, você deve atualizar o cluster com as seguintes alterações na configuração do cluster:

DirectoryService:
  LdapTlsReqCert: never

Como fazer login com uma chave SSH em vez de uma senha

A chave SSH é criada no /home/$user/.ssh/id_rsa após a primeira vez que você efetua login com uma senha. Para fazer login com a chave SSH, você deve fazer login com sua senha, copiar a chave SSH localmente e usá-la para SSH sem senha, como de costume:

$ ssh -i $LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip

Como redefinir uma senha de usuário e senhas expiradas

Se um usuário perder o acesso a um cluster, sua senha AWS Managed Microsoft AD pode ter expirado.

Para redefinir a senha, execute o seguinte comando com um usuário e uma função que tenham permissão de gravação no diretório:

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

Se você redefinir a senha para o DirectoryService / DomainReadOnlyUser:

1. Certifique-se de atualizar o segredo DirectoryService / PasswordSecretArn com a nova senha.

2. Atualize o cluster para obter o novo valor secreto:

   1. Pare a frota de computadores com o comando pcluster update-compute-fleet.

   2. Execute o comando a seguir de dentro do nó principal do cluster.

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

Após a redefinição da senha e a atualização do cluster, o acesso do usuário ao cluster deve ser restaurado.

Para obter mais informações, consulte Redefinir uma senha de usuário no Guia de administração do AWS Directory Service.

Como verificar o domínio associado

O comando a seguir deve ser executado em uma instância associada ao domínio, não no nó 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

Como solucionar problemas com certificados

Quando a comunicação LDAPS não está funcionando, pode ser devido a erros na comunicação TLS, o que, por sua vez, pode ser devido a problemas com certificados.

Notas sobre certificados:

• O certificado especificado na configuração do cluster LdapTlsCaCert deve ser um pacote de certificados PEM contendo os certificados de toda a cadeia de certificados de autoridade (CA) que emitiu certificados para os controladores de domínio.

• Um pacote de certificados PEM é um arquivo feito da concatenação de certificados PEM.

• Um certificado no formato PEM (normalmente usado no Linux) é equivalente a um certificado no formato base64 DER (normalmente exportado pelo Windows).

• Se o certificado para controladores de domínio for emitido por uma CA subordinada, o pacote de certificados deverá conter o certificado da CA subordinada e raiz.

Etapas de verificação de problemas:

As etapas de verificação a seguir pressupõem que os comandos sejam executados de dentro do nó principal do cluster e que o controlador de domínio esteja acessível em SERVER:PORT.

Para solucionar um problema relacionado aos certificados, siga estas etapas de verificação:

Etapas de verificação:

1. Verifique a conexão com os controladores de domínio do Active Directory:

   Verifique se você pode se conectar a um controlador de domínio. Se essa etapa for bem-sucedida, a conexão SSL com o controlador de domínio será bem-sucedida e o certificado será verificado. Seu problema não está relacionado aos certificados.

   Se essa etapa falhar, prossiga com a próxima verificação.

   $ openssl s_client -connect SERVER:PORT -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE

2. Revise a verificação do certificado:

   Verifique se o pacote de certificados CA local pode validar o certificado fornecido pelo controlador de domínio. Se essa etapa for bem-sucedida, seu problema não está relacionado aos certificados, mas a outros problemas de rede.

   Se essa etapa falhar, prossiga com a próxima verificação.

   $ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE

3. Verifique o certificado fornecido pelos controladores de domínio do Active Directory:

   Verifique se o conteúdo do certificado fornecido pelos controladores de domínio é o esperado. Se essa etapa for bem-sucedida, você provavelmente terá problemas com o certificado CA usado para verificar os controladores. Vá para a próxima etapa de solução de problemas.

   Se essa etapa falhar, você deverá corrigir o certificado emitido para os controladores de domínio e reexecutar as etapas de solução de problemas.

   $ openssl s_client -connect SERVER:PORT -showcerts

4. Verifique o conteúdo de um certificado:

   Verifique se o conteúdo do certificado fornecido pelos controladores de domínio é o esperado. Se essa etapa for bem-sucedida, você provavelmente terá problemas com o certificado CA usado para verificar os controladores. Vá para a próxima etapa de solução de problemas.

   Se essa etapa falhar, você deverá corrigir o certificado emitido para os controladores de domínio e reexecutar as etapas de solução de problemas.

   $ openssl s_client -connect SERVER:PORT -showcerts

5. Verifique o conteúdo do pacote de certificados CA local:

   Verifique se o conteúdo do pacote de certificados CA local usado para validar o certificado dos controladores de domínio está conforme o esperado. Se essa etapa for bem-sucedida, você provavelmente terá problemas com o certificado fornecido pelos controladores de domínio.

   Se essa etapa falhar, você deverá corrigir o pacote de certificado de CA emitido para os controladores de domínio e reexecutar as etapas de solução de problemas.

   $ openssl x509 -in PATH_TO_A_CERTIFICATE -text

Como verificar se a integração com o Active Directory está funcionando

Se as duas verificações a seguir forem bem-sucedidas, a integração com o Active Directory está funcionando.

Verificações:

1. Você pode descobrir usuários definidos no diretório:

   De dentro do nó principal do cluster, como um ec2-user:

   $ getent passwd $ANY_AD_USER

2. Você pode usar SSH no nó principal fornecendo a senha do usuário:

   $ ssh $ANY_AD_USER@$HEAD_NODE_IP

Se a verificação um falhar, esperamos que a verificação dois também falhe.

Verificações adicionais para solução de problemas:

• Verifique se o usuário existe no diretório.

• Habilitar debug logging.

• Considere desativar temporariamente a criptografia migrando do LDAPS para o LDAP para descartar problemas de LDAPS.

Como solucionar problemas de login em nós de computação

Esta seção é relevante para fazer login em nós de computação em clusters integrados ao Active Directory.

Com AWS ParallelCluster, os logins com senha nos nós de computação do cluster são desativados por design.

Todos os usuários devem usar sua própria chave SSH para fazer login nos nós de computação.

Os usuários podem recuperar sua chave SSH no nó principal após a primeira autenticação (por exemplo, login), se GenerateSshKeysForUsers estiver habilitadas na configuração do cluster.

Quando os usuários se autenticam no nó principal pela primeira vez, eles podem recuperar chaves SSH que são geradas automaticamente para eles como usuários do diretório. Também são criados diretórios pessoais para o usuário. Isso também pode acontecer na primeira vez que um sudo-usuário muda para um usuário no nó principal.

Se um usuário não estiver conectado ao nó principal, as chaves SSH não serão geradas e o usuário não poderá fazer login nos nós de computação.

Problemas conhecidos com trabalhos SimCenter StarCCM+ em um ambiente multiusuário

Esta seção é relevante para trabalhos lançados em um ambiente multiusuário pelo software de dinâmica de fluidos computacional Simcenter StarCCM+ da Siemens.

Se você executar trabalhos StarCCM+ v16 configurados para usar o IntelMPI incorporado, por padrão, os processos MPI serão inicializados usando SSH.

Devido a um bug do Slurm que faz com que a resolução do nome de usuário esteja errada, os trabalhos podem falhar com um erro como error setting up the bootstrap proxies. Esse bug afeta somente AWS ParallelCluster versões 3.1.1 e 3.1.2.

Para evitar que isso ocorra, force o IntelMPI a usar o Slurm como método de bootstrap do MPI. Exporte a variável de ambiente I_MPI_HYDRA_BOOTSTRAP=slurm para o script de trabalho que inicia o StarCCM+, conforme descrito na documentação oficial do IntelMPI.

Problemas conhecidos com a resolução do nome de usuário

Esta seção é relevante para recuperar nomes de usuário em trabalhos.

Devido a um bug conhecido no Slurm, o nome de usuário recuperado em um processo de trabalho pode ser nobody se você executar um trabalho sem srun. Esse bug afeta somente AWS ParallelCluster versões 3.1.1 e 3.1.2.

Por exemplo, se você executar o comando sbatch --wrap 'srun id' como usuário do diretório, o nome de usuário correto será retornado. No entanto, se você executar o sbatch --wrap 'id' como usuário do diretório, nobody poderá ser retornado como nome de usuário.

É possível usar as seguintes soluções alternativas.

1. Inicie seu trabalho com 'srun' em vez de 'sbatch', se possível.

2. Ative a enumeração SSSD definindo a configuração AdditionalSssdConfigsno cluster da seguinte forma.

   AdditionalSssdConfigs:
     enumerate: true

Como resolver problemas de criação do diretório inicial

Esta seção é relevante para problemas de criação de diretórios iniciais.

Se você ver erros como o mostrado no exemplo a seguir, um diretório inicial não foi criado para você quando você fez login pela primeira vez no nó principal. Ou, um diretório inicial não foi criado para você quando você mudou pela primeira vez de um sudoer para um usuário do Active Directory no nó 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

A falha na criação do diretório inicial pode ser causada pelos pacotes oddjob e oddjob-mkhomedir instalados no nó principal do cluster.

Sem um diretório inicial e uma chave SSH, o usuário não pode enviar trabalhos ou SSH para os nós do cluster.

Se você precisar dos pacotes oddjob em seu sistema, verifique se o serviço oddjobd está em execução e atualize os arquivos de configuração do PAM para garantir que o diretório inicial seja criado. Para fazer isso, execute os comandos no nó principal, conforme mostrado no exemplo a seguir.

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

Se você não precisar dos pacotes oddjob em seu sistema, desinstale-os e atualize os arquivos de configuração do PAM para garantir que o diretório inicial seja criado. Para fazer isso, execute os comandos no nó principal, conforme mostrado no exemplo a seguir.

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