Active Directory와의 다중 사용자 통합 문제 해결 - AWS ParallelCluster
Active Directory 관련 문제 해결디버그 모드 활성화LDAPS에서 LDAP로 이동하는 방법LDAPS 서버 인증서 검증을 비활성화하는 방법암호 대신 SSH 키를 사용하여 로그인하는 방법사용자 암호 및 만료된 암호를 재설정하는 방법조인한 도메인을 확인하는 방법인증서 문제를 해결하는 방법Active Directory와의 통합이 제대로 작동하는지 확인하는 방법컴퓨팅 노드 로그인 문제를 해결하는 방법다중 사용자 환경에서 SimCenter StarCCM+ 작업과 관련된 알려진 문제사용자 이름 확인과 관련된 알려진 문제홈 디렉터리 생성 문제를 해결하는 방법

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Active Directory와의 다중 사용자 통합 문제 해결

이 섹션은 Active Directory와 통합된 클러스터와 관련이 있습니다.

Active Directory 통합 기능이 예상대로 작동하지 않는 경우 SSSD 로그가 유용한 진단 정보를 제공할 수 있습니다. 이러한 로그는 클러스터 노드의 /var/log/sssd에 있습니다. 기본적으로 클러스터의 Amazon CloudWatch 로그 그룹에도 저장됩니다.

Active Directory 관련 문제 해결

이 섹션은 Active Directory 유형별 문제 해결과 관련이 있습니다.

Simple AD

  • DomainReadOnlyUser 값은 사용자에 대한 Simple AD 디렉터리 기본 검색과 일치해야 합니다.

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

    Users에 cn을 참고하세요.

  • 기본 관리자 사용자는 Administrator입니다.

  • Ldapsearch에는 사용자 이름 앞에 NetBIOS 이름이 있어야 합니다.

    Ldapsearch 구문은 다음과 같아야 합니다.

    $ 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

  • DomainReadOnlyUser값은 사용자의 AWS Managed Microsoft AD 디렉토리 기반 검색과 일치해야 합니다.

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

  • 기본 관리자 사용자는 Admin입니다.

  • Ldapsearch 구문은 다음과 같아야 합니다.

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

디버그 모드 활성화

SSSD의 디버그 로그는 문제를 해결하는 데 유용할 수 있습니다. 디버그 모드를 활성화하려면 클러스터 구성을 다음과 같이 변경하여 클러스터를 업데이트해야 합니다.

DirectoryService:
  AdditionalSssdConfigs:
    debug_level: "0x1ff"

LDAPS에서 LDAP로 이동하는 방법

LDAPS(TLS/SSL을 사용하는 LDAP)에서 LDAP로 전환하는 것은 권장되지 않습니다. LDAP만으로는 암호화가 제공되지 않기 때문입니다. 하지만 테스트 목적과 문제 해결에는 유용할 수 있습니다.

클러스터를 이전 구성 정의로 업데이트하여 클러스터를 이전 구성으로 복원할 수 있습니다.

LDAPS에서 LDAP로 이동하려면 클러스터 구성을 다음과 같이 변경하여 클러스터를 업데이트해야 합니다.

DirectoryService:
  LdapTlsReqCert: never
  AdditionalSssdConfigs:
    ldap_auth_disable_tls_never_use_in_production: True

LDAPS 서버 인증서 검증을 비활성화하는 방법

테스트 또는 문제 해결을 위해 헤드 노드에서 LDAPS 서버 인증서 검증을 일시적으로 비활성화하는 것이 유용할 수 있습니다.

클러스터를 이전 구성 정의로 업데이트하여 클러스터를 이전 구성으로 복원할 수 있습니다.

LDAPS 서버 인증서 검증을 사용하지 않도록 설정하려면 클러스터 구성에서 다음과 같이 변경하여 클러스터를 업데이트해야 합니다.

DirectoryService:
  LdapTlsReqCert: never

암호 대신 SSH 키를 사용하여 로그인하는 방법

SSH 키는 처음으로 암호를 사용하여 로그인한 후 /home/$user/.ssh/id_rsa에 생성됩니다. SSH 키로 로그인하려면 암호로 로그인하고 SSH 키를 로컬로 복사한 다음 평소와 같이 이를 사용하여 암호 없이 SSH 작업을 수행해야 합니다.

$ ssh -i $LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip

사용자 암호 및 만료된 암호를 재설정하는 방법

사용자가 클러스터에 액세스할 수 없는 경우 AWS Managed Microsoft AD 암호가 만료되었을 수 있습니다.

암호를 재설정하려면 디렉터리에 대한 쓰기 권한이 있는 사용자 및 역할과 함께 다음 명령을 실행합니다.

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

DirectoryService/DomainReadOnlyUser의 비밀번호를 재설정한 경우:

  1. DirectoryService/PasswordSecretArn 암호를 새 암호로 업데이트해야 합니다.

  2. 새 암호 값에 맞게 클러스터를 업데이트하세요.

    1. pcluster update-compute-fleet 명령을 사용하여 컴퓨팅 플릿을 중지합니다.

    2. 클러스터 헤드 노드 내에서 다음 명령을 실행합니다.

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

