기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # AWS 관리형 Microsoft AD 문제 해결 다음은 AWS 관리형 Microsoft AD Active Directory를 생성하거나 사용할 때 발생할 수 있는 몇 가지 일반적인 문제를 해결하는 데 도움이 될 수 있습니다. ## AWS 관리형 Microsoft AD 관련 문제 일부 문제 해결 작업은 지원에서만 완료할 수 있습니다. 다음은 몇 가지 작업입니다. + Directory Service제공된 도메인 컨트롤러를 다시 시작합니다. + [AWS 관리형 Microsoft AD 업그레이드](ms_ad_upgrade_edition.md). 지원 사례를 생성하려면 [지원 사례 및 사례 관리 생성](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)을 참조하세요. ## Netlogon 및 보안 채널 통신 관련 문제 [CVE-2020-1472](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1472)에 대한 완화 조치로, Microsoft에서는 도메인 컨트롤러에서 Netlogon 보안 채널 통신을 처리하는 방식을 수정하는 패치를 릴리스했습니다. 이러한 보안 Netlogon 변경 사항이 도입된 이후 일부 Netlogon 연결(서버, 워크스테이션 및 신뢰 검증)은 AWS 관리형 Microsoft AD에서 수락되지 않을 수 있습니다. 문제가 Netlogon 또는 보안 채널 통신과 관련이 있는지 확인하려면 Amazon CloudWatch Logs에서 이벤트 ID 5827(디바이스 인증 관련 문제의 경우) 또는 5828(AD 신뢰 검증 관련 문제의 경우)을 검색하세요. AWS Managed Microsoft AD의 CloudWatch에 대한 자세한 내용은 을(를) 참조하세요. [AWS 관리형 Microsoft AD에 대한 Amazon CloudWatch Logs 로그 전달 활성화](ms_ad_enable_log_forwarding.md) CVE-2020-1472 완화에 대한 자세한 내용은 Microsoft 웹 사이트에서 [CVE-2020-1472 관련 Netlogon 보안 채널 연결의 변경 사항을 관리하는 방법](https://support.microsoft.com/en-us/topic/how-to-manage-the-changes-in-netlogon-secure-channel-connections-associated-with-cve-2020-1472-f7e8cc17-0309-1d6a-304e-5ba73cd1a11e)을 참조하세요. ## 사용자의 암호를 재설정하려고 할 때 '응답 상태: 400 잘못된 요청' 오류가 발생합니다. 사용자의 암호를 재설정하려고 할 때 다음과 비슷한 오류 메시지가 표시됩니다. `Response Status: 400 Bad Request` AWS 관리형 Microsoft AD 조직 단위(OU)에 동일한 사용자 로그온 이름을 가진 중복 객체가 있는 경우이 문제가 발생할 수 있습니다. 사용자 로그온 이름은 고유해야 합니다. 자세한 내용은 Microsoft 설명서의 [디렉터리 데이터 문제 해결을](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/bb727059(v=technet.10)?redirectedfrom=MSDN) 참조하세요. ## 암호 복구 사용자가 비밀번호를 잊어버리거나 AWS 관리형 Microsoft AD 디렉토리에 로그인하는 데 문제가 있는 경우 AWS Management Console, PowerShell 또는 AWS CLI를 사용하여 비밀번호를 재설정할 수 있습니다. 자세한 내용은 [AWS 관리형 Microsoft AD 사용자 암호 재설정](ms_ad_manage_users_groups_reset_password.md) 단원을 참조하십시오. ## 추가 리소스 다음 리소스는 작업 시 문제를 해결하는 데 도움이 될 수 있습니다 AWS. + **[AWS 지식 센터](https://aws.amazon.com/premiumsupport/knowledge-center/)** - 문제 해결에 도움이 되는 FAQs 및 다른 리소스에 대한 링크를 찾습니다. + **[AWS 지원 센터](https://console.aws.amazon.com/support/home#/)** - 기술 지원을 받습니다. + **[AWS 프리미엄 지원 센터](https://aws.amazon.com/premiumsupport/)** - 프리미엄 기술 지원을 받으세요. 다음 리소스는 일반적인 Active Directory 문제를 해결하는 데 도움이 될 수 있습니다. + [Active Directory 설명서](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/active-directory-overview) + [AD DS 문제 해결](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/ad-ds-troubleshooting) **Topics** + [AWS 관리형 Microsoft AD 관련 문제](#general_issues) + [Netlogon 및 보안 채널 통신 관련 문제](#ms_ad_tshoot_netlogon_issues) + [사용자의 암호를 재설정하려고 할 때 '응답 상태: 400 잘못된 요청' 오류가 발생합니다.](#ms_ad_tshoot_reset_password) + [암호 복구](#ms_ad_tshoot_password_recovery) + [추가 리소스](#troubleshoot_general_resources) + [Amazon EC2 Linux 인스턴스 도메인 조인 오류](ms_ad_troubleshooting_join_linux.md) + [AWS 관리형 Microsoft AD 사용 가능한 스토리지 공간 부족](ms_ad_troubleshooting_low_storage_space.md) + [스키마 확장 오류](ms_ad_troubleshooting_schema.md) + [신뢰 생성 상태 이유](ms_ad_troubleshooting_trusts.md) + [AWS 관리형 Microsoft AD 높은 CPU 사용률 문제 해결](ms_ad_troubleshooting_high_cpu.md) # Amazon EC2 Linux 인스턴스 도메인 조인 오류 다음은 Amazon EC2 Linux 인스턴스를 AWS Managed Microsoft AD 디렉터리에 조인할 때 발생할 수 있는 몇 가지 오류 메시지를 해결하는 데 도움이 될 수 있습니다. ## Linux 인스턴스가 도메인에 조인을 할 수 없거나, 인증을 할 수 없는 경우 영역이 Microsoft Active Directory에서 작동하려면 먼저 DNS에서 Ubuntu 14.04, 16.04 및 18.04 인스턴스가 *반드시* 역방향 확인 가능해야 합니다. 그렇지 않으면 다음 두 가지 시나리오 중 하나가 발생할 수 있습니다. ### 시나리오 1: 영역에 아직 조인되지 않은 Ubuntu 인스턴스 영역을 조인하려고 시도 중인 Ubuntu 인스턴스의 경우 `sudo realm join` 명령을 실행하면 도메인을 조인하는 데 필요한 권한이 제공되지 않을 수 있으며 다음 오류가 표시될 수 있습니다. \$1 Active Directory에 인증할 수 없음: SASL(-1): 일반 실패: GSSAPI 오류: 잘못된 이름이 제공되었음 (성공) adcli: EXAMPLE.COM 도메인에 연결할 수 없음: Active Directory에 인증할 수 없음: SASL(-1): 일반 실패: GSSAPI 오류: 잘못된 이름이 제공되었음 (성공) \$1 도메인 영역에 조인할 권한 부족: 영역에 조인할 수 없음: 도메인에 조인할 권한 부족 ### 시나리오 2: 영역에 조인된 Ubuntu 인스턴스 Microsoft Active Directory 도메인에 이미 조인된 Ubuntu 인스턴스의 경우 도메인 자격 증명을 사용하여 인스턴스에 SSH 접속하려고 시도하면 다음 오류가 표시되면서 실패할 수 있습니다. \$1 ssh admin@EXAMPLE.COM@198.51.100 해당 자격 증명 없음: /Users/username/.ssh/id\$1ed25519: 해당 파일 또는 디렉터리 없음 admin@EXAMPLE.COM@198.51.100의 암호: 권한이 거부되었습니다. 다시 시도하세요. admin@EXAMPLE.COM@198.51.100의 암호: 퍼블릭 키를 사용하여 인스턴스에 로그인하고 확인하면`/var/log/auth.log` 다음과 같이 사용자를 찾을 수 없다는 내용의 오류가 나타날 수 있습니다. 5월 12일 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1unix(sshd:auth): 인증 실패; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.0 5월 12일 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1sss(sshd:auth): 인증 실패; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.0 user=admin@EXAMPLE.COM 5월 12일 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1sss(sshd:auth): admin@EXAMPLE.COM 사용자에 대해 수신됨: 10 (기본 인증 모듈에서 알 수 없는 사용자) 5월 12일 01:02:14 ip-192-0-2-0 sshd[2251]: 203.0.113.0 포트 13344 ssh2에서 잘못된 사용자 admin@EXAMPLE.COM의 암호 실패 5월 12일 01:02:15 ip-192-0-2-0 sshd[2251]: Connection closed by 203.0.113.0에서 연결 닫힘 [preauth] 하지만 사용자에 대한 `kinit`는 여전히 작동합니다. 이 예제를 참조하세요. ubuntu@ip-192-0-2-0:\$1\$1 kinit admin@EXAMPLE.COM admin@EXAMPLE.COM의 암호: ubuntu@ip-192-0-2-0:\$1\$1 klist 티켓 캐시: FILE:/tmp/krb5cc\$11000 기본 보안 주체: admin@EXAMPLE.COM ### 차선책 이러한 두 시나리오 모두에 대해 현재 권장되는 해결 방법은 아래와 같이 [libdefaults] 섹션의 `/etc/krb5.conf`에서 역방향 DNS를 비활성화하는 것입니다. ``` [libdefaults] default_realm = EXAMPLE.COM rdns = false ``` ## 원활한 도메인 조인 시 단방향 신뢰 인증 문제 AWS 관리형 Microsoft AD와 온프레미스 Active Directory 간에 단방향 발신 신뢰가 설정된 경우 Winbind에서 신뢰할 수 있는 Active Directory 자격 증명을 사용하여 도메인에 조인된 Linux 인스턴스에 대해 인증을 시도할 때 인증 문제가 발생할 수 있습니다. ### 오류 7월 31일 00:00:00 EC2Amaz-LSMWQT sshd [23832]: xxx.xxx.xxx.xxx 포트 18309 ssh2에서 user@corp.example.com 암호 실패 7월 31일 00:05:00 EC2Amaz-LSMWQT sshd [23832]: pam\$1winbind (sshd:auth): 암호 얻기 (0x00000390) 7월 31일 00:05:00 EC2Amaz-LSMWQT sshd [23832]: pam\$1winbind (sshd:auth): pam\$1get\$1item에서 암호를 반환함 7월 31일 00:05:00 EC2Amaz-LSMWQT sshd [23832]: pam\$1winbind (sshd:auth): 요청 wbcLogonUser 실패: WBC\$1ERR\$1AUTH\$1ERR, PAM 오류: PAM\$1SYSTEM\$1ERR (4), NTSTATUS: \$1\$1NT\$1STATUS\$1OBJECT\$1NAME\$1NOT\$1FOUND\$1\$1, 오류 메시지 내용: The object name is not found. 7월 31일 00:05:00 EC2Amaz-LSMWQT sshd [23832]: pam\$1winbind (sshd:auth): 내부 모듈 오류(retval = PAM\$1SYSTEM\$1ERR(4), user = 'CORP\$1user') ## 차선책 이 문제를 해결하려면 다음과 같은 단계를 사용하여 PAM 모듈 구성 파일(`/etc/security/pam_winbind.conf`)에서 디렉티브를 주석 처리하거나 제거해야 합니다. 1. 텍스트 편집기에서 `/etc/security/pam_winbind.conf` 파일을 엽니다. ``` sudo vim /etc/security/pam_winbind.conf ``` 1. **krb5\$1auth = yes**라는 디렉티브를 주석 처리하거나 삭제하세요. ``` [global] cached_login = yes krb5_ccache_type = FILE #krb5_auth = yes ``` 1. Winbind 서비스를 중지한 다음 다시 시작하세요. ``` service winbind stop or systemctl stop winbind net cache flush service winbind start or systemctl start winbind ``` # AWS 관리형 Microsoft AD 사용 가능한 스토리지 공간 부족 사용 가능한 스토리지 공간이 부족하여 AWS 관리형 Microsoft AD가 손상된 경우 디렉터리를 활성 상태로 되돌리려면 즉각적인 조치가 필요합니다. 이 손상의 가장 일반적인 두 가지 원인은 아래 단원에서 다룹니다. 1. [SYSVOL 폴더가 필수 그룹 정책 객체 이상을 저장하는 중](#sysvol-folder-gpo) 1. [Active Directory 데이터베이스가 볼륨을 채움](#ad-db-filled-volume) AWS 관리형 Microsoft AD 스토리지에 대한 요금 정보는 [Directory Service 요금을](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table) 참조하세요. ## SYSVOL 폴더가 필수 그룹 정책 객체 이상을 저장하는 중 이러한 손상의 일반적인 원인은 그룹 정책 처리를 위해 필수적이지 않은 파일을 SYSVOL 폴더에 저장하기 때문입니다. 이러한 필수적이지 않은 파일은 EXE, MSI 또는 그룹 정책에서 처리하는 데 필수적이지 않은 기타 파일일 수 있습니다. 그룹 정책에서 처리할 필수 객체는 그룹 정책 객체, 로그온/오프 스크립트 및 [그룹 정책용 중앙 저장소 객체](https://learn.microsoft.com/en-us/troubleshoot/windows-client/group-policy/create-and-manage-central-store)입니다. 필수적이지 않은 파일은 AWS Managed Microsoft AD 도메인 컨트롤러 이외의 파일 서버(들)에 저장해야 합니다. [그룹 정책 소프트웨어 설치](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/use-group-policy-to-install-software)용 파일이 필요한 경우, 파일 서버를 사용하여 해당 설치 파일을 저장해야 합니다. 파일 서버를 자체 관리하지 않으려면 관리형 파일 서버 옵션인 [Amazon FSx](https://aws.amazon.com/fsx/)를 AWS 제공합니다. 불필요한 파일을 제거하기 위해 범용 이름 지정 규칙(UNC) 경로를 통해 SYSVOL 공유에 액세스할 수 있습니다. 예를 들어 도메인의 완전히 정규화된 도메인 이름(FQDN)이 example.com인 경우, SYSVOL의 UNC 경로는 ‘\$1\$1example.local\$1SYSVOL\$1example.local\$1’입니다. 그룹 정책에서 디렉터리를 처리하는 데 필수적이지 않은 객체를 찾아서 제거하면 30분 이내에 활성 상태로 돌아갑니다. 30분 후에도 디렉터리가 활성화되지 않으면 AWS Support에 문의하십시오. SYSVOL 공유에 필수 그룹 정책 파일만 저장하면 SYSVOL 부풀림으로 인해 디렉터리가 손상되지 않습니다. ## Active Directory 데이터베이스가 볼륨을 채움 이러한 손상의 일반적인 원인은 Active Directory 데이터베이스가 볼륨을 가득 채우기 때문입니다. 이러한 경우인지 확인하기 위해 디렉터리의 **총** 객체 수를 검토할 수 있습니다. **삭제된** 객체는 여전히 디렉터리의 총 개체 수에 포함된다는 점을 이해하실 수 있도록 **총계**라는 글자를 굵게 표시합니다. 기본적으로 AWS 관리형 Microsoft AD는 항목이 재활용 객체가 되기 전에 180일 동안 AD 재활용통에 보관합니다. 객체가 재활용 객체(삭제 표시)가 되면 해당 객체가 디렉터리에서 최종적으로 제거되기 전에 180일 동안 보관됩니다. 따라서 삭제된 객체는 제거되기 전 360일 동안 디렉터리 데이터베이스에 존재합니다. 이 이유 때문에 총 객체 수를 평가해야 합니다. AWS 관리형 Microsoft AD 지원 객체 수에 대한 자세한 내용은 [Directory Service 요금을](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table) 참조하세요. 삭제된 객체가 포함된 디렉터리의 총 객체 수를 가져오려면 도메인이 조인된 Windows 인스턴스에서 다음 PowerShell 명령을 실행하면 됩니다. 관리 인스턴스를 설정하는 방법의 단계는 [AWS 관리형 Microsoft AD의 사용자 및 그룹 관리](ms_ad_manage_users_groups.md) 단원을 참조하세요. ``` Get-ADObject -Filter * -IncludeDeletedObjects | Measure-Object -Property 'Count' | Select-Object -Property 'Count' ``` 다음은 위 명령의 출력 예입니다. ``` Count 10000 ``` 총 개수가 위의 참고 내용에 나열된 디렉터리 크기에 대해 지원되는 객체 수보다 크면 디렉터리의 용량을 초과한 것입니다. 다음은 이러한 손상을 해결할 수 있는 옵션입니다. 1. AD 정리 1. 원치 않는 AD 객체를 삭제합니다. 1. AD 휴지통에서 원하지 않는 객체를 모두 제거합니다. 이 작업은 실행 취소할 수 없으며, 삭제된 객체를 복구할 수 있는 유일한 방법은 디렉터리 복원을 수행하는 것입니다. 1. 다음 명령은 AD 휴지통에서 삭제된 모든 객체를 제거합니다. **중요** 이 명령은 실행 취소할 수 없는 명령이며, 삭제된 객체를 복구할 수 있는 유일한 방법은 디렉터리 복원을 수행하는 것이므로 이 명령은 특히 주의해서 사용해야 합니다. ``` $DomainInfo = Get-ADDomain $BaseDn = $DomainInfo.DistinguishedName $NetBios = $DomainInfo.NetBIOSName $ObjectsToRemove = Get-ADObject -Filter { isDeleted -eq $true } -IncludeDeletedObjects -SearchBase "CN=Deleted Objects,$BaseDn" -Properties 'LastKnownParent','DistinguishedName','msDS-LastKnownRDN' | Where-Object { ($_.LastKnownParent -Like "*OU=$NetBios,$BaseDn") -or ($_.LastKnownParent -Like '*\0ADEL:*') } ForEach ($ObjectToRemove in $ObjectsToRemove) { Remove-ADObject -Identity $ObjectToRemove.DistinguishedName -IncludeDeletedObjects } ``` 1. AWS Support에서 사례를 열어가 여유 공간을 Directory Service 회수하도록 요청합니다. 1. 디렉터리 유형이 Standard Edition인 경우 AWS 지원에서 사례를 열어 디렉터리를 Enterprise Edition으로 업그레이드하도록 요청합니다. 이렇게 하면 디렉터리 비용도 증가합니다. 요금 정보는 [Directory Service 요금](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table)을 참조하세요. AWS 관리형 Microsoft AD에서 **AWS 위임된 삭제된 객체 수명 관리자** 그룹의 구성원은 삭제된 객체가 재활용-객체가 되기 전에 AD 재활용통에 보관되는 일수를 설정하는 `msDS-DeletedObjectLifetime` 속성을 수정할 수 있습니다. **참고** 이는 고급 주제입니다. 부적절하게 구성하면 데이터가 손실될 수 있습니다. 이러한 프로세스를 더 잘 이해하려면 먼저 [AD 휴지통: 이해, 구현, 모범 사례 및 문제 해결](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/the-ad-recycle-bin-understanding-implementing-best-practices-and/ba-p/396944)을 검토하는 것이 좋습니다. `msDS-DeletedObjectLifetime` 속성 값을 더 낮은 숫자로 변경하는 기능은 객체 수가 지원되는 수준을 초과하지 않도록 하는 데 도움이 될 수 있습니다. 이 속성을 설정할 수 있는 가장 낮은 유효 값은 2일입니다. 이 값을 초과하면 AD 휴지통을 사용하여 삭제된 객체를 더 이상 복구할 수 없습니다. 객체를 복구하려면 스냅샷에서 디렉터리를 복구해야 합니다. 자세한 내용은 [스냅샷을 사용하여 AWS 관리형 Microsoft AD 복원](ms_ad_snapshots.md) 단원을 참조하십시오. **스냅샷 복원은 특정 시점이므로 데이터 손실이 발생할 수 있습니다.** 디렉터리의 삭제된 객체 수명을 변경하려면 다음 명령을 실행하세요. **참고** 명령을 그대로 실행하면 삭제된 객체 수명 속성 값이 30일로 설정됩니다. 이를 더 길거나 짧게 만들고 싶다면 ‘30’을 원하는 숫자로 바꾸세요. 그러나 기본 수인 180보다 높지 않게 설정하는 것이 좋습니다. ``` $DeletedObjectLifetime = 30 $DomainInfo = Get-ADDomain $BaseDn = $DomainInfo.DistinguishedName Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,$BaseDn" -Partition "CN=Configuration,$BaseDn" -Replace:@{"msDS-DeletedObjectLifetime" = $DeletedObjectLifetime} ``` # 스키마 확장 오류 다음은 AWS 관리형 Microsoft AD 디렉터리의 스키마를 확장할 때 발생할 수 있는 몇 가지 오류 메시지를 해결하는 데 도움이 될 수 있습니다. ## 추천 **오류** *라인 1에서 시작되는 엔트리에 오류 추가: 추천 서버 측 오류: 0x202b 추천이 서버에서 반환되었습니다. 확장 서버 오류: 0000202B: RefErr: DSID-0310082F, 데이터 0, 1 액세스 포인트 \$1tref 1: ‘example.com' 수정된 객체 수: 0* **문제 해결** 모든 고유 이름 필드가 올바른 도메인 이름을 가지고 있는지 확인합니다. 위의 예제에서 `DC=example,dc=com`를 cmdlet `Get-ADDomain`에 표시된 `DistinguishedName`으로 교체해야 합니다. ## 가져오기 파일을 읽을 수 없음 **오류** *가져오기 파일을 읽을 수 없습니다. 수정된 객체 수: 0* **문제 해결** 가져온 LDIF 파일이 비어 있습니다(0바이트). 올바른 파일이 업로드되었는지 확인합니다. ## 구문 오류 **오류** *라인 21에서 실패한 입력 파일에 구문 오류가 있습니다. 마지막 토큰은 'q'로 시작합니다. 수정된 객체 수: 0* **문제 해결** 라인 21의 텍스트가 올바르게 포맷되지 않았습니다. 유효하지 않은 텍스트의 첫 번째 문자는 `A`입니다. 라인 21을 유효한 LDIF 구문으로 업데이트합니다. LDIF 파일을 포맷하는 방법에 대한 자세한 내용은 [1단계: LDIF 파일 생성](create.md)을 참조하세요. ## 속성 또는 값 있음 **오류** *라인 1에서 시작되는 엔트리에 오류 추가: 속성 또는 값 있음 서버 측 오류: 0x2083 지정된 값이 이미 존재합니다. 확장 서버 오류: 00002083: AtrErr: DSID-03151830, \$11: \$1t0: 00002083: DSID-03151830, 문제 1006 (ATT\$1OR\$1VALUE\$1EXISTS), 데이터 0, Att 20019 (mayContain):len 4 수정된 객체 수: 0* **문제 해결** 스키마 변경이 이미 적용되었습니다. ## 이러한 속성 없음 **오류** *라인 1에서 시작되는 엔트리에 오류 추가: 이러한 속성 없음 서버 측 오류: 0x2085 속성 값은 객체에 존재하지 않으므로 삭제할 수 없습니다. 확장 서버 오류: 00002085: AtrErr: DSID-03152367, \$11: \$1t0: 00002085: DSID-03152367, 문제 1001 (NO\$1ATTRIBUTE\$1OR\$1VAL), 데이터 0, Att 20019 (mayContain):len 4 수정된 객체 수: 0* **문제 해결** LDIF 파일은 클래스에서 속성을 제거하려고 시도하지만, 현재 해당 속성이 클래스에 연결되어 있지 않습니다. 아마도 스키마 변경이 이미 적용되었습니다. **오류** *라인 41에서 시작되는 엔트리에 오류 추가: 이러한 속성 없음 0x57 파라미터가 올바르지 않습니다. 확장 서버 오류: 0x208d 디렉터리 객체를 찾을 수 없음. 확장 서버 오류: "00000057: LdapErr: DSID-0C090D8A, 설명: 속성 변환 작업 시 오류, 데이터 0, v2580" 수정된 객체 수: 0* **문제 해결** 라인 41에 나온 속성이 올바르지 않습니다. 스펠링을 다시 확인합니다. ## 이러한 객체 없음 **오류** *라인 1에서 시작되는 엔트리에 오류 추가: 이러한 객체 없음 서버 측 오류: 0x208d 디렉터리 객체를 찾을 수 없음. 확장 서버 오류: 0000208D: NameErr: DSID-03100238, problem 2001 (NO\$1OBJECT), 데이터 0, best match of: ’CN=Schema,CN=Configuration,DC=example,DC=com’ 수정된 객체 수: 0* **문제 해결** 고유 이름(DN)이 참조한 객체가 존재하지 않습니다. # 신뢰 생성 상태 이유 AWS 관리형 Microsoft AD에 대한 신뢰 생성이 실패하면 상태 메시지에 추가 정보가 포함됩니다. 다음은 이러한 메시지가 의미하는 바를 이해하는 데 도움이 될 수 있습니다. ## 액세스 거부됨 신뢰 생성을 시도할 때 액세스가 거부되었습니다. 신뢰 암호가 잘못되었거나 원격 도메인의 보안 설정이 신뢰 구성을 허용하지 않습니다. 신뢰에 대한 자세한 내용은 [사이트 이름 및 DCLocator를 사용하여 신뢰 효율성 향상](#enhancing-trust-site-names)을 참조하세요. 이러한 문제를 해결하려면 다음 작업을 시도해 보세요. + 원격 도메인에서 해당 신뢰 관계를 생성할 때 사용한 것과 동일한 신뢰 암호를 사용하고 있는지 확인합니다. + 도메인 보안 설정이 신뢰 관계 생성을 허용하는지 확인합니다. + 로컬 보안 정책이 올바르게 설정되었는지 확인합니다. `Local Security Policy > Local Policies > Security Options > Network access: Named Pipes that can be accessed anonymously`를 자세히 점검하여 다음과 같이 명명된 파이프가 3개 이상 포함되어 있는지 확인합니다. + netlogon + samr + lsarpc + 위의 명명된 파이프가 레지스트리 경로 **HKLM\$1 SYSTEM\$1 CurrentControlSet\$1 Services\$1 LANManServer\$1Parameters**에 있는 **NullSessionPipes** 레지스트리 키의 값으로 존재하는지 확인하세요. 이러한 값은 구분된 행에 삽입해야 합니다. **참고** 기본적으로 `Network access: Named Pipes that can be accessed anonymously`는 설정이 되어 있지 않으며 `Not Defined`라는 메시지가 표시됩니다. `Network access: Named Pipes that can be accessed anonymously`에 대한 도메인 컨트롤러의 유효 기본 설정이 `netlogon`, `samr`, `lsarpc`이기 때문에 이는 정상적인 상태입니다. + *기본 도메인 컨트롤러 정책* 에서 다음 서버 메시지 블록(SMB) 서명 설정을 확인합니다. 이러한 설정은 **컴퓨터 구성** > **Windows 설정** > **보안 설정** > **로컬 정책/보안 옵션 **에서 찾을 수 있습니다. 다음 설정과 일치해야 합니다. + Microsoft 네트워크 클라이언트: 디지털 서명 통신(항상): 기본값: 활성화됨 + Microsoft 네트워크 서버: 디지털 서명 통신(항상): 활성화됨 ### 사이트 이름 및 DCLocator를 사용하여 신뢰 효율성 향상 Default-First-Site-Name과 같은 첫 번째 사이트 이름은 도메인 간에 신뢰 관계를 설정하기 위한 요구 사항이 아닙니다. 그러나 도메인 간 사이트 이름을 정렬하면 도메인 컨트롤러 로케이터(DCLocator) 프로세스의 효율성을 크게 향상할 수 있습니다. 이 정렬을 통해 포리스트 신뢰에서 도메인 컨트롤러 선택을 더욱 잘 예측하고 제어할 수 있습니다. DCLocator 프로세스는 다양한 도메인과 포리스트에서 도메인 컨트롤러를 찾는 데 매우 중요합니다. DCLocator 프로세스에 대한 자세한 내용은 [Microsoft 설명서](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/troubleshoot-domain-controller-location-issues)를 참조하세요. 사이트를 효율적으로 구성하면 도메인 컨트롤러 위치를 더 빠르고 정확하게 찾을 수 있으며, 이는 교차 포리스트 작업의 성능과 안정성을 향상하는 데 도움이 됩니다. 사이트 이름과 DCLocator 프로세스가 상호 작용하는 방법에 대한 자세한 내용은 다음 Microsoft 문서를 참조하세요. + [트러스트 간에 도메인 컨트롤러 위치를 찾는 방법](https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-domain-controllers-are-located-across-trusts/ba-p/256180) + [포리스트 간 도메인 로케이터](https://techcommunity.microsoft.com/blog/askds/domain-locator-across-a-forest-trust/395689) ## 지정된 도메인 이름이 없거나 해당 주소를 찾을 수 없습니다. 이 문제를 해결하려면 도메인의 보안 그룹 설정과 VPC의 액세스 제어 목록(ACL)이 올바르고 조건부 전달자에 대한 정보를 정확하게 입력했는지 확인합니다.는 Active Directory 통신에 필요한 포트만 열도록 보안 그룹을 AWS 구성합니다. 기본 구성에서 보안 그룹은 모든 IP 주소에서 이러한 포트에 도달하는 트래픽을 수용합니다. 아웃바운드 트래픽은 보안 그룹으로 제한됩니다. 온프레미스 네트워크로의 트래픽을 허용하려면 보안 그룹의 아웃바운드 규칙을 업데이트해야 합니다. 보안 요건에 대한 자세한 내용은 [2단계: AWS 관리형 Microsoft AD 준비](ms_ad_tutorial_setup_trust_prepare_mad.md)을(를) 참조하세요. ![\[보안 그룹 편집\]](http://docs.aws.amazon.com/ko_kr/directoryservice/latest/admin-guide/images/edit_security_group.png) 다른 디렉터리의 네트워크에 대한 DNS 서버가 공용(RFC 1918이 아닌) IP 주소를 사용하는 경우 디렉터리에 Directory Services 콘솔에서 DNS 서버에 대한 IP 경로를 추가해야 합니다. 자세한 내용은 [신뢰 관계의 설정, 확인, 삭제](ms_ad_setup_trust.md#trust_steps) 및 [사전 조건](ms_ad_setup_trust.md#trust_prereq) 섹션을 참조하세요. IANA(인터넷 할당 번호 기관)가 다음 세 블록의 IP 주소 공간을 사설 인터넷을 위해 예약했습니다. + 10.0.0.0 - 10.255.255.255 (10/8 접두사) + 172.16.0.0 - 172.31.255.255 (172.16/12 접두사) + 192.168.0.0 - 192.168.255.255 (192.168/16 접두사) 자세한 내용은 [https://tools.ietf.org/html/rfc1918](https://tools.ietf.org/html/rfc1918)을 참조하세요. AWS 관리형 Microsoft **AD의 기본 AD 사이트 이름이** 온프레미스 인프라의 **기본 AD 사이트 이름과** 일치하는지 확인합니다. 컴퓨터는 사용자 도메인이 아닌 컴퓨터가 구성원으로 속해 있는 도메인을 사용하여 사이트 이름을 결정합니다. 가장 가까운 온프레미스와 일치하도록 사이트 이름을 바꾸면 DC 로케이터가 가장 가까운 사이트의 도메인 컨트롤러를 사용합니다. 이것으로도 문제가 해결되지 않는 경우에는 이전에 생성된 조건부 전달자로부터의 정보가 캐시에 저장되어 새로운 신뢰 생성이 금지되었을 가능성이 있습니다. 몇 분 정도 기다린 다음 신뢰 및 조건부 전달자를 다시 생성하세요. 작동 방식에 대한 자세한 내용은 Microsoft 웹 사이트의 [Forest Trust 전반의 도메인 로케이터](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689)를 참조하세요. ![\[첫 번째 기본 사이트 이름\]](http://docs.aws.amazon.com/ko_kr/directoryservice/latest/admin-guide/images/default_first_site_name.png) ## 이 도메인에서 해당 작업을 수행할 수 없습니다 두 도메인/디렉터리 모두에 중복되는 NETBIOS 이름이 없어야 이 문제를 해결할 수 있습니다. 도메인/디렉터리에 NETBIOS 이름이 겹치는 경우 둘 중 하나를 다른 NETBIOS 이름으로 다시 만든 다음 다시 시도하세요. ## “필요하고 유효한 도메인 이름”이라는 오류 때문에 트러스트 생성이 실패하고 있습니다. DNS 이름에는 영문자(A\$1Z), 숫자(0\$19), 빼기 기호(-) 및 마침표(.)만 포함할될 수 있습니다. 마침표 문자는 도메인 스타일 이름의 구성 요소를 구분하는 데 사용하는 경우에만 허용됩니다. 또한, 다음을 고려하세요. + AWS 관리형 Microsoft AD는 단일 레이블 도메인과의 신뢰를 지원하지 않습니다. 자세한 내용은 [Microsoft단일 레이블 도메인에 대한 지원](https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/single-label-domains-support-policy)을 참조하세요. + RFC 1123([https://tools.ietf.org/html/rfc1123](https://tools.ietf.org/html/rfc1123))에 따르면 DNS 레이블에 사용할 수 있는 유일한 문자는 “A”\$1“Z”, “a”\$1“z”, “0"\$1“9", 하이픈(“-”)입니다. 마침표[.]는 DNS 이름에도 사용되지만, DNS 레이블 사이와 FQDN 끝에만 사용됩니다. + RFC 952([https://tools.ietf.org/html/rfc952](https://tools.ietf.org/html/rfc952))에 따르면 “이름"(넷, 호스트, 게이트웨이, 도메인 이름)은 알파벳(A\$1Z), 숫자(0\$19), 빼기 기호(-), 마침표(.)에서 가져온 최대 24자의 텍스트 문자열입니다. 마침표는 “도메인 스타일 이름”의 구성 요소를 구분하는 용도로만 사용할 수 있다는 점을 유의하세요. 자세한 내용은 Microsoft 웹 사이트의 [호스트 및 도메인에 대한 이름 제한 준수](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc959336(v=technet.10))를 참조하세요. ## 신뢰 관계 테스트용 일반 도구 다음은 다양한 신뢰 관련 문제를 해결하는 데 사용할 수 있는 도구입니다. **AWS Systems Manager Automation 문제 해결 도구** [Support Automation Workflows(SAW)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-support.html)는 AWS Systems Manager Automation을 활용하여 사전 정의된 실행서를 제공합니다 Directory Service. [AWSSupport-TroubleshootDirectoryTrust](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-awssupport-troubleshootdirectorytrust.html) 실행서 도구는 AWS 관리형 Microsoft AD와 온프레미스 Microsoft Active Directory 간의 일반적인 신뢰 생성 문제를 진단하는 데 도움이 됩니다. **DirectoryServicePortTest 도구** [DirectoryServicePortTest](samples/DirectoryServicePortTest.zip) 테스트 도구는 AWS 관리형 Microsoft AD와 온프레미스 Active Directory 간의 신뢰 생성 문제를 해결할 때 유용할 수 있습니다. 도구를 사용하는 방법에 대한 예제는 [AD 커넥터 테스트](ad_connector_getting_started.md#connect_verification) 단원을 참조하세요. **NETDOM 및 NLTEST 도구** 관리자는 **Netdom** 및 **Nltest** 명령줄 도구를 모두 사용하여 신뢰를 찾고, 표시하며, 생성하고, 제거하며, 관리할 수 있습니다. 이러한 도구는 도메인 컨트롤러의 LSA 기관과 직접 통신합니다. 이러한 도구를 사용하는 방법에 대한 예는 Microsoft 웹 사이트의 [Netdom](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc772217(v=ws.11)) 및 [NLTEST](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731935(v=ws.11))를 참조하세요. **패킷 캡처 도구** 내장된 Windows 패키지 캡처 유틸리티를 사용하여 잠재적인 네트워크 문제를 조사하고 해결할 수 있습니다. 자세한 내용은 [아무것도 설치하지 않은 채로 네트워크 추적 캡처](https://techcommunity.microsoft.com/t5/iis-support-blog/capture-a-network-trace-without-installing-anything-amp-capture/ba-p/376503)를 참조하세요. # AWS 관리형 Microsoft AD 높은 CPU 사용률 문제 해결 다음은 AWS 관리형 Microsoft AD 도메인 컨트롤러에서 높은 CPU 문제를 해결하는 데 도움이 될 수 있습니다. ## 근본 원인 찾기 높은 CPU 사용률 문제를 해결하는 첫 번째 단계는 CloudWatch 지표를 분석하여 리소스 소비 증가를 설명할 수 있는 패턴을 식별하는 것입니다. ### 1단계: Directory Service CloudWatch 지표 검토 CloudWatch 지표를 사용하여 AWS 관리형 Microsoft AD 성능을 모니터링하여 높은 CPU 사용량과 상관관계가 있는 트래픽 패턴을 식별합니다. Directory Service 지표 보기 및 해석에 대한 자세한 내용은 섹션을 참조하세요[CloudWatch를 사용하여 AWS 관리형 Microsoft AD 도메인 컨트롤러의 성능 모니터링](ms_ad_monitor_dc_performance.md). CPU 증가를 설명할 수 있는 다음 주요 지표에서 시프팅 패턴을 찾습니다. + **초당 DNS 쿼리** - 갑작스러운 스파이크는 DNS 해결 문제 또는 잘못 구성된 애플리케이션을 나타낼 수 있습니다. + **Kerberos/NTLM 인증 **- 사용자 로그온 또는 서비스 계정의 인증 비율이 높습니다. + **초당 LDAP 쿼리** - 애플리케이션 또는 서비스의 LDAP 트래픽 증가. 현재 지표를 과거 기준과 비교하여 높은 CPU 사용률이 시작된 시기를 식별하고 이를 특정 트래픽 증가와 연관시킵니다. 지표에서 상관관계가 없는 경우 근본 원인은 트래픽의 압도적인 증가가 아닙니다. 대신 근본 원인은 비효율적인 LDAP 쿼리일 수 있으므로 로 건너뜁니다[3단계: 트래픽 미러링을 사용하여 세부 트래픽 분석 캡처](#ms_ad_high_cpu_step3). ### 2단계: VPC 흐름 로그를 사용하여 소스 시스템 식별 VPC 흐름 로그는 도메인 컨트롤러로 트래픽을 생성하는 시스템의 소스 IP 주소를 식별하는 효과적인 방법을 제공합니다. 자세한 내용은 [VPC 흐름 로그를 사용하여 IP 트래픽 로깅](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)을 참조하세요. 대상 포트 번호를 사용하여 서비스를 구분합니다. + **포트 53** - DNS 쿼리 + **포트 88** - Kerberos 인증 + **포트 123** - NTP 클럭 동기화 + **포트 135, 49152-65535** – RPC + **포트 389, 636, 3268, 3269** – LDAP 쿼리(표준 LDAP의 경우 389 또는 3268, LDAPS의 경우 636 또는 3269) + **포트 445** - SMB 파일 공유(그룹 정책) + **포트 464** - Kerberos 암호 변경 + **포트 9389** – Active Directory 웹 서비스 VPC 흐름 로그를 활성화하고 분석하려면: + 도메인 컨트롤러 ENIs가 포함된 서브넷에 대해 VPC 흐름 로그를 활성화합니다. + 대상 포트별로 로그를 필터링하여 트래픽 패턴을 식별합니다. + 일정 기간 동안 대부분의 패킷 및/또는 대부분의 바이트를 기준으로 구성합니다. + 소스 IP 주소를 분석하여 트래픽을 가장 많이 생성하는 시스템을 결정합니다. ### 3단계: 트래픽 미러링을 사용하여 세부 트래픽 분석 캡처 VPC 흐름 로그는 요청의 실제 콘텐츠에 대한 제한된 정보를 제공합니다. 자세한 분석을 위해 트래픽 미러링을 고려하여 전체 패킷 데이터를 캡처합니다. 자세한 내용은 [트래픽 미러링을 사용하여 네트워크 트래픽 모니터링 시작하기를](https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-getting-started.html) 참조하세요. 이는 다음을 분석해야 할 때 특히 유용합니다. + LDAP 필터 복잡성 및 효율성 + 특정 DNS 쿼리 패턴 + 인증 요청 세부 정보 트래픽 미러링을 사용하면 도메인 컨트롤러 인스턴스로 전송된 전체 네트워크 패킷을 캡처하여 CPU 사용률이 높은 트래픽에 대한 심층 분석을 수행할 수 있습니다. ### 4단계: 소스 애플리케이션 조사 및 트래픽 최적화 소스 시스템과 트래픽 패턴을 식별한 후에는 트래픽을 생성하는 애플리케이션을 조사합니다. + **애플리케이션 구성 검토** - 애플리케이션이 비효율적인 쿼리 또는 과도한 요청을 수행하고 있는지 확인합니다. 애플리케이션을 단일 도메인 컨트롤러로 하드 코딩하지 마십시오. + **LDAP 쿼리 분석** - 비효율적인 LDAP 쿼리는 도메인 컨트롤러 CPU가 높은 가장 일반적인 원인입니다. 속성 인덱싱의 이점을 누릴 수 있는 복잡한 필터를 찾습니다. + **DNS 캐싱 검사** - 반복적인 쿼리를 줄이기 위해 DNS 클라이언트 캐싱이 활성화되어 있는지 확인합니다. + **인증 패턴 확인** - 서비스 계정이 너무 자주 인증하는지 확인합니다. ## 해결 전략 조사를 기반으로 적절한 최적화 전략을 구현합니다. ### 애플리케이션 최적화 + **LDAP 쿼리 최적화** - 복잡한 LDAP 쿼리를 다시 작성합니다. 검색 기반을 도메인의 루트로 설정하지 말고 대신 검색하려는 객체가 있는 OU로 구성합니다. 하위 트리 검색을 수행하는 검색 범위를 사용하지 마세요. 대신 기본 또는 단일 수준 범위를 사용합니다. 필터에 객체 클래스를 포함합니다. 예: `(objectClass=user)` 또는 `(objectClass=computer)`. 속성이 인덱싱되지 않는 한 필터에서 와일드카드를 사용하지 마세요. 와일드카드 스캔이 필요한 경우 인덱스를 추가합니다. 자세한 내용은 [AWS 관리형 Microsoft AD 스키마 확장](ms_ad_schema_extensions.md) 단원을 참조하십시오. 인덱싱 프로세스도 CPU 사용률을 높이기 때문에 모든 것을 인덱싱하지 마세요. ``` # Sample LDIF code to index the email attribute dn: CN=mail,CN=Schema,CN=Configuration,DC=yourdomain,DC=com changetype: modify replace: searchFlags searchFlags: 1 ``` + **DNS 클라이언트 캐싱 활성화** - DNS 응답을 로컬로 캐싱하도록 클라이언트를 구성하여 서버 로드를 줄입니다. + **연결 풀링 구현** - 각 쿼리에 대해 새 연결을 생성하는 대신 LDAP 연결을 재사용하도록 애플리케이션을 구성합니다. ### 디렉터리 인프라 확장 트래픽 최적화로 CPU 사용률이 높아지지 않는 경우: + **도메인 컨트롤러 추가** - 추가 도메인 컨트롤러를 배포하여 로드를 분산하여 확장합니다. 자세한 내용은 [AWS 관리형 Microsoft AD에 대한 추가 도메인 컨트롤러 배포](ms_ad_deploy_additional_dcs.md) 단원을 참조하십시오. + **Enterprise Edition으로 업그레이드** - Standard Edition을 사용하는 경우 Enterprise Edition으로 업그레이드하여 CPU 용량과 성능을 높입니다. 자세한 내용은 [AWS 관리형 Microsoft AD 업그레이드](ms_ad_upgrade_edition.md) 단원을 참조하십시오. Enterprise Edition을 이미 사용하고 있는 경우 [AWS Support](https://docs.aws.amazon.com//awssupport/latest/user/case-management.html)에 문의하여 용량을 늘리세요. AWS 관리형 Microsoft AD 에디션에 대한 요금 정보는 [Directory Service 요금을](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table) 참조하세요.