# RDS Custom for SQL Server를 사용하여 Microsoft Active Directory 작업
RDS Custom for SQL Server를 사용하면 인스턴스를 자체 관리형 Active Directory(AD) 또는 AWS Managed Microsoft AD에 조인할 수 있습니다. 이는 온프레미스 데이터 센터, Amazon EC2 또는 다른 클라우드 서비스 공급자와 같이 AD가 호스팅되는 위치에 관계없이 적용됩니다.
사용자 및 서비스 인증의 경우, 중간 도메인 및 포리스트 신뢰를 사용하지 않고도 RDS Custom for SQL Server DB 인스턴스에서 NTLM 또는 Kerberos 인증을 사용할 수 있습니다. 사용자가 자체 조인된 Active Directory로 RDS Custom for SQL Server DB 인스턴스에서 인증을 시도하면 인증 요청이 자체 관리형 AD 또는 사용자가 지정한 AWS Managed Microsoft AD로 전달됩니다.
다음 섹션에서는 RDS Custom for SQL Server에 자체 관리형 Active Directory 및 AWS 관리형 Active Directory를 사용하여 작업하는 정보를 찾을 수 있습니다.
**Topics**
+ [리전 및 버전 사용 가능 여부](#custom-sqlserver-WinAuth.Regions)
+ [자체 관리형 또는 온프레미스 AD 구성](custom-sqlserver-WinAuth.config-Self-Managed.md)
+ [Directory Service를 사용하여 Microsoft Active Directory 구성](custom-sqlserver-WinAuth.config-ADS.md)
+ [네트워크 구성 포트 규칙](custom-sqlserver-WinAuth.NWConfigPorts.md)
+ [네트워크 검증](custom-sqlserver-WinAuth.NWValidation.md)
+ [RDS Custom for SQL Server 인스턴스에 대한 Windows 인증 설정](custom-sqlserver-WinAuth.settingUp.md)
+ [도메인에서 DB 인스턴스 관리](custom-sqlserver-WinAuth.ManagingDBI.md)
+ [도메인 멤버십 이해](custom-sqlserver-WinAuth.Understanding.md)
+ [Active Directory 문제 해결](custom-sqlserver-WinAuth.Troubleshoot.md)
## 리전 및 버전 사용 가능 여부
RDS Custom for SQL Server는 RDS Custom for SQL Server가 지원되는 모든 리전에서 NTLM 또는 Kerberos를 사용하여 자체 관리형 AD 및 AWS Managed Microsoft AD를 모두 지원합니다. 자세한 내용은 [RDS Custom을 지원하는 리전 및 DB 엔진](Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.md) 단원을 참조하십시오.
# 자체 관리형 또는 온프레미스 AD 구성
온프레미스 또는 자체 관리형 Microsoft AD를 RDS Custom for SQL Server DB 인스턴스에 조인하려면 Active Domain을 다음과 같이 구성해야 합니다.
+ 자체 관리형 또는 온프레미스 AD에서 RDS Custom for SQL Server DB 인스턴스와 연결된 VPC의 서브넷을 정의합니다. VPC의 서브넷과 AD 사이트의 서브넷 간에 충돌이 없는지 확인합니다.
+ AD 도메인 컨트롤러의 도메인 기능 수준은 Windows Server 2008 R2 이상입니다.
+ AD 도메인 이름은 단일 레이블 도메인(SLD) 형식일 수 없습니다. RDS Custom for SQL Server는 SLD 도메인을 지원하지 않습니다.
+ AD의 정규화된 도메인 이름(FQDN)이 47자를 초과하면 안 됩니다.
## 네트워크 연결 구성
다음과 같은 방식으로 자체 관리형 또는 온프레미스 AD 네트워크 연결을 구성합니다.
+ RDS Custom for SQL Server 인스턴스가 실행 중인 Amazon VPC와 AD 간의 연결을 설정합니다. Direct Connect, Site-to-Site VPN, AWS Transit Gateway 및 VPC 피어링을 사용합니다.
+ 자체 관리형 또는 온프레미스 AD에 대해 RDS Custom for SQL Server 보안 그룹 및 네트워크 ACL 포트의 트래픽을 허용합니다. 자세한 내용은 [네트워크 구성 포트 규칙](custom-sqlserver-WinAuth.NWConfigPorts.md) 섹션을 참조하세요.
![\[Microsoft SQL Server Windows 인증 디렉터리\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/custom-sqs-SM-NC.png)
## DNS 확인 구성
자체 관리형 또는 온프레미스 AD를 사용하여 DNS 확인을 구성하려면 다음 요구 사항을 설정합니다.
+ 자체 호스팅된 Active Directory의 정규화된 도메인 이름(FQDN)을 확인하도록 VPC 내에서 DNS 확인을 구성합니다. FQDN의 예는 `corp.example.local`입니다. DNS 확인을 구성하려면 Amazon Route 53 아웃바운드 엔드포인트 및 해석기 규칙이 있는 특정 도메인에 대한 쿼리를 전달하도록 VPC DNS 해석기를 구성합니다. 자세한 내용은 [DNS 레코드를 확인하도록 Route 53 Resolver 아웃바운드 엔드포인트 구성](https://repost.aws/knowledge-center/route53-resolve-with-outbound-endpoint)을 참조하세요.
+ VPC와 온프레미스 리소스를 모두 활용하는 워크로드의 경우 온프레미스에서 호스팅되는 DNS 레코드를 확인해야 합니다. 온프레미스 리소스는 AWS에서 호스팅되는 이름을 확인해야 할 수 있습니다.
하이브리드 클라우드 설정을 생성하려면 해석기 엔드포인트와 조건부 전달을 사용하여 온프레미스 리소스와 사용자 지정 VPC 간의 DNS 쿼리를 확인합니다. 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [VPC와 네트워크 간 DNS 쿼리 해석](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html)을 참조하세요.
**중요**
RDS Custom for SQL Server에서 네트워크 인터페이스의 DNS 해석기 설정을 수정하면 DNS 지원 VPC 엔드포인트가 더 이상 제대로 작동하지 않습니다. 인터넷 액세스가 없는 프라이빗 서브넷 내의 인스턴스에는 DNS 지원 VPC 엔드포인트가 필요합니다.
# Directory Service를 사용하여 Microsoft Active Directory 구성
AWS Managed Microsoft AD는 AWS에서 완전 관리형 Microsoft Active Directory를 생성하며, Windows Server 2019에 의해 구동되고 2012 R2 포리스트 및 도메인 기능 수준에서 작동합니다. Directory Service는 Amazon VPC의 서로 다른 서브넷에 도메인 컨트롤러를 생성하여 장애가 발생하더라도 디렉터리를 쉽게 사용할 수 있도록 합니다.
AWS Managed Microsoft AD를 사용하여 디렉터리를 생성하려면 *AWS Directory Service 관리 안내서*의 [AWS Managed Microsoft AD 시작하기](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html)를 참조하세요.
## 네트워크 연결 구성
### 디렉터리와 DB 인스턴스 사이에 VPC 간 트래픽 활성화
디렉터리와 DB 인스턴스를 동일한 VPC에 배치하려면 이 단계를 건너뛰고 [네트워크 구성 포트 규칙](custom-sqlserver-WinAuth.NWConfigPorts.md)의 다음 단계로 이동하세요.
디렉터리와 DB 인스턴스를 서로 다른 VPC에 배치하려면 VPC 피어링 또는 AWS Transit Gateway를 사용하여 VPC 간 트래픽을 구성하세요. VPC 피어링 사용에 대한 자세한 내용은 *Amazon VPC 피어링 가이드*의 [VPC 피어링이란 무엇인가요?](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) 및 *Amazon VPC Transit Gateways*의 [AWS Transit Gateway란 무엇인가요?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)를 참조하세요.
**VPC 피어링을 사용하여 VPC 간 트래픽 활성화**
1. 네트워크 트래픽이 양방향으로 흐를 수 있도록 적절한 VPC 라우팅 규칙을 설정합니다.
1. DB 인스턴스의 보안 그룹이 디렉터리의 보안 그룹에서 인바운드 트래픽을 수신할 수 있도록 허용합니다. 자세한 내용은 [네트워크 구성 포트 규칙](custom-sqlserver-WinAuth.NWConfigPorts.md) 섹션을 참조하세요.
1. 네트워크 액세스 제어 목록(ACL)은 트래픽을 차단해서는 안 됩니다.
다른 AWS 계정가 디렉터리를 소유하는 경우 디렉터리를 공유해야 합니다. *AWS Directory Service 관리 안내서*의 [자습서: 원활한 EC2 도메인 조인을 위해 AWS Managed Microsoft AD 공유](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html)에 따라 RDS Custom for SQL Server 인스턴스가 있는 AWS 계정와 디렉터리를 공유합니다.
**AWS 계정 간에 디렉터리 공유**
1. DB 인스턴스용 계정을 사용하여 Directory Service 콘솔에 로그인하고 계속하기 전에 도메인이 `SHARED` 상태가 되었는지 확인합니다.
1. DB 인스턴스용 계정을 사용하여 Directory Service 콘솔에 로그인한 후 **디렉터리 ID** 값을 기록해 둡니다. 이 ID를 사용하여 DB 인스턴스를 도메인에 조인합니다.
## DNS 확인 구성
AWS Managed Microsoft AD를 사용하여 디렉터리를 생성하면 Directory Service가 자동으로 두 개의 도메인 컨트롤러를 생성하고 사용자를 대신하여 DNS 서비스를 추가합니다.
기존 AWS Managed Microsoft AD가 있거나 RDS Custom for SQL Server DB 인스턴스가 아닌 다른 VPC에서 시작할 계획이 있는 경우 Route 53 아웃바운드 및 해석기 규칙이 있는 특정 도메인에 대한 쿼리를 전달하도록 VPC DNS 해석기를 구성합니다. [DNS 레코드를 확인하도록 Route 53 Resolver 아웃바운드 엔드포인트 구성](https://repost.aws/knowledge-center/route53-resolve-with-outbound-endpoint)을 참조하세요.
# 네트워크 구성 포트 규칙
다음 네트워크 구성을 충족하는지 확인합니다.
+ RDS Custom for SQL Server DB 인스턴스를 생성하려는 Amazon VPC와 자체 관리형 Active Directory 또는 AWS Managed Microsoft AD 간에 연결이 구성되었습니다. 자체 관리형 Active Directory의 경우, AWS Direct Connect, AWS VPN, VPC 피어링 또는 AWS Transit Gateway를 사용하여 연결을 설정합니다. AWS Managed Microsoft AD의 경우, VPC 피어링을 사용하여 연결을 설정합니다.
+ RDS Custom for SQL Server DB 인스턴스를 만드는 서브넷의 보안 그룹과 VPC 네트워크 ACL이 다음 다이어그램에 표시된 방향으로 포트를 통한 트래픽을 허용하는지 확인합니다.
![\[Microsoft Active Directory 네트워크 구성 포트 규칙입니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/custom_sqlserver_ActiveDirectory_Requirements_NetworkConfig.png)
다음 테이블에는 각 포트의 역할이 나와 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/custom-sqlserver-WinAuth.NWConfigPorts.html)
+ 일반적으로 도메인 DNS 서버는 AD 도메인 컨트롤러에 있습니다. 이 기능을 사용하기 위해 VPC DHCP 옵션 세트를 구성할 필요는 없습니다. 자세한 정보는 *Amazon VPC 사용 설명서*의 [DHCP 옵션 세트](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)를 참조하세요.
**중요**
VPC 네트워크 ACL을 사용하는 경우 RDS Custom for SQL Server DB 인스턴스의 동적 포트(49152\$165535)를 통한 아웃바운드 트래픽도 허용해야 합니다. 이러한 트래픽 규칙이 각 AD 도메인 컨트롤러, DNS 서버 및 RDS Custom for SQL Server DB 인스턴스에 적용되는 방화벽에도 반영되는지 확인하세요.
VPC 보안 그룹에서는 네트워크 트래픽이 시작되는 방향으로만 포트를 열어야 하지만, 대부분의 Windows 방화벽과 VPC 네트워크 ACL에서는 포트가 양방향으로 열려 있어야 합니다.
# 네트워크 검증
RDS Custom 인스턴스를 자체 관리형 또는 AWS Managed Microsoft AD에 조인하기 전에 RDS Custom for SQL Server 인스턴스를 시작하려는 위치와 동일한 VPC의 EC2 인스턴스에서 다음을 확인합니다.
+ 정규화된 도메인 이름(FQDN)을 도메인 컨트롤러 IP로 확인할 수 있는지 확인합니다.
```
nslookup corp.example.com
```
명령은 유사한 출력을 반환해야 합니다.
```
Server: ip-10-0-0-2.us-west-2.compute.internal
Address: 25.0.0.2
Non-authoritative answer:
Name: corp.example.com
Addresses: 40.0.9.25 (DC1 IP)
40.0.50.123 (DC2 IP)
```
+ RDS Custom 인스턴스를 시작하는 VPC의 EC2 인스턴스에서 AWS 서비스를 확인합니다.
```
$region='input-your-aws-region'
$domainFQDN='input-your-domainFQDN'
function Test-DomainPorts {
param (
[string]$Domain,
[array]$Ports
)
foreach ($portInfo in $Ports) {
try {
$conn = New-Object System.Net.Sockets.TcpClient
$connectionResult = $conn.BeginConnect($Domain, $portInfo.Port, $null, $null)
$success = $connectionResult.AsyncWaitHandle.WaitOne(1000) # 1 second timeout
if ($success) {
$conn.EndConnect($connectionResult)
$result = $true
} else {
$result = $false
}
}
catch {
$result = $false
}
finally {
if ($null -ne $conn) {
$conn.Close()
}
}
Write-Host "$($portInfo.Description) port open: $result"
}
}
# Check if ports can be reached
$ports = @(
@{Port = 53; Description = "DNS"},
@{Port = 88; Description = "Kerberos"},
@{Port = 389; Description = "LDAP"},
@{Port = 445; Description = "SMB"},
@{Port = 5985; Description = "WinRM"},
@{Port = 636; Description = "LDAPS"},
@{Port = 3268; Description = "Global Catalog"},
@{Port = 3269; Description = "Global Catalog over SSL"},
@{Port = 9389; Description = "AD DS"}
)
function Test-DomainReachability {
param (
[string]$DomainName
)
try {
$dnsResults = Resolve-DnsName -Name $DomainName -ErrorAction Stop
Write-Host "Domain $DomainName is successfully resolving to following IP addresses: $($dnsResults.IpAddress)"
Write-Host ""
return $true
}
catch {
Write-Host ""
Write-Host "Error Message: $($_.Exception.Message)"
Write-Host "Domain $DomainName reachability check failed, please Configure DNS resolution"
return $false
}
}
$domain = (Get-WmiObject Win32_ComputerSystem).Domain
if ($domain -eq 'WORKGROUP') {
Write-Host ""
Write-Host "Host $env:computername is still part of WORKGROUP and not part of any domain"
}
else {
Write-Host ""
Write-Host "Host $env:computername is joined to $domain domain"
Write-Host ""
}
$isReachable = Test-DomainReachability -DomainName $domainFQDN
if ($isReachable) {
write-Host "Checking if domain $domainFQDN is reachable on required ports "
Test-DomainPorts -Domain $domainFQDN -Ports $ports
}
else {
Write-Host "Port check skipped. Domain not reachable"
}
# Get network adapter configuration
$networkConfig = Get-WmiObject Win32_NetworkAdapterConfiguration |
Where-Object { $_.IPEnabled -eq $true } |
Select-Object -First 1
# Check DNS server settings
$dnsServers = $networkConfig.DNSServerSearchOrder
if ($dnsServers) {
Write-Host "`nDNS Server settings:"
foreach ($server in $dnsServers) {
Write-Host " - $server"
}
} else {
Write-Host "`nNo DNS servers configured or unable to retrieve DNS server information."
}
write-host ""
# Checks reachability to dependent services
$services = "s3", "ec2", "secretsmanager", "logs", "events", "monitoring", "ssm", "ec2messages", "ssmmessages"
function Get-TcpConnectionAsync {
param (
$ServicePrefix,
$region
)
$endpoint = "${ServicePrefix}.${region}.amazonaws.com"
$tcp = New-Object Net.Sockets.TcpClient
$result = $false
try {
$connectTask = $tcp.ConnectAsync($endpoint, 443)
$timedOut = $connectTask.Wait(3000)
$result = $tcp.Connected
}
catch {
$result = $false
}
return $result
}
foreach ($service in $services) {
$validationResult = Get-TcpConnectionAsync -ServicePrefix $service -Region $region
Write-Host "Reachability to $service is $validationResult"
}
```
`TcpTestSucceeded` 값은 `s3`, `ec2`, `secretsmanager`, `logs`, `events`, `monitoring`, `ssm`, `ec2messages`, `ssmmessages`에 대해 `True`를 반환해야 합니다.
# RDS Custom for SQL Server 인스턴스에 대한 Windows 인증 설정
AD 도메인에 조인된 RDS Custom for SQL Server DB 인스턴스를 소유한 AWS 계정에 대해 전용 OU 및 해당 OU 범위의 서비스 보안 인증을 만드는 것이 좋습니다. 전용 OU 및 서비스 보안 인증을 지정하면 권한 충돌을 피하고 최소 권한 원칙을 따릅니다.
Active Directory 수준 그룹 정책은 AWS 자동화 및 권한과 충돌할 수 있습니다. RDS Custom for SQL Server에 대해 생성한 OU에만 적용되는 GPO를 선택하는 것이 좋습니다.
+ 자체 관리형 또는 온프레미스 AD에서 OU 및 AD 도메인 사용자를 생성하려면 도메인 컨트롤러를 도메인 관리자로 연결할 수 있습니다.
+ Directory Service 디렉터리에서 사용자 및 그룹을 생성하려면 관리 인스턴스에 연결하고 사용자 및 그룹 생성 권한이 있는 사용자로 로그인해야 합니다. 자세한 내용은 *AWS Directory Service 관리 안내서*의 [AWS Managed Microsoft AD에서의 사용자 및 그룹 관리](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html)를 참조하세요.
+ Amazon EC2 Windows Server 인스턴스에서 Active Directory를 관리하려면 EC2 인스턴스에서 Active Directory 도메인 서비스 및 Active Directory Lightweight Directory 서비스 도구를 설치해야 합니다. 자세한 내용은 *AWS Directory Service 관리 안내서*의 [AWS Managed Microsoft AD용 Active Directory 관리 도구 설치](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html)를 참조하세요.
+ 이러한 도구는 관리가 용이하도록 RDS Custom for SQL Server DB 인스턴스가 아닌 별도의 EC2 인스턴스에 설치하는 것이 좋습니다.
AD 도메인 서비스 계정의 요구 사항은 다음과 같습니다.
+ AD 도메인에는 컴퓨터를 도메인에 연결할 수 있는 권한이 위임된 서비스 계정이 있어야 합니다. 도메인 서비스 계정은 특정 작업을 수행할 권한이 위임된 AD의 사용자 계정입니다.
+ RDS Custom for SQL Server에 조인하려는 조직 단위의 도메인 서비스 계정에 다음 권한을 위임합니다.
+ 검증된 DNS 호스트 이름 쓰기 기능
+ 서비스 보안 주체 이름에 쓸 수 있는 검증된 기능
+ 컴퓨터 객체 생성 및 삭제
+ 자체 관리형 및 온프레미스 AD의 경우 도메인 서비스 계정은 ‘AWS위임 도메인 이름 시스템 관리자’ 그룹의 멤버여야 합니다.
+ AWS Managed Microsoft AD의 경우 도메인 서비스 계정은 ‘DnsAdmins’ 그룹의 멤버여야 합니다.
이러한 권한은 컴퓨터 객체를 자체 관리형 AD 및 AWS Managed Microsoft AD에 조인하는 데 필요한 최소 권한 집합입니다. 자세한 내용은 Microsoft Windows Server 설명서의 [오류: 제어를 위임받은 관리자가 아닌 사용자가 컴퓨터를 도메인 컨트롤러에 조인하려고 하면 액세스가 거부됨](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/access-denied-when-joining-computers) 항목을 참조하세요.
**중요**
DB 인스턴스를 만든 후에는 RDS Custom for SQL Server가 조직 단위(OU)에서 생성한 컴퓨터 객체를 옮기지 마세요. 연결된 객체를 이동하면 RDS Custom for SQL Server DB 인스턴스가 잘못 구성될 수 있습니다. Amazon RDS에서 생성한 컴퓨터 객체를 이동해야 하는 경우 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) 작업을 사용하여 컴퓨터 객체의 원하는 위치로 도메인 파라미터를 수정하세요.
**Topics**
+ [1단계: AD에서 조직 단위(OU) 생성](#custom-sqlserver-WinAuth.settingUp.CreateOU)
+ [2단계: AD 도메인 사용자 생성](#custom-sqlserver-WinAuth.settingUp.ADuser)
+ [3단계: 자체 관리형 또는 AWS Managed Microsoft AD에서 AD 사용자에게 제어 권한 위임](#custom-sqlserver-WinAuth.settingUp.Delegate)
+ [4단계: 보안 암호 생성](#custom-sqlserver-WinAuth.settingUp.ASM)
+ [5단계: RDS Custom for SQL Server DB 인스턴스 생성 또는 수정](#custom-sqlserver-WinAuth.settingUp.CreateDBInstance)
+ [6단계: Windows 인증 SQL Server 로그인 생성](#custom-sqlserver-WinAuth.settingUp.CreateLogins)
+ [7단계: Kerberos 또는 NTLM 인증 사용](#custom-sqlserver-WinAuth.settingUp.KerbNTLM)
## 1단계: AD에서 조직 단위(OU) 생성
다음 단계에 따라 AD에서 조직 단위를 생성합니다.
**AD에서 OU 생성**
1. 도메인 관리자로 도메인 AD에 연결합니다.
1. **Active Directory 사용자 및 컴퓨터**를 열고 OU를 생성할 도메인을 선택합니다.
1. 도메인을 마우스 오른쪽 버튼으로 클릭하고 **새로 만들기**를 선택한 다음 **조직 단위**를 선택합니다.
1. OU 이름을 입력합니다.
**컨테이너가 실수로 삭제되지 않도록 보호**를 활성화합니다.
1. **확인**을 선택합니다. 새 OU는 도메인 아래에 표시됩니다.
AWS Managed Microsoft AD의 경우 이 OU의 이름은 디렉터리 생성 시 입력한 NetBIOS 이름에 근거를 둡니다. 이 OU는 AWS가 소유하며, 전체 제어 권한을 부여한 모든 AWS 관련 디렉터리 객체가 포함됩니다. 기본적으로 이 OU에는 **컴퓨터와 사용자**라는 두 개의 하위 OU가 있습니다. RDS Custom이 생성하는 새 OU는 NetBIOS를 기반으로 하는 OU의 하위 OU입니다.
## 2단계: AD 도메인 사용자 생성
도메인 사용자 보안 인증 정보는 Secrets Manager에서 보안 암호로 사용됩니다.
**AD에서 AD 도메인 사용자 생성**
1. **Active Directory 사용자 및 컴퓨터**를 열고 사용자를 생성할 도메인과 OU를 선택합니다.
1. **사용자** 객체를 마우스 오른쪽 버튼으로 클릭하고 **새로 만들기**, **사용자** 순으로 선택합니다.
1. 사용자의 이름, 성 및 로그인 이름을 입력합니다. **다음**을 클릭합니다.
1. 사용자의 암호를 입력합니다. **다음 로그인 시 사용자가 암호를 변경해야 함** 또는 **계정이 비활성화됨**을 선택하지 마세요. **다음**을 클릭합니다.
1. **확인**을 클릭합니다. 새 사용자는 도메인 아래에 표시됩니다.
## 3단계: 자체 관리형 또는 AWS Managed Microsoft AD에서 AD 사용자에게 제어 권한 위임
**도메인의 AD 도메인 사용자에게 제어 권한을 위임하려면**
1. **Active Directory 사용자 및 컴퓨터** MMC 스냅인을 열고 도메인을 선택합니다.
1. 이전에 만든 OU를 마우스 오른쪽 버튼으로 클릭하고 **제어 위임**을 선택합니다.
1. **제어 위임 마법사**에서 **다음**을 클릭합니다.
1. **사용자 또는 그룹** 섹션에서 **추가**를 클릭합니다.
1. **사용자, 컴퓨터 또는 그룹 선택**에서 생성한 AD 사용자를 입력하고 **이름 확인**을 클릭합니다. AD 사용자 확인에 성공하면 **확인**을 클릭합니다.
1. **사용자 또는 그룹** 섹션에서 AD 사용자가 추가되었는지 확인하고 **다음**을 클릭합니다.
1. **위임할 작업** 섹션에서 **위임할 사용자 지정 작업 생성**을 선택하고 **다음**을 클릭합니다.
1. **Active Directory 객체 유형** 섹션에서:
**폴더의 다음 객체만**을 선택합니다.
**컴퓨터 객체**를 선택합니다.
**이 폴더에서 선택한 객체 생성**을 선택합니다.
**이 폴더에서 선택한 객체 삭제**를 선택하고 **다음**을 클릭합니다.
1. **권한** 섹션에서:
**일반**을 선택한 상태로 유지합니다.
**DNS 호스트 이름에 대한 검증된 쓰기**를 선택합니다.
**서비스 보안 주체 이름에 대한 검증된 쓰기**를 선택하고 **다음**을 클릭합니다.
1. **제어 위임 마법사를 완료하려면**에서 설정을 확인한 다음 **마침**을 클릭합니다.
## 4단계: 보안 암호 생성
Active Directory에 포함하려는 RDS Custom for SQL Server DB 인스턴스가 포함된 동일한 AWS 계정 및 리전에 보안 암호를 만들어야 합니다. [2단계: AD 도메인 사용자 생성](#custom-sqlserver-WinAuth.settingUp.ADuser)에서 생성된 AD 도메인 사용자의 자격 증명을 저장합니다.
------
#### [ Console ]
+ AWS Secrets Manager에서 **새 암호 저장**을 선택합니다.
+ **보안 암호 유형**에서 **다른 유형의 보안 암호**를 선택합니다.
+ **키/값 쌍**의 경우 2개의 키를 추가합니다.
+ 첫 번째 키 값에는 `SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME`을 입력하고 AD 사용자의 사용자 이름(도메인 접두사 제외)을 입력합니다.
+ 두 번째 키에 `SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD`를 입력하고 도메인에 AD 사용자의 암호를 입력합니다.
+ **암호화 키**에 RDS Custom for SQL Server 인스턴스를 생성하는 데 사용한 것과 동일한 AWS KMS 키를 입력합니다.
+ **보안 암호 이름**에서 `do-not-delete-rds-custom-`으로 시작하는 보안 암호 이름을 선택하여 인스턴스 프로파일이 이 보안 암호에 액세스할 수 있도록 합니다. 보안 암호에 다른 이름을 선택하려면 **보안 암호 이름**에 액세스하도록 `RDSCustomInstanceProfile`을 업데이트합니다.
+ (선택 사항) **설명**에 보안 암호 이름에 대한 설명을 입력합니다.
+ 태그 `Key="AWSRDSCustom",Value="custom-sqlserver"` 추가
+ **저장**을 클릭한 후 **다음**을 클릭합니다.
+ **교체 설정 구성**에서 기본값을 유지하고 **다음**을 선택합니다.
+ 보안 암호 설정을 검토하고 **저장**을 클릭합니다.
+ 새 보안 암호를 선택하고 **보안 암호 ARN**의 값을 복사합니다. 다음 단계에서 이를 사용하여 Active Directory를 설정합니다.
------
#### [ CLI ]
CLI에서 다음 명령을 실행하여 보안 암호를 생성합니다.
```
# Linux based
aws secretsmanager create-secret \
--name do-not-delete-rds-custom-DomainUserCredentails \
--description "Active directory user credentials for managing RDS Custom" \
--secret-string "{\"SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME\":\"tester\",\"SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD\":\"xxxxxxxx\"}" \
--kms-key-id \
--tags Key="AWSRDSCustom",Value="custom-sqlserver"
# Windows based
aws secretsmanager create-secret ^
--name do-not-delete-rds-custom-DomainUserCredentails ^
--description "Active directory user credentials for managing RDS Custom" ^
--secret-string "{\"SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME\":\"tester\",\"SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD\":\"xxxxxxxx\"}" ^
--kms-key-id ^
--tags Key="AWSRDSCustom",Value="custom-sqlserver"
```
------
## 5단계: RDS Custom for SQL Server DB 인스턴스 생성 또는 수정
디렉터리에서 사용할 RDS Custom for SQL Server DB 인스턴스를 생성하거나 수정합니다. 콘솔, CLI 또는 RDS API를 사용하여 DB 인스턴스를 디렉터리에 연결할 수 있습니다. 이 작업을 다음 중 한 가지 방법으로 수행할 수 있습니다.
+ 콘솔, [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) CLI 명령 또는 [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) RDS API 작업을 사용하여 새 SQL Server DB 인스턴스를 생성합니다.
지침은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 콘솔, [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI 명령 또는 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API 작업을 사용하여 기존 SQL Server DB 인스턴스를 수정합니다.
지침은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
+ 콘솔, [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) CLI 명령 또는 [RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) RDS API 작업을 사용하여 DB 스냅샷에서 SQL Server DB 인스턴스를 복원합니다.
지침은 [DB 인스턴스 복원](USER_RestoreFromSnapshot.md) 섹션을 참조하세요.
+ 콘솔, [restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI 명령 또는 [RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) RDS API 작업을 사용하여 SQL Server DB 인스턴스를 특정 시점으로 복구합니다.
지침은 [Amazon RDS에서 DB 인스턴스를 지정된 시간으로 복원](USER_PIT.md) 섹션을 참조하세요.
**참고**
RDS Custom for SQL Server 인스턴스가 이미 AD에 수동으로 조인된 경우 [네트워크 구성 포트 규칙](custom-sqlserver-WinAuth.NWConfigPorts.md), [네트워크 검증](custom-sqlserver-WinAuth.NWValidation.md)의 설정을 확인하고 1\$14단계를 완료합니다. 도메인 조인 보안 인증 정보 및 구성이 RDS Custom에 등록되어 CNAME를 모니터링, 등록 및 복구 작업을 수행할 수 있도록 `--domain-fqdn`, `--domain-ou` 및 `--domain-auth-secret-arn`을 AD로 업데이트합니다.
AWS CLI를 사용하는 경우 생성한 도메인 디렉터리를 DB 인스턴스에서 사용하려면 다음과 같은 파라미터가 필요합니다.
+ `--domain-fqdn` 파라미터에는 자체 관리형 AD의 정규화된 도메인 이름을 사용합니다.
+ `--domain-ou` 파라미터에는 자체 관리형 AD에서 만든 OU를 사용합니다.
+ `--domain-auth-secret-arn` 파라미터에는 생성한 **보안 암호 ARN**의 값을 사용합니다.
**중요**
자체 관리형 AD 도메인에 조인하거나 자체 관리형 AD 도메인 또는 AWS Managed Microsoft AD에서 제거하도록 DB 인스턴스를 수정한 경우 변경 사항이 적용되려면 DB 인스턴스를 재부팅해야 합니다. 변경 사항을 즉시 적용하거나 다음 유지 관리 기간까지 기다릴 수 있습니다. **즉시 적용** 옵션을 선택하면 단일 AZ DB 인스턴스에 가동 중단이 발생합니다. 다중 AZ DB 클러스터는 재부팅을 완료하기 전에 장애 조치를 수행합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
다음 CLI 명령은 새 RDS Custom for SQL Server DB 인스턴스를 만들어 자체 관리형 또는 AWS Managed Microsoft AD 도메인에 조인합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-instance \
--engine custom-sqlserver-se \
--engine-version 15.00.4312.2.v1 \
--db-instance-identifier my-custom-instance \
--db-instance-class db.m5.large \
--allocated-storage 100 --storage-type io1 --iops 1000 \
--master-username my-master-username \
--master-user-password my-master-password \
--kms-key-id my-RDSCustom-key-id \
--custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \
--domain-fqdn "corp.example.com" \
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" \
--db-subnet-group-name my-DB-subnet-grp \
--vpc-security-group-ids my-securitygroup-id \
--no-publicly-accessible \
--backup-retention-period 3 \
--port 8200 \
--region us-west-2 \
--no-multi-az
```
Windows의 경우:
```
aws rds create-db-instance ^
--engine custom-sqlserver-se ^
--engine-version 15.00.4312.2.v1 ^
--db-instance-identifier my-custom-instance ^
--db-instance-class db.m5.large ^
--allocated-storage 100 --storage-type io1 --iops 1000 ^
--master-usernamemy-master-username ^
--master-user-password my-master-password ^
--kms-key-id my-RDSCustom-key-id ^
--custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^
--domain-fqdn "corp.example.com" ^
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" ^
--db-subnet-group-name my-DB-subnet-grp ^
--vpc-security-group-ids my-securitygroup-id ^
--no-publicly-accessible ^
--backup-retention-period 3 ^
--port 8200 ^
--region us-west-2 ^
--no-multi-az
```
**중요**
AWS Managed Microsoft AD에 대한 NetBIOS가 **corpexample**인 경우 OU 자체로 표시됩니다. 이전에 생성된 새 OU는 중첩 OU로 표시됩니다. AWS Managed Microsoft AD의 경우 `--domain-ou`을 `"OU=RDSCustomOU,OU=corpexample,DC=corp,DC=example,DC=com"`으로 설정합니다.
다음 명령은 Active Directory 도메인을 사용하도록 기존 RDS Custom for SQL Server DB 인스턴스를 수정합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my-custom-instance \
--domain-fqdn "corp.example.com" \
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" \
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier my-custom-instance ^
--domain-fqdn "corp.example.com" ^
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" ^
```
다음 CLI 명령은 Active Directory 도메인에서 RDS Custom for SQL Server DB 인스턴스를 제거합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my-custom-instance \
--disable-domain
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier my-custom-instance ^
--disable-domain
```
콘솔을 사용하여 인스턴스를 생성하거나 수정할 때 **Microsoft SQL Server Windows 인증 활성화**를 클릭하여 다음 옵션을 확인합니다.
![\[Microsoft SQL Server Windows 인증 디렉터리\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/custom-sqs-WinAuth.png)
도메인 FQDN이 도메인 컨트롤러 IP 주소로 확인되고 있는지 확인하는 것은 사용자의 책임입니다. 도메인 컨트롤러 IP가 확인되지 않으면 도메인 조인 작업은 실패하지만 RDS Custom for SQL Server 인스턴스 만들기에 성공합니다. 문제 해결 정보는 [Active Directory 문제 해결](custom-sqlserver-WinAuth.Troubleshoot.md)를 참조하세요.
## 6단계: Windows 인증 SQL Server 로그인 생성
다른 DB 인스턴스의 경우와 같은 방법으로 Amazon RDS 마스터 사용자 보안 인증 정보를 사용하여 SQL Server DB 인스턴스에 연결합니다. DB 인스턴스는 AD 도메인에 조인되므로 SQL Server 로그인 및 사용자를 프로비저닝할 수 있습니다. 이 작업은 AD 도메인의 AD 사용자 및 그룹 유틸리티에서 수행합니다. 데이터베이스 권한은 이러한 Windows 로그인에 부여되거나 취소되는 표준 SQL Server 권한을 통해 관리됩니다.
AD 사용자가 SQL Server로 인증하려면 AD 사용자 또는 사용자가 속한 Active Directory 그룹에 대한 SQL Server Windows 로그인이 있어야 합니다. 세분화된 액세스 제어는 이러한 SQL Server 로그인에 대한 권한을 부여하거나 취소하여 처리합니다. SQL Server 로그인이 없거나 이러한 로그인이 있는 AD 그룹에 속하지 않은 AD 사용자는 SQL Server DB 인스턴스에 액세스할 수 없습니다.
AD SQL Server 로그인을 생성하려면 `ALTER ANY LOGIN` 권한이 필요합니다. 이 권한으로 로그인을 생성하지 않은 경우 SQL Server 인증을 사용하여 DB 인스턴스의 마스터 사용자로 연결하고 마스터 사용자의 맥락에서 AD SQL Server 로그인을 생성합니다.
다음과 같은 데이터 정의 언어(DDL) 명령을 실행하여 AD 사용자 또는 그룹에 대한 SQL Server 로그인을 생성할 수 있습니다.
```
USE [master]
GO
CREATE LOGIN [mydomain\myuser] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english];
GO
```
도메인의 사용자(사람 및 애플리케이션)는 이제 Windows 인증을 사용하여 도메인이 조인된 클라이언트 컴퓨터의 RDS Custom for SQL Server 인스턴스에 연결할 수 있습니다.
## 7단계: Kerberos 또는 NTLM 인증 사용
### RDS 엔드포인트를 사용한 NTLM 인증
각 Amazon RDS DB 인스턴스에는 엔드포인트가 있으며, 각 엔드포인트에는 DB 인스턴스의 DNS 이름과 포트 번호가 있습니다. SQL 클라이언트 애플리케이션을 사용해 DB 인스턴스에 연결하려면 DB 인스턴스에 연결할 수 있는 DNS 이름과 포트 번호가 필요합니다. NTLM 인증을 사용하여 인증하려면 RDS 엔드포인트에 연결해야 합니다.
계획된 데이터베이스 유지 관리 또는 예기치 않은 서비스 중단이 발생할 경우 Amazon RDS가 최신 보조 데이터베이스로 자동으로 장애 조치를 수행하므로 수동 개입 없이 작업을 빠르게 재개할 수 있습니다. 기본 인스턴스 및 보조 인스턴스는 동일한 엔드포인트를 사용합니다. 이 엔드포인트의 물리적 네트워크 주소는 장애 조치 프로세스의 일환으로 보조로 전환됩니다. 장애 조치가 발생하는 경우 애플리케이션을 다시 구성할 필요가 없습니다.
### Kerberos 인증
RDS Custom for SQL Server에 대한 Kerberos 기반 인증을 수행하려면 특정 서비스 보안 주체 이름(SPN)에 연결해야 합니다. 그러나 장애 조치 이벤트 후 애플리케이션이 새 SPN을 인식하지 못할 수 있습니다. 이를 해결하기 위해 RDS Custom for SQL Server는 Kerberos 기반 엔드포인트를 제공합니다.
Kerberos 기반 엔드포인트는 특정 형식을 따릅니다. RDS 엔드포인트가 `rds-instance-name.account-region-hash.aws-region.rds.amazonaws.com`인 경우 해당 Kerberos 기반 엔드포인트는 `rds-instance-name.account-region-hash.aws-region.awsrds.fully qualified domain name (FQDN)`입니다.
예를 들어 RDS 엔드포인트가 `ad-test.cocv6zwtircu.us-east-1.rds.amazonaws.com`이고 도메인 이름이 `corp-ad.company.com`인 경우 Kerberos 기반 엔드포인트는 `ad-test.cocv6zwtircu.us-east-1.awsrds.corp-ad.company.com`입니다.
이 Kerberos 기반 엔드포인트는 기본 SQL Server 인스턴스의 새 SPN을 가리키도록 엔드포인트가 자동으로 업데이트되므로 장애 조치 이벤트 후에도 Kerberos를 사용하여 SQL Server 인스턴스로 인증하는 데 사용할 수 있습니다.
### CNAME 찾기
CNAME를 찾으려면 도메인 컨트롤러에 연결하고 **DNS Manager**를 엽니다. **정방향 조회 영역** 및 FQDN으로 이동합니다.
**awsrds**, **aws-region**, **계정 및 리전별 해시**를 탐색합니다.
RDS Custom EC2 인스턴스를 연결하고 CNAME를 사용하여 로컬에서 데이터베이스에 연결하려고 하면 연결에서 Kerberos 대신 NTLM 인증을 사용합니다.
원격 클라이언트에서 CNAME를 연결한 후 NTLM 연결이 반환되면 필요한 포트가 허용 목록에 있는지 확인합니다.
연결에서 Kerberos를 사용 중인지 확인하려면 다음 쿼리를 실행합니다.
```
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SSPID;
```
# 도메인에서 DB 인스턴스 관리
콘솔, AWS CLI 또는 Amazon RDS API를 사용하여 DB 인스턴스 및 DB 인스턴스와 도메인과의 관계를 관리할 수 있습니다. 예를 들어, DB 인스턴스를 도메인 내로, 도메인 외부로 또는 도메인 간에 이동할 수 있습니다.
예를 들어 Amazon RDS API를 사용하여 다음을 수행할 수 있습니다.
+ 실패한 멤버십에 대한 도메인 조인을 다시 시도하려면 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API 작업을 사용하고 현재 멤버십의 디렉터리 ID를 지정합니다.
+ 멤버십에 대한 IAM 역할 이름을 업데이트하려면 `ModifyDBInstance` API 작업을 사용하고 현재 멤버십의 디렉터리 ID 및 새 IAM 역할을 지정합니다.
+ 도메인에서 DB 인스턴스를 제거하려면 `ModifyDBInstance` API 작업을 사용하고 `none`을 도메인 파라미터로 지정합니다.
+ 한 도메인에서 다른 도메인으로 DB 인스턴스를 이동하려면 `ModifyDBInstance` API 작업을 사용하여 새 도메인의 도메인 식별자를 도메인 파라미터로 지정합니다.
+ 각 DB 인스턴스에 대한 멤버십을 나열하려면 [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html) API 작업을 사용합니다.
## RDS Custom for SQL Server DB 인스턴스 복원 및 Active Directory 도메인에 추가
DB 스냅샷을 복원하거나 SQL Server DB 인스턴스에 대한 특정 시점 복구(PITR)를 수행한 후 Active Directory 도메인에 추가할 수 있습니다. DB 인스턴스가 복원된 후 [5단계: RDS Custom for SQL Server DB 인스턴스 생성 또는 수정](custom-sqlserver-WinAuth.settingUp.md#custom-sqlserver-WinAuth.settingUp.CreateDBInstance)에 설명된 프로세스를 사용하여 DB 인스턴스를 AD 도메인에 추가하도록 인스턴스를 수정합니다.
# 도메인 멤버십 이해
DB 인스턴스를 생성하거나 수정한 경우 해당 인스턴스는 도메인의 구성원이 됩니다. AWS 콘솔은 DB 인스턴스에 대한 도메인 멤버십의 상태를 나타냅니다. DB 인스턴스의 상태는 다음 중 한 가지가 될 수 있습니다.
+ **joined** – 인스턴스가 도메인의 구성원입니다.
+ **joining** – 인스턴스가 도메인 구성원이 되기 위한 과정을 진행하고 있습니다.
+ **pending-join** – 인스턴스 멤버십이 보류 중입니다.
+ **pending-maintenance-join** - AWS에서 다음 예약된 유지 관리 기간 동안 인스턴스를 도메인의 멤버로 만들려고 시도합니다.
+ **pending-removal** – 도메인에서 인스턴스 제거 작업이 보류 중입니다.
+ **pending-maintenance-removal** - AWS에서 다음 예약된 유지 관리 기간 동안 도메인에서 인스턴스를 제거하려고 시도합니다.
+ **failed** – 구성 문제가 발생하여 인스턴스가 도메인에 조인되지 않았습니다. 인스턴스 수정 명령을 다시 실행하기 전에 구성을 확인하고 수정합니다.
+ **removing** – 인스턴스를 도메인에서 제거하고 있습니다.
네트워크 연결 문제 또는 잘못된 IAM 역할로 인해 도메인 구성원 되기 요청이 실패할 수 있습니다. 예를 들어, DB 인스턴스를 생성하거나 기존 인스턴스를 수정하여 DB 인스턴스가 도메인의 멤버가 되려는 시도를 못하게 할 수 있습니다. 이 경우 명령을 다시 실행하여 DB 인스턴스를 생성 또는 수정하거나 새로 생성된 인스턴스를 수정하여 도메인에 조인할 수 있습니다.
# Active Directory 문제 해결
다음은 AD를 설정하거나 수정할 때 발생할 수 있는 문제입니다.
| 오류 코드 | 설명 | 일반적인 원인 | 문제 해결 제안 |
| --- | --- | --- | --- |
| 오류 2/0x2 | 시스템이 지정된 파일을 찾을 수 없습니다. | `—domain-ou` 파라미터로 지정된 조직 단위(OU)의 형식 또는 위치가 잘못되었습니다. AWS Secrets Manager를 통해 지정된 도메인 서비스 계정에는 OU에 가입하는 데 필요한 권한이 없습니다. | `—domain-ou` 파라미터를 검토합니다. 도메인 서비스 계정에 OU에 대한 올바른 권한이 있는지 확인합니다. |
| 오류 5/0x5 | 액세스가 거부되었습니다. | 도메인 서비스 계정에 대한 권한이 잘못 구성되었거나 컴퓨터 계정이 이미 도메인에 있습니다. | 도메인의 도메인 서비스 계정 권한을 검토하고 RDS 컴퓨터 계정이 도메인에 중복되지 않았는지 확인합니다. RDS Custom for SQL Server DB 인스턴스에서 `SELECT @@SERVERNAME`을 실행하여 RDS 컴퓨터 계정의 이름을 확인할 수 있습니다. 다중 AZ를 사용하는 경우 장애 조치를 사용하여 재부팅한 다음 RDS 컴퓨터 계정을 다시 확인합니다. 자세한 내용은 [ DB 인스턴스 재부팅](USER_RebootInstance.md) 단원을 참조하십시오. |
| 오류 87/0x57 | 파라미터가 올바르지 않습니다. | AWS Secrets Manager를 통해 지정된 도메인 서비스 계정에 올바른 권한이 없습니다. 사용자 프로필도 손상되었을 수 있습니다. | 도메인 서비스 계정의 요구 사항을 검토합니다. |
| 오류 234/0xEA | 지정된 조직 단위(OU)가 없습니다. | `—domain-ou` 파라미터로 지정된 OU가 AD에 존재하지 않습니다. | `—domain-ou` 파라미터를 검토하고 지정된 OU가 AD에 있는지 확인합니다. |
| 오류 1326/0x52E | 사용자 이름 또는 암호가 잘못되었습니다. | AWS Secrets Manager에 제공된 도메인 서비스 계정 보안 인증 정보에 알 수 없는 사용자 이름이나 잘못된 암호가 있습니다. AD에서 도메인 계정을 사용하지 않도록 설정할 수도 있습니다. | AWS Secrets Manager에 제공된 보안 인증 정보가 올바르고 Active Directory에서 도메인 계정이 활성화되어 있는지 확인합니다. |
| 오류 1355/0x54B | 지정된 도메인이 존재하지 않거나 해당 주소를 찾을 수 없습니다. | 도메인이 중지되었거나, 지정된 DNS IP 집합에 연결할 수 없거나, 지정된 FQDN에 연결할 수 없습니다. | `—domain-dns-ips` 및 `—domain-fqdn` 파라미터를 검토하여 올바른지 확인합니다. RDS Custom for SQL Server DB 인스턴스의 네트워킹 구성을 검토하고 AD에 연결할 수 있는지 확인합니다. |
| 오류 1722/0x6BA | RPC 서버를 사용할 수 없습니다. | AD 도메인의 RPC 서비스에 연결하는 중 문제가 발생했습니다. 서비스 또는 네트워크 문제일 수 있습니다. | RPC 서비스가 도메인 컨트롤러에서 실행되고 있고 TCP 포트 `135` 및 `49152-65535`에서 RDS Custom for SQL Server DB 인스턴스의 도메인에 연결할 수 있는지 확인합니다. |
| 오류 2224/0x8B0 | 계정이 이미 있습니다. | AD에 추가하려는 컴퓨터 계정이 이미 있습니다. | RDS Custom for SQL Server DB 인스턴스에서 `SELECT @@SERVERNAME`을 실행하여 컴퓨터 계정을 식별한 다음 AD에서 해당 계정을 신중히 제거합니다. |
| 오류 2242/0x8c2 | 이 사용자의 암호가 만료되었습니다. | AWS Secrets Manager를 통해 지정한 도메인 서비스 계정의 암호가 만료되었습니다. | RDS Custom for SQL Server DB 인스턴스를 AD에 가입시키는 데 사용되는 도메인 서비스 계정의 암호를 업데이트합니다. |