암호를 재설정하고 클러스터를 업데이트한 후에는 사용자의 클러스터 액세스를 복원해야 합니다.

자세한 내용은AWS Directory Service 관리 안내서의 사용자 암호 재설정을 참조하세요.

조인한 도메인을 확인하는 방법

다음 명령은 헤드 노드가 아닌 도메인에 가입된 인스턴스에서 실행해야 합니다.

$ 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

인증서 문제를 해결하는 방법

LDAPS 통신이 작동하지 않는 경우 TLS 통신 오류 때문일 수 있으며, 이는 인증서 문제 때문일 수 있습니다.

인증서에 대한 참고 사항:

  • 클러스터 구성 LdapTlsCaCert에 지정된 인증서는 도메인 컨트롤러용 인증서를 발급한 전체 CA(인증 기관) 체인의 인증서를 포함하는 PEM 인증서 번들이어야 합니다.

  • PEM 인증서 번들은 PEM 인증서를 연결하여 만든 파일입니다.

  • PEM 형식의 인증서(일반적으로 Linux에서 사용됨)는 base64 DER 형식의 인증서(일반적으로 Windows에서 내보내는 인증서)와 동일합니다.

  • 도메인 컨트롤러용 인증서를 하위 CA에서 발급한 경우 인증서 번들에는 하위 CA와 루트 CA의 인증서가 모두 포함되어야 합니다.

문제 해결 확인 단계:

다음 확인 단계에서는 명령이 클러스터 헤드 노드 내에서 실행되고 도메인 컨트롤러가 SERVER:PORT에 연결할 수 있다고 가정합니다.

인증서와 관련된 문제를 해결하려면 다음 확인 단계를 따르세요.

확인 단계:

  1. Active Directory 도메인 컨트롤러에 대한 연결을 확인하세요.

    도메인 컨트롤러에 연결할 수 있는지 확인합니다. 이 단계가 성공하면 도메인 컨트롤러에 대한 SSL 연결이 성공하고 인증서가 확인됩니다. 사용자의 문제는 인증서와 관련이 없습니다.

    이 단계가 실패하면 다음 확인을 진행하세요.

    $ openssl s_client -connect SERVER:PORT -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE

  2. 인증서 검증 확인:

    로컬 CA 인증서 번들이 도메인 컨트롤러에서 제공한 인증서를 검증할 수 있는지 확인하세요. 이 단계가 성공하면 문제는 인증서와 관련된 것이 아니라 다른 네트워킹 문제와 관련이 있는 것입니다.

    이 단계가 실패하면 다음 확인을 진행하세요.

    $ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE

  3. Active Directory 도메인 컨트롤러에서 제공된 인증서를 확인하세요.

    도메인 컨트롤러가 제공한 인증서의 내용이 예상한 것과 같은지 확인하세요. 이 단계가 성공하면 컨트롤러 확인에 사용된 CA 인증서에 문제가 있을 수 있습니다. 다음 문제 해결 단계로 이동하세요.

    이 단계가 실패할 경우 도메인 컨트롤러용으로 발급된 인증서를 수정하고 문제 해결 단계를 다시 실행해야 합니다.

    $ openssl s_client -connect SERVER:PORT -showcerts

  4. 인증서 내용 확인:

    도메인 컨트롤러가 제공한 인증서의 내용이 예상한 것과 같은지 확인하세요. 이 단계가 성공하면 컨트롤러 확인에 사용된 CA 인증서에 문제가 있을 수 있습니다. 다음 문제 해결 단계로 이동하세요.

    이 단계가 실패할 경우 도메인 컨트롤러용으로 발급된 인증서를 수정하고 문제 해결 단계를 다시 실행해야 합니다.

    $ openssl s_client -connect SERVER:PORT -showcerts

  5. 로컬 CA 인증서 번들의 내용을 확인하세요.

    도메인 컨트롤러 인증서를 검증하는 데 사용되는 로컬 CA 인증서 번들의 내용이 예상과 같은지 확인하세요. 이 단계가 성공하면 도메인 컨트롤러에서 제공하는 인증서에 문제가 있을 수 있습니다.

    이 단계가 실패할 경우 도메인 컨트롤러용으로 발급된 CA 인증서 번들을 수정하고 문제 해결 단계를 다시 실행해야 합니다.

    $ openssl x509 -in PATH_TO_A_CERTIFICATE -text

Active Directory와의 통합이 제대로 작동하는지 확인하는 방법

다음 두 가지 검사가 성공하면 Active Directory와의 통합이 작동하는 것입니다.

확인:

  1. 디렉터리에 정의된 사용자를 검색할 수 있습니다.

    클러스터 헤드 노드 내에서 ec2-user로서:

    $ getent passwd $ANY_AD_USER

  2. 사용자 비밀번호를 제공하여 헤드 노드에 SSH로 연결할 수 있습니다.

    $ ssh $ANY_AD_USER@$HEAD_NODE_IP

