# 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 Managed Active Directory を使用する方法について説明します。
**Topics**
+ [利用可能なリージョンとバージョン](#custom-sqlserver-WinAuth.Regions)
+ [セルフマネージド AD またはオンプレミス 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 またはオンプレミス AD を設定する
オンプレミスまたはセルフマネージドの Microsoft AD を RDS Custom for SQL Server DB インスタンスに結合するには、アクティブドメインを次のように設定する必要があります。
+ RDS Custom for SQL Server DB インスタンスに関連付けられている VPC 内のサブネットを、セルフマネージド AD またはオンプレミス AD で定義します。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 ピアリング接続を使用します。
+ RDS Custom for SQL Server セキュリティグループとネットワーク ACL からセルフマネージド AD またはオンプレミス AD へのトラフィックをポートで許可します。詳細については、「[ネットワーク設定ポートルール](custom-sqlserver-WinAuth.NWConfigPorts.md)」を参照してください。
![\[Microsoft SQL Server の Windows 認証ディレクトリ\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/custom-sqs-SM-NC.png)
## DNS 解決を設定する
セルフマネージド AD またはオンプレミス 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 は、Windows Server 2019 を搭載した AWS でフルマネージドの Microsoft Active Directory を作成し、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 トラフィックを有効にする
同じ VPC 内にディレクトリと DB インスタンスを配置するには、このステップをスキップして「[ネットワーク設定ポートルール](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 アカウントがディレクトリを所有している場合は、ディレクトリを共有する必要があります。RDS Custom for SQL Server インスタンスが含まれているディレクトリを AWS アカウント と共有するには、「*AWS Directory Service 管理ガイド*」の「[チュートリアル: シームレスな EC2 ドメイン結合のための AWS Managed Microsoft AD の共有](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html)」に従います。
**ディレクトリを AWS アカウント間で共有する**
1. DB インスタンスのアカウントを使用して Directory Service コンソールにサインインし、ドメインのステータスが `SHARED` であることを確認してから、続行します。
1. DB インスタンスのアカウントを使用して Directory Service コンソールにサインインした後で、**[ディレクトリ ID]** の値を書き留めておきます。この ID は、DB インスタンスをドメインに参加させるために使用します。
## DNS 解決を設定する
AWS Managed Microsoft AD でディレクトリを作成すると、ユーザーに代わって Directory Service が 2 つのドメインコントローラーを作成し、DNS サービスを追加します。
VPC に既存の AWS Managed Microsoft AD があるか、RDS Custom for SQL Server DB インスタンス以外の AD を起動する予定がある場合は、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/ja_jp/AmazonRDS/latest/UserGuide/images/custom_sqlserver_ActiveDirectory_Requirements_NetworkConfig.png)
以下の表に、各ポートのロールを示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/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-65535) で許可する必要があります。これらのトラフィックルールが、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 またはオンプレミス 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 およびオンプレミス 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 に 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. [**OK**] を選択してください。新しい OU がドメインの下に表示されます。
AWS Managed Microsoft AD の場合、この OU の名前は、ディレクトリの作成時に入力した NetBIOS 名に基づきます。この OU は AWS が所有し、AWS 関連のディレクトリオブジェクトをすべて含んでいます。ユーザーは、これらのオブジェクトに対して完全な制御権を付与されます。デフォルトでは、この OU の下に 2 つの子 OU (**Computers および Users**) が存在します。RDS Custom が作成する新しい OU は、NetBIOS に基づく OU の子です。
## ステップ 2: AD に AD ドメインユーザーを作成する
ドメインユーザーの認証情報は Secrets Manager のシークレットに使用されます。
**AD に AD ドメインユーザーを作成する**
1. **[Active Directory ユーザーとコンピュータ]** を開き、ユーザーを作成するドメインと OU を選択します。
1. **[ユーザー]** オブジェクトを右クリックして、**[新規]** を選択し、**[ユーザー]** を選択します。
1. ユーザーの姓名とログイン名を入力します。**[次へ]** をクリックします。
1. ユーザーのパスワードを入力します。**[ユーザーは次回のログイン時にパスワードを変更する必要があります]** または **[アカウントは無効になっています]** を選択しないでください。**[次へ]** をクリックします。
1. **[OK]** をクリックします。新しいユーザーがドメインの下に表示されます。
## ステップ 3: セルフマネージドまたは AWS Managed Microsoft AD で AD ユーザーに制御を委任する
**ドメイン内の AD ドメインユーザーに制御を委任するには**
1. **[Active Directory ユーザーとコンピュータ]** MMC スナップインを開き、ドメインを選択します。
1. 前に作成した OU を右クリックし、**[制御を委任]** を選択します。
1. **[委任制御ウィザード]** で、**[次へ]** を選択します。
1. **[ユーザーまたはグループ]** セクションで、**[追加]** をクリックします。
1. **[ユーザー、コンピューター、またはグループを選択]** で、作成した AD ユーザーを入力し、**[名前を確認]** をクリックします。AD ユーザーのチェックが成功したら、**[OK]** をクリックします。
1. **[ユーザーまたはグループ]** セクションで、AD ユーザーが追加されたことを確認し、**[次へ]** をクリックします。
1. **[委任するタスク]** セクションで、**[委任するカスタムタスクを作成]** を選択し、**[次へ]** をクリックします。
1. **[Active Directory オブジェクトタイプ]** セクションで、次の操作を行います。
**[フォルダ内の次のオブジェクトのみ]** を選択します。
**[コンピュータオブジェクト]** を選択します。
**[このフォルダに選択したオブジェクトを作成]** を選択します。
**[このフォルダ内の選択したオブジェクトを削除]** を選択し、**[次へ]** をクリックします。
1. **[アクセス許可]** セクションで、次の操作を行います。
**[全般]** を選択したままにします。
**[DNS ホスト名への検証済み書き込み]** を選択します。
**[サービスプリンシパル名への検証済み書き込み]** を選択し、**[次へ]** をクリックします。
1. **[制御の委任を完了ウィザード]** で、設定を確認して **[完了]** をクリックします。
## ステップ 4: シークレットを作成する
シークレットは、アクティブディレクトリに含める RDS Custom for SQL Server DB インスタンスがある同じ AWS アカウントおよびリージョンに作成します。「[ステップ 2: AD に AD ドメインユーザーを作成する](#custom-sqlserver-WinAuth.settingUp.ADuser)」で作成した AD ドメインユーザーの認証情報を保存します。
------
#### [ Console ]
+ AWS Secrets Manager で、**[新しいシークレットを保存]** を選択します。
+ **[Secret type] (シークレットタイプ)** で、**[Other type of secret]** (他の種類のシークレット) を選択します。
+ **[キー/値のペア]** で、2 つのキーを追加します。
+ 最初のキー `SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME` の値には、AD ユーザーのユーザー名 (ドメインプレフィックスなし) のみを入力します。
+ 2 番目のキーとして `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 インスタンスとディレクトリを関連付けることができます。これには以下の 2 つの方法があります。
+ コンソール、[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 からステップ 4 までを完了します。`--domain-fqdn`、`--domain-ou`、`--domain-auth-secret-arn` を AD に更新して、ドメイン参加の認証情報と設定を RDS Custom に登録し、モニタリング、CNAME の登録、復旧アクションの実行ができるようにします。
AWS CLI を使用する場合は、DB インスタンスが、作成したディレクトリを使用できるように、以下のパラメータが必要です。
+ `--domain-fqdn` パラメータには、セルフマネージド AD の完全修飾ドメイン名を使用します。
+ `--domain-ou` パラメータには、セルフマネージド AD で作成した OU を使用します。
+ `--domain-auth-secret-arn` パラメータには、作成した**シークレット ARN** の値を使用します。
**重要**
DB インスタンスを変更してセルフマネージド AD ドメインや AWS Managed Microsoft AD に参加させたり、これらから削除したりする場合、変更を有効にするには DB インスタンスを再起動する必要があります。変更をすぐに適用するか、次のメンテナンスウィンドウまで待つかを選択できます。**[すぐに適用]** オプションを選択すると、シングル AZ DB インスタンスのダウンタイムが発生します。マルチ AZ DB クラスターは、再起動を完了する前にフェイルオーバーを実行します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
次の CLI コマンドは、新しい RDS Custom for SQL Server DB インスタンスを作成し、それをセルフマネージドドメインまたは AWS Managed Microsoft AD ドメインに参加させます。
Linux、macOS、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 インスタンスを変更します。
Linux、macOS、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 インスタンスを削除します。
Linux、macOS、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/ja_jp/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 ログインを作成する
Amazon RDS マスターユーザーの認証情報を使用して、他の DB インスタンスと同じように SQL Server DB インスタンスに接続します。DB インスタンスは AD ドメインに参加しているため、SQL Server のログインとユーザーをプロビジョニングできます。これは、AD ドメインの AD ユーザーとグループユーティリティから行います。データベースへのアクセス許可は、これらの Windows ログインに付与され無効化されている標準の SQL サーバーのアクセス許可によって管理されています。
AD ユーザーが SQL Server で認証するには、AD ユーザーまたはそのユーザーがメンバーになっている Active Directory グループに SQL Server Windows ログインが必要です。これらの SQL Server ログインでアクセスを許可したり取り消したりして、細分化されたアクセスコントロールを処理します。AD ユーザーが SQL Server ログインを持っていないか、そのようなログインを持つ AD グループに属していない場合、SQL Server DB インスタンスにアクセスすることはできません。
AD SQL Server ログインを作成するには、`ALTER ANY LOGIN` アクセス許可が必要です。このアクセス許可を持つログインをまだ作成していない場合は、SQL Server 認証を使用して DB インスタンスのマスターユーザーとして接続し、マスターユーザーのコンテキストで AD SQL Server ログインを作成します。
AD ユーザーまたは AD グループの SQL Server ログインを作成するには、次に示すようなデータ定義言語 (DDL) コマンドを実行できます。
```
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 マネージャー]** を開きます。**[前方参照ゾーン]** と 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 インスタンスをドメイン内、ドメイン外、またはドメイン間で移動させることができます。
例えば、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 ドメインに追加する
SQL Server DB インスタンスの 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 (参加保留中)** – インスタンスのメンバーシップは保留中です。
+ **メンテナンスまで参加保留中** – 次に予定されているメンテナンスウィンドウ中に、AWS がインスタンスをドメインのメンバーにできるよう試みます。
+ **pending-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 コンピュータアカウントの名前は、RDS Custom for SQL Server DB インスタンスで `SELECT @@SERVERNAME` を実行することで確認できます。マルチ 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 にアクセスできることを確認します。 |
| エラー 1772 / 0x6BA | RPC サーバーは使用できません。 | AD ドメインの RPC サービスへのアクセスに問題がありました。これはサービスまたはネットワークの問題かもしれません。 | RPC サービスがドメインコントローラーで実行されていることと、RDS Custom for SQL Server DB インスタンスからドメインの TCP ポート `135` および `49152-65535` にアクセスできることを確認します。 |
| エラー 2224 / 0x8B0 | ユーザーアカウントは既に存在しています。 | AD に追加しようとしているコンピュータアカウントは既に存在します。 | RDS Custom for SQL Server DB インスタンスで `SELECT @@SERVERNAME` を実行してコンピュータアカウントを特定し、それを AD から慎重に削除します。 |
| エラー 2242 / 0x8c2 | このユーザーのパスワードは有効期限が切れています。 | AWS Secrets Manager で指定されたドメインサービスアカウントのパスワードは有効期限が切れています。 | RDS Custom for SQL Server DB インスタンスを AD に参加させるために使用しているドメインサービスアカウントのパスワードを更新します。 |