기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Active Directory와의 다중 사용자 통합 문제 해결
이 섹션은 Active Directory와 통합된 클러스터와 관련이 있습니다.
Active Directory 통합 기능이 예상대로 작동하지 않는 경우 SSSD 로그가 유용한 진단 정보를 제공할 수 있습니다. 이러한 로그는 클러스터 노드의 `/var/log/sssd`에 있습니다. 기본적으로 클러스터의 Amazon CloudWatch 로그 그룹에도 저장됩니다.
**Topics**
+ [
## Active Directory 관련 문제 해결
](#troubleshooting-v3-multi-ad-specific)
+ [
## 디버그 모드 활성화
](#troubleshooting-v3-multi-user-debug)
+ [
## LDAPS에서 LDAP로 이동하는 방법
](#troubleshooting-v3-multi-user-ldaps-ldap)
+ [
## LDAPS 서버 인증서 검증을 비활성화하는 방법
](#troubleshooting-v3-multi-user-ldaps-verify)
+ [
## 암호 대신 SSH 키를 사용하여 로그인하는 방법
](#troubleshooting-v3-multi-user-ssh-login)
+ [
## 사용자 암호 및 만료된 암호를 재설정하는 방법
](#troubleshooting-v3-multi-user-reset-passwd)
+ [
## 조인한 도메인을 확인하는 방법
](#troubleshooting-v3-multi-user-domain-verify)
+ [
## 인증서 문제를 해결하는 방법
](#troubleshooting-v3-multi-user-certificates)
+ [
## Active Directory와의 통합이 제대로 작동하는지 확인하는 방법
](#troubleshooting-v3-multi-user-ad-verify)
+ [
## 컴퓨팅 노드 로그인 문제를 해결하는 방법
](#troubleshooting-v3-multi-user-ad-compute-node-login)
+ [
## 다중 사용자 환경에서 SimCenter StarCCM\$1 작업과 관련된 알려진 문제
](#troubleshooting-v3-multi-user-ad-starccm)
+ [
## 사용자 이름 확인과 관련된 알려진 문제
](#troubleshooting-v3-multi-user-name-resolution)
+ [
## 홈 디렉터리 생성 문제를 해결하는 방법
](#troubleshooting-v3-multi-home-directory)
## 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 암호가 만료되었을 수 있습니다](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_password_policies.html).
암호를 재설정하려면 디렉터리에 대한 쓰기 권한이 있는 사용자 및 역할과 함께 다음 명령을 실행합니다.
```
$ aws ds reset-user-password \
--directory-id "d-abcdef01234567890" \
--user-name "USER_NAME" \
--new-password "NEW_PASSWORD" \
--region "region-id"
```
[`DirectoryService`](DirectoryService-v3.md)/[`DomainReadOnlyUser`](DirectoryService-v3.md#yaml-DirectoryService-DomainReadOnlyUser)의 비밀번호를 재설정한 경우:
1. [`DirectoryService`](DirectoryService-v3.md)/[`PasswordSecretArn`](DirectoryService-v3.md#yaml-DirectoryService-PasswordSecretArn) 암호를 새 암호로 업데이트해야 합니다.
1. 새 암호 값에 맞게 클러스터를 업데이트하세요.
1. `pcluster update-compute-fleet` 명령을 사용하여 컴퓨팅 플릿을 중지합니다.
1. 클러스터 헤드 노드 내에서 다음 명령을 실행합니다.
```
$ sudo /opt/parallelcluster/scripts/directory_service/update_directory_service_password.sh
```
암호를 재설정하고 클러스터를 업데이트한 후에는 사용자의 클러스터 액세스를 복원해야 합니다.
자세한 내용은Directory Service 관리 안내서**의 [사용자 암호 재설정](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_reset_password.html)을 참조하세요.
## 조인한 도메인을 확인하는 방법
다음 명령은 헤드 노드가 아닌 도메인에 가입된 인스턴스에서 실행해야 합니다.
```
$ 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
```
1. 인증서 검증 확인:****
로컬 CA 인증서 번들이 도메인 컨트롤러에서 제공한 인증서를 검증할 수 있는지 확인하세요. 이 단계가 성공하면 문제는 인증서와 관련된 것이 아니라 다른 네트워킹 문제와 관련이 있는 것입니다.
이 단계가 실패하면 다음 확인을 진행하세요.
```
$ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE
```
1. Active Directory 도메인 컨트롤러에서 제공된 인증서를 확인하세요.****
도메인 컨트롤러가 제공한 인증서의 내용이 예상한 것과 같은지 확인하세요. 이 단계가 성공하면 컨트롤러 확인에 사용된 CA 인증서에 문제가 있을 수 있습니다. 다음 문제 해결 단계로 이동하세요.
이 단계가 실패할 경우 도메인 컨트롤러용으로 발급된 인증서를 수정하고 문제 해결 단계를 다시 실행해야 합니다.
```
$ openssl s_client -connect SERVER:PORT -showcerts
```
1. 인증서 내용 확인:****
도메인 컨트롤러가 제공한 인증서의 내용이 예상한 것과 같은지 확인하세요. 이 단계가 성공하면 컨트롤러 확인에 사용된 CA 인증서에 문제가 있을 수 있습니다. 다음 문제 해결 단계로 이동하세요.
이 단계가 실패할 경우 도메인 컨트롤러용으로 발급된 인증서를 수정하고 문제 해결 단계를 다시 실행해야 합니다.
```
$ openssl s_client -connect SERVER:PORT -showcerts
```
1. 로컬 CA 인증서 번들의 내용을 확인하세요.****
도메인 컨트롤러 인증서를 검증하는 데 사용되는 로컬 CA 인증서 번들의 내용이 예상과 같은지 확인하세요. 이 단계가 성공하면 도메인 컨트롤러에서 제공하는 인증서에 문제가 있을 수 있습니다.
이 단계가 실패할 경우 도메인 컨트롤러용으로 발급된 CA 인증서 번들을 수정하고 문제 해결 단계를 다시 실행해야 합니다.
```
$ openssl x509 -in PATH_TO_A_CERTIFICATE -text
```
## Active Directory와의 통합이 제대로 작동하는지 확인하는 방법
다음 두 가지 검사가 성공하면 Active Directory와의 통합이 작동하는 것입니다.
확인:****
1. 디렉터리에 정의된 사용자를 검색할 수 있습니다.****
클러스터 헤드 노드 내에서 `ec2-user`로서:
```
$ getent passwd $ANY_AD_USER
```
1. 사용자 비밀번호를 제공하여 헤드 노드에 SSH로 연결할 수 있습니다.****
```
$ ssh $ANY_AD_USER@$HEAD_NODE_IP
```
검사 1이 실패하면 검사 2도 실패할 것으로 예상됩니다.
추가 문제 해결 확인:
+ 사용자가 디렉터리에 있는지 확인하세요.
+ [디버그 로깅](#troubleshooting-v3-multi-user-debug) 활성화
+ LDAPS 문제를 배제하려면 [LDAPS에서 LDAP로 이동하여](#troubleshooting-v3-multi-user-ldaps-ldap) 암호화를 일시적으로 비활성화하는 것이 좋습니다.
## 컴퓨팅 노드 로그인 문제를 해결하는 방법
이 섹션은 Active Directory와 통합된 클러스터의 컴퓨팅 노드에 로그인하는 것과 관련이 있습니다.
를 사용하면 클러스터 컴퓨팅 노드에 대한 AWS ParallelCluster암호 로그인이 설계상 비활성화됩니다.
모든 사용자는 자신의 SSH 키를 사용하여 컴퓨팅 노드에 로그인해야 합니다.
클러스터 구성에서 [`GenerateSshKeysForUsers`](DirectoryService-v3.md#yaml-DirectoryService-GenerateSshKeysForUsers)가 활성화된 경우 사용자는 첫 번째 인증(예: 로그인) 후 헤드 노드에서 SSH 키를 검색할 수 있습니다.
사용자가 헤드 노드에서 처음으로 인증하는 경우 디렉터리 사용자를 위해 자동으로 생성되는 SSH 키를 검색할 수 있습니다. 사용자의 홈 디렉터리도 생성됩니다. sudo-user가 헤드 노드의 사용자로 처음 전환할 때도 이런 일이 발생할 수 있습니다.
사용자가 헤드 노드에 로그인하지 않은 경우 SSH 키는 생성되지 않으며 사용자는 컴퓨팅 노드에 로그인할 수 없습니다.
## 다중 사용자 환경에서 SimCenter StarCCM\$1 작업과 관련된 알려진 문제
이 섹션은 Siemens의 Simcenter StarCCM\$1 전산 유체 역학 소프트웨어가 다중 사용자 환경에서 시작한 작업과 관련이 있습니다.
내장된 IntelMPI를 사용하도록 구성된 StarCCM\$1 v16 작업을 실행하는 경우 기본적으로 MPI 프로세스는 SSH를 사용하여 부트스트랩됩니다.
사용자 이름 확인이 잘못되게 하는 알려진 [Slurm 버그](https://bugs.schedmd.com/show_bug.cgi?id=13385)로 인해 작업이 실패하고 `error setting up the bootstrap proxies` 같은 오류가 발생할 수 있습니다. 이 버그는 AWS ParallelCluster 버전 3.1.1 및 3.1.2에만 영향을 줍니다.
이러한 문제를 방지하려면 IntelMPI가 Slurm을 MPI 부트스트랩 방법으로 사용하도록 강제하세요. [IntelMPI 공식 설명서](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/hydra-environment-variables.html)에 설명된 대로 StarCCM\$1를 시작하는 작업 스크립트로 환경 변수 `I_MPI_HYDRA_BOOTSTRAP=slurm`를 내보냅니다.
## 사용자 이름 확인과 관련된 알려진 문제
이 섹션은 작업 내에서 사용자 이름을 검색하는 것과 관련이 있습니다.
[Slurm의 알려진 버그](https://bugs.schedmd.com/show_bug.cgi?id=13385)로 인해 `srun` 없이 작업을 실행하면 작업 프로세스 내에서 검색된 사용자 이름은 `nobody`일 수 있습니다. 이 버그는 AWS ParallelCluster 버전 3.1.1 및 3.1.2에만 영향을 줍니다.
예를 들어 디렉터리 사용자로 명령 `sbatch --wrap 'srun id'`을 실행하면 올바른 사용자 이름이 반환됩니다. 하지만 디렉터리 사용자로 `sbatch --wrap 'id'`를 실행하면 사용자 이름으로 `nobody`가 반환될 수 있습니다.
다음 해결 방법을 사용할 수 있습니다.
1. 가능하면 `'srun'` 대신 `'sbatch'`를 사용하여 작업을 시작하세요.
1. 다음과 같이 클러스터 구성에서 [AdditionalSssdConfigs](DirectoryService-v3.md#yaml-DirectoryService-AdditionalSssdConfigs)를 설정하여 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
```