검사 1이 실패하면 검사 2도 실패할 것으로 예상됩니다.

추가 문제 해결 확인:

컴퓨팅 노드 로그인 문제를 해결하는 방법

이 섹션은 Active Directory와 통합된 클러스터의 컴퓨팅 노드에 로그인하는 것과 관련이 있습니다.

를 사용하면 AWS ParallelCluster클러스터 컴퓨팅 노드에 대한 암호 로그인이 설계상 비활성화됩니다.

모든 사용자는 자신의 SSH 키를 사용하여 컴퓨팅 노드에 로그인해야 합니다.

클러스터 구성에서 GenerateSshKeysForUsers가 활성화된 경우 사용자는 첫 번째 인증(예: 로그인) 후 헤드 노드에서 SSH 키를 검색할 수 있습니다.

사용자가 헤드 노드에서 처음으로 인증하는 경우 디렉터리 사용자를 위해 자동으로 생성되는 SSH 키를 검색할 수 있습니다. 사용자의 홈 디렉터리도 생성됩니다. sudo-user가 헤드 노드의 사용자로 처음 전환할 때도 이런 일이 발생할 수 있습니다.

사용자가 헤드 노드에 로그인하지 않은 경우 SSH 키는 생성되지 않으며 사용자는 컴퓨팅 노드에 로그인할 수 없습니다.

다중 사용자 환경에서 SimCenter StarCCM+ 작업과 관련된 알려진 문제

이 섹션은 Siemens의 Simcenter StarCCM+ 전산 유체 역학 소프트웨어가 다중 사용자 환경에서 시작한 작업과 관련이 있습니다.

내장된 IntelMPI를 사용하도록 구성된 StarCCM+ v16 작업을 실행하는 경우 기본적으로 MPI 프로세스는 SSH를 사용하여 부트스트랩됩니다.

사용자 이름 확인이 잘못되게 하는 알려진 Slurm 버그로 인해 작업이 실패하고 error setting up the bootstrap proxies 같은 오류가 발생할 수 있습니다. 이 버그는 AWS ParallelCluster 버전 3.1.1 및 3.1.2에만 영향을 미칩니다.

이러한 문제를 방지하려면 IntelMPI가 Slurm을 MPI 부트스트랩 방법으로 사용하도록 강제하세요. IntelMPI 공식 설명서에 설명된 대로 StarCCM+를 시작하는 작업 스크립트로 환경 변수 I_MPI_HYDRA_BOOTSTRAP=slurm를 내보냅니다.

사용자 이름 확인과 관련된 알려진 문제

이 섹션은 작업 내에서 사용자 이름을 검색하는 것과 관련이 있습니다.

Slurm의 알려진 버그로 인해 srun 없이 작업을 실행하면 작업 프로세스 내에서 검색된 사용자 이름은 nobody일 수 있습니다. 이 버그는 AWS ParallelCluster 버전 3.1.1 및 3.1.2에만 영향을 미칩니다.

예를 들어 디렉터리 사용자로 명령 sbatch --wrap 'srun id'을 실행하면 올바른 사용자 이름이 반환됩니다. 하지만 디렉터리 사용자로 sbatch --wrap 'id'를 실행하면 사용자 이름으로 nobody가 반환될 수 있습니다.

다음 해결 방법을 사용할 수 있습니다.

  1. 가능하면 'srun' 대신 'sbatch'를 사용하여 작업을 시작하세요.

  2. 다음과 같이 클러스터 구성에서 AdditionalSssd구성을 설정하여 SSSD 열거를 활성화합니다.

    AdditionalSssdConfigs:
  enumerate: true

홈 디렉터리 생성 문제를 해결하는 방법

이 섹션은 홈 디렉터리 생성 문제와 관련이 있습니다.

다음 예와 같은 오류가 표시되면 헤드 노드에 처음 로그인했을 때 홈 디렉터리가 자동으로 생성되지 않은 것입니다. 또는 sudoer에서 헤드 노드의 Active Directory 사용자로 처음 전환했을 때 홈 디렉터리가 자동으로 생성되지 않은 경우도 있습니다.

$ 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

홈 디렉터리 생성 실패는 클러스터 헤드 노드에 설치된 oddjob 및 oddjob-mkhomedir 패키지로 인해 발생할 수 있습니다.

홈 디렉터리와 SSH 키가 없으면 사용자는 클러스터 노드에 작업이나 SSH를 제출할 수 없습니다.

시스템에 oddjob 패키지가 필요한 경우 oddjobd 서비스가 실행 중인지 확인하고 PAM 구성 파일을 새로 고쳐 홈 디렉터리가 생성되었는지 확인하세요. 이렇게 하려면 다음 예와 같이 헤드 노드에서 명령을 실행하세요.

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

시스템에 oddjob 패키지가 필요하지 않은 경우 패키지를 제거하고 PAM 구성 파일을 새로 고쳐 홈 디렉터리가 생성되었는지 확인하세요. 이렇게 하려면 다음 예와 같이 헤드 노드에서 명령을 실행하세요.

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