# RDS for SQL Server による Active Directory の操作
RDS for SQL Server DB インスタンスを Microsoft Active Directory (AD) ドメインに参加させることができます。AD ドメインは、AWS 内の AWS マネージド AD で、企業データセンターなど任意の場所のセルフマネージド AD で、AWS EC2 で、またはその他のクラウドプロバイダーでホストすることができます。
セルフマネージド Active Directory および AWS Managed Microsoft AD では、NTLM 認証と Kerberos 認証を使用してドメインユーザーを認証できます。
以下のセクションでは、Amazon RDS 上の Microsoft SQL Server について、セルフマネージド Active Directory と AWS マネージド Active Directory の使用方法について説明します。
**Topics**
+ [Amazon RDS for SQL Server DB インスタンスによるセルフマネージド Active Directory の操作](USER_SQLServer_SelfManagedActiveDirectory.md)
+ [RDS for SQL Server による AWS Managed Active Directory の操作](USER_SQLServerWinAuth.md)
# Amazon RDS for SQL Server DB インスタンスによるセルフマネージド Active Directory の操作
Amazon RDS for SQL Server は、データセンター内、Amazon EC2、またはその他のクラウドプロバイダーなど、AD がホストされている場所に関係なく、セルフマネージド Active Directory (AD) ドメインとシームレスに統合されます。この統合により、NTLM または Kerberos プロトコルを介した直接ユーザー認証が可能になり、複雑な中間ドメインやフォレストの信頼性が不要になります。RDS SQL Server DB インスタンスに接続すると、認証リクエストは指定された AD ドメインに安全に転送され、Amazon RDS のマネージドデータベース機能を活用しながら、既存の ID 管理構造が維持されます。
**Topics**
+ [利用可能なリージョンとバージョン](#USER_SQLServer_SelfManagedActiveDirectory.RegionVersionAvailability)
+ [要件](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md)
+ [考慮事項](#USER_SQLServer_SelfManagedActiveDirectory.Limitations)
+ [セルフマネージド Active Directory の設定](USER_SQLServer_SelfManagedActiveDirectory.SettingUp.md)
+ [DB インスタンスをセルフマネージド Active Directory に結合する](USER_SQLServer_SelfManagedActiveDirectory.Joining.md)
+ [セルフマネージド Active Directory ドメイン内の DB インスタンスの管理](USER_SQLServer_SelfManagedActiveDirectory.Managing.md)
+ [セルフマネージド Active Directory ドメインメンバーシップについて](#USER_SQLServer_SelfManagedActiveDirectory.Understanding)
+ [セルフマネージド Active Directory のトラブルシューティング](USER_SQLServer_SelfManagedActiveDirectory.TroubleshootingSelfManagedActiveDirectory.md)
+ [SQL Server DB インスタンスを復元してからセルフマネージド Active Directory ドメインに追加する](#USER_SQLServer_SelfManagedActiveDirectory.Restore)
## 利用可能なリージョンとバージョン
Amazon RDS は、すべての商用 AWS リージョンおよび AWS GovCloud (US) Regions で NTLM を使用するセルフマネージド AD for SQL Server をサポートしています。
# 要件
RDS for SQL Server DB インスタンスをセルフマネージド AD ドメインに参加させる前に、次の要件を満たしていることを確認してください。
**Topics**
+ [オンプレミス AD の設定](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.OnPremConfig)
+ [ネットワーク接続の設定](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig)
+ [AD ドメインサービスアカウントの設定](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig)
+ [LDAPS を介した安全な通信の設定](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.LDAPS)
## オンプレミス AD の設定
Amazon RDS for SQL Server インスタンスを参加させることができるオンプレミスまたはその他のセルフマネージド Microsoft AD があることを確認してください。オンプレミス AD には以下の設定が必要です。
+ AD サイトが定義されている場合、RDS for SQL Server DB インスタンスに関連付けられている VPC 内のサブネットが AD サイトで定義されていることを確認してください。VPC 内のサブネットと他の AD サイトのサブネットの間に競合がないことを確認します。
+ AD ドメインコントローラーは、Windows Server 2008 R2 以降のドメイン機能レベルを持ちます。
+ AD ドメイン名をシングルラベルドメイン (SLD) 形式にすることはできません。RDS for SQL Server は、SLD ドメインをサポートしていません。
+ AD の完全修飾ドメイン名 (FQDN) は 47 文字以内で指定します。
## ネットワーク接続の設定
次のネットワーク設定を満たしていることを確認します。
+ RDS for SQL Server DB インスタンスを作成する Amazon VPC とセルフマネージド AD の間の接続を設定します。接続は、AWS 直接接続、AWS VPN、VPC ピアリング、または AWS トランジットゲートウェイを使用して設定できます。
+ VPC セキュリティグループ については、デフォルトの Amazon VPC のデフォルトセキュリティグループが、コンソールの RDS for SQL Server DB インスタンスに既に追加されています。RDS for SQL Server DB インスタンスを作成するサブネットのセキュリティグループと VPC ネットワーク ACL が、次の図に示す方向でのポート上のトラフィックを許可していることを確認します。
![\[セルフマネージド AD ネットワーク設定ポートルール。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/SQLServer_SelfManagedActiveDirectory_Requirements_NetworkConfig.png)
以下の表に、各ポートのロールを示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.Requirements.html)
+ 通常、ドメイン DNS サーバーは AD ドメインコントローラーにあります。この機能を使用するために VPC DHCP オプションセットを設定する必要はありません。詳細については、「*Amazon VPC ユーザーガイド*」の「[DHCP オプションセット](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)」を参照してください。
**重要**
VPC ネットワーク ACL を使用している場合は、RDS for SQL Server DB インスタンスからのダイナミックポート (49152-65535) でのアウトバウンドトラフィックも許可する必要があります。これらのトラフィックルールが、各 ADドメインコントローラー、DNS サーバー、および RDS for SQL Server DB インスタンスにもミラーリングされていることを確認します。
VPC セキュリティグループでは、ネットワークトラフィックが開始される方向でのみポートを開く必要がありますが、ほとんどの Windows ファイアウォールとおよび VPC ネットワーク ACL では両方向にポートを開く必要があります。
## AD ドメインサービスアカウントの設定
AD ドメインサービスアカウントが次の要件を満たしていることを確認してください。
+ コンピュータをドメインに参加させる委任アクセス許可のあるドメインサービスアカウントがセルフマネージド AD ドメインにあることを確認してください。ドメインサービスアカウントは、特定のタスクを実行するアクセス許可を委任されたセルフマネージド AD のユーザーアカウントです。
+ ドメインサービスアカウントには、RDS for SQL Server DB インスタンスを参加させる組織単位 (OU) の以下のアクセス許可を委任する必要があります。
+ DNS ホスト名への書き込みを検証する機能
+ サービスプリンシパル名への書き込みを検証する機能
+ コンピュータオブジェクトを作成および削除する
これらは、コンピュータオブジェクトをセルフマネージド AD に接続させるために必要な最小限の許可セットです。詳細については、Microsoft Windows Server ドキュメントの「[コンピューターをドメインに参加させようとするとエラーが発生する](https://learn.microsoft.com/en-US/troubleshoot/windows-server/identity/access-denied-when-joining-computers)」を参照してください。
+ Kerberos 認証を使用するには、AD ドメインサービスアカウントにサービスプリンシパルネーム (SPN) と DNS アクセス許可を提供する必要があります。
+ **書き込み SPN**: RDS for SQL Server DB インスタンスに参加する必要がある OU の AD ドメインサービスアカウントに**書き込み SPN** アクセス許可を委任します。このアクセス許可は、検証済みの書き込み SPN とは異なります。
+ **DNS アクセス許可**: ドメインコントローラーのサーバーレベルで DNS マネージャーの AD ドメインサービスアカウントに次のアクセス許可を付与します。
+ コンテンツを一覧表示する
+ すべてのプロパティを読み取る
+ 読み取りアクセス許可
**重要**
DB インスタンスの作成後に RDS for SQL Server が組織単位に作成したコンピュータオブジェクトを移動しないでください。関連するオブジェクトを移動すると、RDS for SQL Server DB インスタンスが誤って設定される原因となります。Amazon RDS によって作成されたコンピュータオブジェクトを移動する必要がある場合は、[ModifyDbInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API オペレーションを使用して、コンピュータオブジェクトの目的の場所にドメインパラメータを変更します。
## LDAPS を介した安全な通信の設定
RDS がドメインコントローラー内のコンピュータオブジェクトと SPN をクエリしてアクセスするには、LDAPS 経由の通信が推奨されます。安全な LDAP を使用するには、安全な LDAPS の要件を満たす有効な SSL 証明書をドメインコントローラーで使用します。有効な SSL 証明書がドメインコントローラーに存在しない場合、RDS for SQL Server DB インスタンスはデフォルトで LDAP を使用します。証明書の有効性の詳細については、「[Requirements for an LDAPS certificate](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-over-ssl-3rd-certification-authority#requirements-for-an-ldaps-certificate)」を参照してください。
## 考慮事項
RDS for SQL Server DB インスタンスをセルフマネージド AD に追加するときは、次の点を考慮してください。
+ DB インスタンスは、AD ドメインのタイムサーバーではなく、AWS の NTP サービスと同期します。AD ドメイン内のリンクされた SQL Server インスタンス間のデータベース接続の場合、SQL 認証のみ実行でき、Windows 認証は実行できません。
+ セルフマネージド AD ドメインのグループポリシーオブジェクト設定は RDS for SQL Server インスタンスには伝播されません。
# セルフマネージド Active Directory の設定
セルフマネージド AD を設定するには、次の手順を実行してください。
**Topics**
+ [ステップ 1: AD に組織単位を作成する](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateOU)
+ [ステップ 2: AD に AD ドメインサービスアカウントを作成する](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateADuser)
+ [ステップ 3: AD ドメインサービスアカウントに制御を委任する](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.DelegateControl)
+ [ステップ 4: AWS KMS キーを作成する](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateKMSkey)
+ [ステップ 5: AWS シークレットを作成する](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateSecret)
## ステップ 1: AD に組織単位を作成する
**重要**
セルフマネージド AD ドメインに参加した RDS for SQL Server DB インスタンスを所有する AWS アカウントに、専用の OU とその OU を対象とするサービス認証情報を作成することをお勧めします。OU とサービス認証情報を専用にすることで、アクセス許可の競合を回避し、最小特権の原則に従うことができます。
**AD に OU を作成するには**
1. ドメイン管理者として AD ドメインに接続します。
1. **[Active Directory ユーザーとコンピューター]** を開き、OU を作成するドメインを選択します。
1. ドメインを右クリックして、**[新規]** を選択し、次に **[組織単位]** を選択します。
1. OU の名前を入力します。
1. **[コンテナを誤って削除しないように保護する]** ボックスはオンのままにしてください。
1. **[OK]** をクリックします。新しい OU がドメインの下に表示されます。
## ステップ 2: AD に AD ドメインサービスアカウントを作成する
ドメインサービスアカウントの認証情報は AWS Secrets Manager のシークレットに使用されます。
**AD に AD ドメインサービスアカウントを作成するには**
1. **[Active Directory ユーザーとコンピューター]** を開き、ユーザーを作成するドメインと OU を選択します。
1. **[ユーザー]** オブジェクトを右クリックして、**[新規]** を選択し、**[ユーザー]** を選択します。
1. ユーザーの名、姓、およびログオン名を入力します。**[次へ]** をクリックします。
1. ユーザーのパスワードを入力します。**[ユーザーは次回のログイン時にパスワードを変更する必要がある]** を選択しないでください。**[アカウントは無効です]** を選択しないでください。**[次へ]** をクリックします。
1. **[OK]** をクリックします。新しいユーザーがドメインの下に表示されます。
## ステップ 3: AD ドメインサービスアカウントに制御を委任する
**ドメイン内の AD ドメインサービスアカウントに制御を委任するには**
1. **[Active Directory ユーザーとコンピューター]** MMC スナップインを開き、ユーザーを作成するドメインを選択します。
1. 前に作成した OU を右クリックして、**[制御を委任]** を選択します。
1. **[コントロールウィザードの委任]** で、**[次へ]** を選択します。
1. **[ユーザーまたはグループ]** セクションで、**[追加]** をクリックします。
1. **[ユーザー、コンピューター、またはグループの選択]** セクションで、作成した AD ドメインサービスアカウントを入力し、**[名前を確認]** をクリックします。AD ドメインサービスアカウントのチェックが成功したら、**[OK]** をクリックします。
1. **[ユーザーまたはグループ]** セクションで、AD ドメインサービスアカウントが追加されたことを確認し、**[次へ]** をクリックします。
1. **[委任するタスク]** セクションで、**[委任するカスタムタスクを作成]** を選択し、**[次へ]** をクリックします。
1. **[Active Directory オブジェクトタイプ]** セクションで:
1. **[フォルダ内の次のオブジェクトのみ]** を選択します。
1. **[コンピュータオブジェクト]** を選択します。
1. **[このフォルダに選択したオブジェクトを作成]** を選択します。
1. **[このフォルダ内の選択したオブジェクトを削除]** を選択し、**[次へ]** をクリックします。
1. **[アクセス許可]** セクションで:
1. **[全般]** を選択したままにします。
1. **[DNS ホスト名への検証済み書き込み]** を選択します。
1. **[サービスプリンシパル名への検証済み書き込み]** を選択し、**[次へ]** をクリックします。
1. Kerberos 認証を有効にするには、**[プロパティ固有]** を選択し、リストから **[書き込み servicePrincipalName]** を選択します。
1. **[コントロールウィザードの委任の完了]** で設定を確認し、**[完了]** をクリックします。
1. Kerberos 認証の場合は、DNS Manager を開き、**[サーバー]** プロパティを開きます。
1. Windows ダイアログボックスで、`dnsmgmt.msc` と入力します。
1. **[セキュリティ]** タブの下に AD ドメインサービスアカウントを追加します。
1. **[読み取り]** アクセス許可を選択し、変更を適用します。
## ステップ 4: AWS KMS キーを作成する
KMS キーは、AWS シークレットの暗号化に使用されます。
**AWS KMS キーを作成するには**
**注記**
**[暗号化キー]** として、AWS デフォルトの KMS キーを使用しないでください。AWS KMS キーは、セルフマネージド AD に参加させる RDS for SQL Server DB インスタンスを含んでいるのと同じ AWS アカウントに作成してください。
1. AWS KMS コンソールで、**[キーの作成]** を選択します。
1. **[キーの種類]** として、**[対称]** を選択します。
1. **[キーの使用方法]** として、**[暗号化と復号化]** を選択します。
1. [**Advanced options (詳細オプション)**] の場合:
1. **[キーマテリアルのオリジン]** として、**[KMS]** を選択します。
1. **[リージョナリティ]** として、**[単一リージョンキー]** を選択し、**[次へ]** をクリックします。
1. **[エイリアス]** に、KMS キーの名前を指定します。
1. (オプション) **[説明]** に、KMS キーの説明を入力します。
1. (オプション) **[タグ]** に、KMS キーのタグを指定し、**[次へ]** をクリックします。
1. **[キー管理者]** として、IAM ユーザーの名前を入力して選択します。
1. **[キーの削除]** で、**[キー管理者にこのキーの削除を許可する]** のボックスをオンのままにして、**[次へ]** をクリックします。
1. **[キーユーザー]** として、前のステップと同じ IAM ユーザーを指定して選択します。**[次へ]** をクリックします。
1. 設定を確認します。
1. **[キーポリシー]** で、以下をポリシー **[ステートメント]** に含めます。
```
{
"Sid": "Allow use of the KMS key on behalf of RDS",
"Effect": "Allow",
"Principal": {
"Service": [
"rds.amazonaws.com"
]
},
"Action": "kms:Decrypt",
"Resource": "*"
}
```
1. [**Finish**] をクリックします。
## ステップ 5: AWS シークレットを作成する
**シークレットを作成する**
**注記**
シークレットは、セルフマネージド AD に参加させる RDS for SQL Server DB インスタンスを含んでいるのと同じ AWS アカウントに作成してください。
1. AWS Secrets Manager で、**[新しいシークレットを保存する]** を選択します。
1. **[Secret type] (シークレットタイプ)** で、**[Other type of secret]** (他の種類のシークレット) を選択します。
1. **[キーと値のペア]** として、次の 2 つのキーを追加します。
1. 最初のキーには、`SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME` と入力します。
1. 最初のキーの値には、AD ユーザーのユーザー名 (ドメインプレフィックスなし) のみを入力します。ドメイン名を含めないでください。含めると、インスタンスの作成が失敗します。
1. 2 番目のキーとして、`SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD` と入力します。
1. 2 番目のキーの値には、ドメインの AD ユーザー用に作成したパスワードを入力します。
1. **[暗号化キー]** として、前のステップで作成した KMS キーを入力し、**[次へ]** をクリックします。
1. **[シークレット名]** として、後でシークレットを見つけやすい、わかりやすい名前を入力します。
1. (オプション) **[説明]** として、シークレット名の説明を入力します。
1. **[リソースアクセス許可]** として、**[編集]** をクリックします。
1. 以下のポリシーをアクセス許可ポリシーに追加します。
**注記**
*Confused Deputy* Problem (混乱した代理の問題) を回避するために、ポリシーの `aws:sourceAccount` および `aws:sourceArn` 条件を使用することをお勧めします。`aws:sourceAccount` の AWS アカウント と `aws:sourceArn` の RDS for SQL Server DB インスタンス ARN を使用します。詳細については、「[サービス間での混乱した代理問題の防止](cross-service-confused-deputy-prevention.md)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Principal":
{
"Service": "rds.amazonaws.com"
},
"Action": "secretsmanager:GetSecretValue",
"Resource": "*",
"Condition":
{
"StringEquals":
{
"aws:sourceAccount": "123456789012"
},
"ArnLike":
{
"aws:sourceArn": "arn:aws:rds:us-west-2:123456789012:db:*"
}
}
}
]
}
```
------
1. **[保存]** をクリックし、**[次へ]** をクリックします。
1. **[ローテーションの設定]** は、デフォルト値のままにして、**[次へ]** を選択します。
1. シークレットの設定を確認し、**[保存]** をクリックします。
1. 作成したシークレットを選択し、**[シークレット ARN]** の値をコピーします。これを次のステップで使用して、セルフマネージド Active Directory をセットアップします。
# DB インスタンスをセルフマネージド Active Directory に結合する
RDS for SQL Server DB インスタンスをセルフマネージド AD に結合するには、次の手順に従います。
## ステップ 1: SQL Server DB インスタンスを作成または変更する
コンソール、CLI、または RDS API を使用して、RDS for SQL Server DB インスタンスをセルフマネージド AD ドメインに関連付けることができます。これは、次のいずれかの方法で行うことができます。
+ コンソール、[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)」を参照してください。
AWS CLI を使用する場合は、DB インスタンスが、作成したセルフマネージド AD ドメインを使用できるように、以下のパラメータが必要です。
+ `--domain-fqdn` パラメータには、セルフマネージド AD の完全修飾ドメイン名 (FQDN) を使用します。
+ `--domain-ou` パラメータには、セルフマネージド AD で作成した OU を使用します。
+ `--domain-auth-secret-arn` パラメータには、前のステップで作成した**[シークレット ARN]** の値を使用します。
+ `--domain-dns-ips` パラメータには、セルフマネージド AD の DNS サーバーのプライマリ IPv4 アドレスとセカンダリ IPv4 アドレスを使用します。セカンダリ DNS サーバーの IP アドレスがない場合は、プライマリ IP アドレスを 2 回入力します。
次の CLI コマンドの例は、セルフマネージド AD ドメインを使用して RDS for SQL Server DB インスタンスを作成、変更、削除する方法を示しています。
**重要**
DB インスタンスを変更してセルフマネージド AD ドメインに参加させたり、削除したりする場合、変更を有効にするには DB インスタンスを再起動する必要があります。変更をすぐに適用するか、次のメンテナンスウィンドウまで待つかを選択できます。**[すぐに適用]** オプションを選択すると、シングル AZ DB インスタンスのダウンタイムが発生します。マルチ AZ DB インスタンスは、再起動を完了する前にフェイルオーバーを実行します。詳細については、「[スケジュール変更設定の使用](USER_ModifyInstance.ApplyImmediately.md)」を参照してください。
次の CLI コマンドは、新しい RDS for SQL Server DB インスタンスを作成し、それをセルフマネージド AD ドメインに参加させます。
Linux、macOS、Unix の場合:
```
aws rds create-db-instance \
--db-instance-identifier my-DB-instance \
--db-instance-class db.m5.xlarge \
--allocated-storage 50 \
--engine sqlserver-se \
--engine-version 15.00.4043.16.v1 \
--license-model license-included \
--master-username my-master-username \
--master-user-password my-master-password \
--domain-fqdn my_AD_domain.my_AD.my_domain \
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
Windows の場合:
```
aws rds create-db-instance ^
--db-instance-identifier my-DB-instance ^
--db-instance-class db.m5.xlarge ^
--allocated-storage 50 ^
--engine sqlserver-se ^
--engine-version 15.00.4043.16.v1 ^
--license-model license-included ^
--master-username my-master-username ^
--master-user-password my-master-password ^
--domain-fqdn my-AD-test.my-AD.mydomain ^
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \ ^
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
次の CLI コマンドは、セルフマネージド AD ドメインを使用するように既存の RDS for SQL Server DB インスタンスを変更します。
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier my-DB-instance \
--domain-fqdn my_AD_domain.my_AD.my_domain \
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier my-DBinstance ^
--domain-fqdn my_AD_domain.my_AD.my_domain ^
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" ^
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
次の CLI コマンドは、セルフマネージド AD ドメインから RDS for SQL Server DB インスタンスを削除します。
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier my-DB-instance \
--disable-domain
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier my-DB-instance ^
--disable-domain
```
## ステップ 2: Kerberos または NTLM 認証の使用
### NTLM 認証
各 Amazon RDS DB インスタンスにはエンドポイントがあり、各エンドポイントには DB インスタンスの DNS 名とポート番号があります。SQL クライアントアプリケーションを使用して DB インスタンスに接続するには、DB インスタンスの DNS 名とポート番号が必要です。NTLM 認証を使用して認証するには、マルチ AZ 配置を使用している場合、RDS エンドポイントまたはリスナーエンドポイントに接続する必要があります。
計画されたデータベースメンテナンス時や計画外のサービス中断時に、Amazon RDS は自動的に最新のセカンダリデータベースにフェイルオーバーするため、オペレーションは手動の介入なしで速やかに再開できます。プライマリインスタンスおよびセカンダリインスタンスは、同じエンドポイントを使用し、エンドポイントの物理ネットワークアドレスは、フェイルオーバープロセスの一環としてセカンダリに移行します。フェイルオーバーが発生した場合、アプリケーションを再構成する必要はありません。
### Kerberos 認証
RDS for SQL Server の Kerberos ベースの認証では、特定のサービスプリンシパル名 (SPN) に接続する必要があります。ただし、フェイルオーバーイベント後、アプリケーションは新しい SPN を認識しない場合があります。これに対処するために、RDS 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**、および **[アカウントとリージョン固有のハッシュ]** をナビゲートします。
![\[DB インスタンスのストレージ量の変更\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/kerb-endpoint-selfManagedAD-RDSMS.png)
リモートクライアントから CNAME を接続した後に NTLM 接続が返された場合は、必要なポートが許可リストに登録されているかどうかを確認します。
接続で Kerberos を使用しているかどうかを確認するには、次のクエリを実行します。
```
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SSPID;
```
Kerberos エンドポイントに接続するときにインスタンスが NTLM 接続を返す場合は、ネットワーク設定とユーザー設定を確認します。「[ネットワーク接続の設定](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig)」を参照してください。
## ステップ 3: Windows 認証の SQL Server ログインを作成する
Amazon RDS マスターユーザーの認証情報を使用して、他の DB インスタンスと同じように SQL Server DB インスタンスに接続します。DB インスタンスはセルフマネージド AD ドメインに参加しているため、SQL Server のログインとユーザーをプロビジョニングできます。これは、セルフマネージド AD ドメインの AD ユーザーとグループユーティリティから行います。データベースへのアクセス許可は、これらの Windows ログインに付与され無効化されている標準の SQL サーバーのアクセス許可によって管理されています。
セルフマネージド AD ドメインサービスアカウントが SQL Server に認証するには、セルフマネージド AD ドメインサービスアカウント、またはそのユーザーが属するセルフマネージド AD グループに、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 ログインを作成できます。
**注記**
`my_AD_domain\my_AD_domain_user` の形式で Windows 2000 以前のログイン名を使用して、ユーザーまたはグループを指定します。ユーザープリンシパル名 (UPN) を *`my_AD_domain_user`* `@` *`my_AD_domain`* の形式で使用することはできません。
```
USE [master]
GO
CREATE LOGIN [my_AD_domain\my_AD_domain_user] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english];
GO
```
詳細については、Microsoft Developer Network ドキュメントの「[ログインの作成 (Transact-SQL)](https://msdn.microsoft.com/en-us/library/ms189751.aspx)」を参照してください。
ドメインのユーザー (人およびアプリケーション) は、Windows 認証を使用して、セルフマネージド AD ドメインに参加したクライアントマシンから RDS for SQL Server インスタンスに接続できるようになりました。
# セルフマネージド Active Directory ドメイン内の DB インスタンスの管理
コンソール、AWS CLI、または Amazon RDS API を使用して、DB インスタンスおよびセルフマネージド AD ドメインとの関係を管理できます。例えば、DB インスタンスをドメイン内、ドメイン外、またはドメイン間で移動させることができます。
例えば、Amazon RDS API を使用して次を実行できます。
+ メンバーシップが失敗したためにセルフマネージドドメインへの参加を再試行するには、[ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API オペレーションを使用して、同じパラメータセットを指定します。
+ `--domain-fqdn`
+ `--domain-dns-ips`
+ `--domain-ou`
+ `--domain-auth-secret-arn`
+ セルフマネージドドメインから DB インスタンスを削除するには、`ModifyDBInstance` API オペレーションを使用し、ドメインパラメータとして `--disable-domain` を指定します。
+ DB インスタンスを別のセルフマネージドドメインに移動するには、`ModifyDBInstance` API オペレーションを使用し、新しいドメインのドメインパラメータを指定します。
+ `--domain-fqdn`
+ `--domain-dns-ips`
+ `--domain-ou`
+ `--domain-auth-secret-arn`
+ 各 DB インスタンスのセルフマネージド AD ドメインメンバーシップを一覧表示するには、[DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html) API オペレーションを使用します。
## セルフマネージド Active Directory ドメインメンバーシップについて
AD の詳細を指定しながら DB インスタンスを作成または変更した後、そのインスタンスはセルフマネージド AD ドメインのメンバーになります。AWS コンソールは、DB インスタンスについて、セルフマネージド Active Directory ドメインメンバーシップのステータスを示します。DB インスタンスのステータスは、以下のいずれかです。
+ **joined** – インスタンスは AD ドメインのメンバーです。
+ **Joining** – インスタンスは、AD ドメインのメンバーになる途中です。
+ **pending-join (参加保留中)** – インスタンスのメンバーシップは保留中です。
+ **pending-maintenance-join** – AWS は、次に予定されているメンテナンスウィンドウ中に、インスタンスを AD ドメインのメンバーにできるよう試みます。
+ **pending-removal** – AD ドメインからのインスタンスの削除は保留中です。
+ **pending-maintenance-removal** – AWS は、次に予定されているメンテナンスウィンドウ中に、AD ドメインからのインスタンスの削除を試みます。
+ **failed** – 設定の問題により、インスタンスは AD ドメインに参加できませんでした。インスタンスの変更コマンドを再発行する前に、設定を確認して修正してください。
+ **removing** – インスタンスをセルフマネージド AD ドメインから削除しています。
**重要**
セルフマネージド AD ドメインのメンバーになるリクエストは、ネットワーク接続の問題が原因で失敗する場合があります。例えば、DB インスタンスを作成したか、既存のインスタンスを変更したが、DB インスタンスをセルフマネージド AD ドメインのメンバーにする試みが失敗することがあります。この場合、コマンドを再発行して DB インスタンスを作成または変更するか、新しく作成されたインスタンスを変更して、セルフマネージド AD ドメインに参加させます。
# セルフマネージド Active Directory のトラブルシューティング
セルフマネージド AD をセットアップまたは変更する際に発生する可能性のある問題は次のとおりです。
****
| エラーコード | 説明 | 一般的な原因 | トラブルシューティングの推奨事項 |
| --- | --- | --- | --- |
| エラー 2 / 0x2 | 指定されたファイルがシステムで見つかりません。 | `—domain-ou` パラメータで指定された組織単位 (OU) の形式または場所が無効です。AWS Secrets Manager で指定されたドメインサービスアカウントには、OU への参加に必要なアクセス許可がありません。 | `—domain-ou` パラメータを確認してください。ドメインサービスアカウントに OU に対する適切なアクセス許可があることを確認してください。詳細については、「[AD ドメインサービスアカウントの設定](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig)」を参照してください。 |
| エラー 5 / 0x5 | アクセスが拒否されました。 | ドメインサービスアカウントのアクセス許可が正しく設定されていないか、コンピュータアカウントがドメインに既に存在しています。 | ドメイン内のドメインサービスアカウントのアクセス許可を確認し、RDS コンピュータアカウントがドメイン内で重複していないことを確認します。RDS コンピュータアカウントの名前は、RDS for SQL Server DB インスタンスで `SELECT @@SERVERNAME` を実行することで確認できます。マルチ AZ を使用している場合は、フェイルオーバーを使用して再起動し、RDS コンピュータアカウントを再度確認してください。詳細については、「[ DB インスタンスの再起動](USER_RebootInstance.md)」を参照してください。 |
| エラー 87 / 0x57 | パラメータが間違っています。 | AWS Secrets Manager で指定されたドメインサービスアカウントには、適切なアクセス許可がありません。ユーザープロファイルが壊れている可能性もあります。 | ドメインサービスアカウントの要件を確認します。詳細については、「[AD ドメインサービスアカウントの設定](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig)」を参照してください。 |
| エラー 234 / 0xEA | 指定された組織単位 (OU) は存在しません。 | `—domain-ou` パラメータで指定された OU は、セルフマネージド AD に存在しません。 | `—domain-ou` パラメータを確認して、指定した OU がセルフマネージド AD に存在することを確認します。 |
| エラー 1326 / 0x52E | ユーザー名またはパスワードが正しくありません。 | AWS Secrets Manager で指定されたドメインサービスアカウントの認証情報に、不明なユーザー名または不正なパスワードが含まれています。セルフマネージド AD でドメインアカウントが無効になっている場合もあります。 | AWS Secrets Manager で指定した認証情報が正しく、ドメインアカウントがセルフマネージド AD で有効になっていることを確認します。 |
| エラー 1355 / 0x54B | 指定されたドメインが存在しないか、接続できませんでした。 | ドメインがダウンしているか、指定された DNS IP セットにアクセスできないか、指定された FQDN にアクセスできません。 | `—domain-dns-ips` および `—domain-fqdn` パラメータが正しいことを確認します。RDS for SQL Server DB インスタンスのネットワーク構成を確認し、セルフマネージド AD にアクセスできることを確認します。詳細については、「[ネットワーク接続の設定](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig)」を参照してください。 |
| エラー 1772 / 0x6BA | RPC サーバーは使用できません。 | AD ドメインの RPC サービスへのアクセスに問題がありました。これはサービスまたはネットワークの問題かもしれません。 | RPC サービスがドメインコントローラーで実行されていることと、RDS for SQL Server DB インスタンスから TCP ポート `135` および `49152-65535` にアクセスできることを確認します。 |
| エラー 1727 / 0x6BF | リモートプロシージャ呼び出しが失敗し、実行されませんでした。 | ネットワーク接続の問題またはファイアウォールの制限により、ドメインコントローラーへの RPC 通信がブロックされます。 | クロス VPC ドメイン結合を使用する場合は、クロス VPC 通信が VPC ピアリングまたは Transit Gateway のいずれかで正しく設定されていることを確認します。RDS for SQL Server DB インスタンスからドメインで TCP ハイポート `49152-65535` にアクセスできることを確認します。これには、ファイアウォールの潜在的な制限も含まれます。 |
| エラー 2224 / 0x8B0 | ユーザーアカウントは既に存在しています。 | セルフマネージド AD に追加しようとしているコンピュータアカウントはすでに存在しています。 | RDS for SQL Server DB インスタンスで `SELECT @@SERVERNAME` を実行してコンピュータアカウントを特定し、セルフマネージド AD から慎重に削除します。 |
| エラー 2242 / 0x8c2 | このユーザーのパスワードは有効期限が切れています。 | AWS Secrets Manager で指定されたドメインサービスアカウントのパスワードは有効期限が切れています。 | RDS for SQL Server DB インスタンスをセルフマネージド AD に参加させるために使用するドメインサービスアカウントのパスワードを更新します。 |
DB インスタンスをセルフマネージド Active Directory ドメインに結合すると、ドメインの状態に関連する RDS イベントが表示される場合があります。
```
Unhealthy domain state detected while attempt to verify or
configure your Kerberos endpoint in your domain on
node node_n. message
```
マルチ AZ インスタンスの場合、node1 と node2 の両方でエラーレポートが表示されることがあります。これは、インスタンスの Kerberos 設定がフェイルオーバーする準備ができていないことを示します。フェイルオーバーが発生した場合、Kerberos を使用した認証で問題が発生する可能性があります。設定の問題を解決して、Kerberos のセットアップが有効で最新の状態であることを確認します。マルチ AZ インスタンスの場合、すべてのネットワークとアクセス許可の設定が整っているため、新しいプライマリホストで Kerberos 認証を使用するためのアクションは必要ありません。
シングル AZ インスタンスの場合、node1 はプライマリノードです。Kerberos 認証が期待どおりに動作しない場合は、インスタンスイベントを確認し、設定の問題を解決して、Kerberos 設定が有効で最新の状態であることを確認します。
## SQL Server DB インスタンスを復元してからセルフマネージド Active Directory ドメインに追加する
SQL Server DB インスタンスの DB スナップショットまたはポイントインタイムリカバリ (PITR) を復元して、セルフマネージド Active Directory ドメインに追加できます。DB インスタンスが復元されたら、「[ステップ 1: SQL Server DB インスタンスを作成または変更する](USER_SQLServer_SelfManagedActiveDirectory.Joining.md#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateModify)」で説明している手順に従ってインスタンスを変更し、DB インスタンスをセルフマネージド AD ドメインに追加します。
# RDS for SQL Server による AWS Managed Active Directory の操作
ユーザーが RDS for SQL Server DB インスタンスに接続する際、AWS Managed Microsoft AD を使用して Windows 認証でユーザーを認証できます。DB インスタンスは、Windows 認証を有効にするために AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD とも呼ばれます) を使用します。ユーザーが、信頼性の高いドメインに接続された SQL Server DB インスタンスを使用して認証を実行すると、Directory Service を使用して作成したドメインディレクトリに認証リクエストが転送されます。
## リージョンとバージョンの可用性
Amazon RDS では、Windows Authentication 向けに AWS Managed Microsoft AD のみの使用をサポートしています。RDS は AD Connector の使用をサポートしていません。詳細については次を参照してください:
+ [ のアプリケーションの互換性ポリシーAWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_app_compatibility.html)
+ [AD Connector のアプリケーションの互換性ポリシー](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_app_compatibility.html)
バージョンおよびリージョンの可用性の詳細については、「[RDS for SQL Server を使用したKerberos 認証](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.html#Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.sq)」を参照してください。
## Windows 認証のセットアップの概要
Amazon RDS は Windows 認証にミックスモードを使用します。この方法では、*マスターユーザー* (SQL Server DB インスタンスの作成に使用された名前とパスワード) が SQL 認証を使用します。マスターユーザーアカウントは特権を持つ認証情報のため、このアカウントへのアクセスを制限する必要があります。
オンプレミスまたはセルフホスト型の Microsoft Active Directory を使用して Windows 認証を取得するには、フォレストの信頼関係を確立します。信頼は、一方向または双方向にすることができます。Directory Service を使用してフォレストの信頼関係を設定する方法の詳細については、*AWS Directory Service 管理ガイド*の「[信頼関係を作成する場合](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_setup_trust.html)」を参照してください。
SQL Server DB インスタンスの Windows 認証を設定するには、次のステップに従います。詳細については、「[SQL Server DB インスタンスの Windows 認証のセットアップ](USER_SQLServerWinAuth.SettingUp.md)」を参照してください。
1. AWS Managed Microsoft AD または AWS マネジメントコンソール API のいずれかから Directory Service を使用して、AWS Managed Microsoft AD ディレクトリを作成します。
1. AWS CLI または Amazon RDS API を使用してSQL Server DB インスタンスを作成する場合は、AWS Identity and Access Management (IAM) ロールを作成します。このロールはマネージド IAM ポリシー `AmazonRDSDirectoryServiceAccess` を使用し、Amazon RDS によるディレクトリへの呼び出しを許可します。SQL Server DB インスタンスの作成にコンソールを使用している場合、AWS は IAM ロールを作成します。
ロールによるアクセスを許可するには、AWS Security Token Service (AWS STS) エンドポイントを AWS アカウントの AWS リージョンでアクティベートする必要があります。AWS STS エンドポイントはすべての AWS リージョンでデフォルトでアクティブになっているため、他のアクションを実行することなくエンドポイントを使用することができます。詳細については、*IAM ユーザーガイド*の 「[AWS リージョン での AWS STS の管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)」を参照してください。
1. Microsoft Active Directory のツールを使用して、AWS Managed Microsoft AD ディレクトリでユーザーとグループを作成して設定します。Active Directory にユーザーおよびグループを作成する方法の詳細については、*AWS Directory Service 管理ガイド*の「[AWS Managed Microsoft AD でユーザーとグループを管理する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html)」を参照してください。
1. ディレクトリと DB インスタンスを異なる VPC に配置する場合は、クロス VPC トラフィックを有効にします。
1. Amazon RDS を使用して、コンソール、AWS CLI、または Amazon RDS API のいずれかから、新しい SQL Server DB インスタンスを作成します。作成リクエストで、ディレクトリの作成時に生成されたドメイン識別子 (「`d-*`」識別子) と、作成したロールの名称を指定します。DB インスタンスのドメインおよび IAM ロールパラメータを設定して、既存の SQL Server DB インスタンスを Windows 認証を使用するように変更することもできます。
1. Amazon RDS マスターユーザーの認証情報を使用して、他の DB インスタンスと同じように SQL Server DB インスタンスに接続します。DB インスタンスは AWS Managed Microsoft AD ドメインに参加しているため、ドメイン内の Active Directory ユーザーとグループから SQL Server のログインとユーザーをプロビジョニングできます (これらは、SQL Server の「Windows」ログインとして知られています)。データベースへのアクセス許可は、これらの Windows ログインに付与され無効化されている標準の SQL サーバーのアクセス許可によって管理されています。
Amazon RDS コンソールを使用してドメイン接続された RDS for SQL Server DB インスタンスを作成すると、AWS は自動的に `rds-directoryservice-access-role` IAM ロールを作成します。このロールは、ドメイン接続されたインスタンスを管理するために不可欠であり、以下の操作に必要です。
+ ドメイン接続された SQL Server インスタンスの設定変更
+ Active Directory 統合設定の管理
+ ドメイン結合インスタンスでのメンテナンス操作の実行
**重要**
`rds-directoryservice-access-role` IAM ロールを削除すると、Amazon RDS コンソールまたは API を使用してドメイン接続された SQL Server インスタンスを変更することはできません。インスタンスを変更しようとすると、次のエラーメッセージが表示されます。You don't have permission to iam:CreateRole. To request access, copy the following text and send it to your AWS administrator.
このエラーは、Amazon RDS がドメイン接続を管理するためにロールを再作成する必要があるが、必要なアクセス許可がないために発生します。さらに、このエラーは CloudTrail に記録されないため、トラブルシューティングがより困難になる可能性があります。
誤って `rds-directoryservice-access-role` を削除した場合、ドメインに接続された SQL Server インスタンスに変更を加える前に、再作成するための `iam:CreateRole` アクセス許可が必要です。ロールを手動で再作成するには、ロールに `AmazonRDSDirectoryServiceAccess` 管理ポリシーがアタッチされ、RDS サービスがロールを引き受けることを許可する適切な信頼関係があることを確認します。
# Kerberos 認証のエンドポイントの作成
Kerberos に基づく認証では、エンドポイントは「お客様が指定したホスト名、ピリオド、省略なしのドメイン名 (FQDN)」の形式である必要があります。次の例は、Kerberos に基づく認証で使用できるエンドポイントの例です。この例では、SQL Server DB インスタンスのホスト名は `ad-test`、ドメイン名は `corp-ad.company.com` です。
```
ad-test.corp-ad.company.com
```
接続で Kerberos が使用されていることを確認するには、次のクエリを実行します。
```
1. SELECT net_transport, auth_scheme
2. FROM sys.dm_exec_connections
3. WHERE session_id = @@SPID;
```
# SQL Server DB インスタンスの Windows 認証のセットアップ
SQL Server DB インスタンスの Windows 認証をセットアップするには、AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD とも呼ばれます) を使用します。Windows 認証を設定するには、次の手順を実行します。
## ステップ 1: AWS Directory Service for Microsoft Active Directory を使用してディレクトリを作成する
Directory Service は完全マネージド型の Microsoft Active Directory を AWS クラウドに作成します。AWS Managed Microsoft AD ディレクトリを作成すると、Directory Service がユーザーに代わって 2 つのドメインコントローラーと 2 つのドメインネームサービス (DNS) サーバーを作成します。ディレクトリサーバーは、 VPC 内の 2 つの異なるアベイラビリティーゾーンの 2 つのサブネットで作成されています。この冗長性により、障害が発生してもディレクトリがアクセスできるようになります。
AWS Managed Microsoft AD ディレクトリを作成すると、Directory Service がユーザーに代わって自動的に以下のタスクを実行します。
+ VPC 内に Microsoft Active Directory を設定します。
+ 「Admin」のユーザー名と指定されたパスワードを使用して、ディレクトリ管理者アカウントを作成します。このアカウントはディレクトリの管理に使用します。
+ ディレクトリコントローラー用のセキュリティグループを作成する。
AWS Directory Service for Microsoft Active Directory を立ち上げると、AWS は組織単位 (OU) を作成します。OU にはディレクトリのオブジェクトがすべて含まれています。この OU はドメインルートにあります。OU にはディレクトリを作成する際に入力した NetBIOS 名があります。ドメインルートは AWS が所有し、管理します。
AWS Managed Microsoft AD ディレクトリに作成された*管理者*アカウントには、次のような、OU で最も一般的な管理業務用のアクセス権限があります。
+ ユーザー、グループ、およびコンピュータを作成、更新、または削除する
+ ファイルやプリントサーバーなどのドメインにリソースを追加して、追加したリソースへのアクセス許可を OU のユーザーとグループに割り当てる。
+ 追加の OU やコンテナを作成する。
+ 権限を委譲する。
+ グループポリシーを作成し、リンクする。
+ 削除されたオブジェクトを Active Directory のごみ箱から元に戻す。
+ Active Directory Web Service で AD と DNS Windows PowerShell モジュールを実行する。
管理者アカウントには、ドメイン全体に関係するアクティビティを実行する権限もあります。
+ DNS 設定 (レコード、ゾーン、フォワーダーの追加、削除、または更新) を管理する。
+ DNS イベントログを参照する。
+ セキュリティイベントログを参照する。
**AWS Managed Microsoft AD でディレクトリを作成するには**
1. [Directory Service コンソール](https://console.aws.amazon.com/directoryservicev2/)のナビゲーションペインで、[**ディレクトリ**]、[**ディレクトリの設定**] の順に選択します。
1. を選択します。。**AWS Managed Microsoft AD**これは Amazon RDS 用に現在サポートされている唯一のオプションです。
1. [**Next (次へ)**] を選択します。
1. [**ディレクトリ情報の入力**] ページに、以下の情報を指定します。
**エディション**
目的の要件を満たすエディションを選択します。
**ディレクトリの DNS 名**
ディレクトリの完全修飾名。例: `corp.example.com`。47 文字を超える名前は SQL Server でサポートされていません。
**ディレクトリの NetBIOS 名**
ディレクトリの短縮名 (例: `CORP`)。
**ディレクトリの説明**
必要に応じて、ディレクトリの説明。
**Admin パスワード**
ディレクトリ管理者のパスワードです。ディレクトリの作成プロセスでは、ユーザー名「Admin」とこのパスワードを使用して管理者アカウントが作成されます。
ディレクトリ管理者のパスワードに「`admin`」の単語を含めることはできません。パスワードは大文字と小文字を区別し、8–64 文字にします。また、以下の 4 つのカテゴリうち 3 つから少なくとも 1 文字を含める必要があります。
+ 小文字 (a〜z)
+ 大文字 A〜Z
+ 数字 (0〜9)
+ アルファベットと数字以外の文字 (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/)
**パスワードを確認**
管理者のパスワードをもう一度入力します。
1. [**Next (次へ)**] を選択します。
1. [**VPC とサブネットの選択**] ページで、以下の情報を指定します。
**VPC**
ディレクトリ用の VPC を選択します。
ディレクトリと DB インスタンスは異なる VPC に配置できますが、その場合、必ずクロス VPC トラフィックを有効にしてください。詳細については、「[ステップ 4: ディレクトリと DB インスタンス間のクロス VPC トラフィックを有効にする](#USER_SQLServerWinAuth.SettingUp.VPC-Peering)」を参照してください。
**Subnets**
ディレクトリサーバーのサブネットを選択します。2 つのサブネットは、異なるアベイラビリティーゾーンに存在している必要があります。
1. [**Next (次へ)**] を選択します。
1. ディレクトリの情報を確認します。変更が必要な場合は、[**Previous**] を選択します。情報が正しい場合は、[**Create directory (ディレクトリの作成)**] を選択します。
![\[「確認と作成」ページ\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/WinAuth2.png)
ディレクトリが作成されるまで、数分かかります。正常に作成されると、[**Status**] 値が [**Active**] に変わります。
ディレクトリに関する情報を表示するには、ディレクトリの一覧で、そのディレクトリを選択します。**ディレクトリ ID** を書き留めます。この値は、SQL Server DB インスタンスを作成または変更するときに必要になります。
![\[ディレクトリの詳細ページ\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/WinAuth3.png)
## ステップ 2: Amazon RDS 用の IAM ロールを作成する
コンソールを使用して SQL Server DB インスタンスを作成する場合、このステップをスキップできます。SQL Server DB インスタンスの作成に CLI または RDS API を使用する場合、`AmazonRDSDirectoryServiceAccess` マネージド IAM ポリシーを使用する IAM ロールを作成する必要があります。このロールを使用すると、Amazon RDS で Directory Service への呼び出しを行うことができます。
AWS 管理 `AmazonRDSDirectoryServiceAccess` ポリシーではなく、ドメインを結合するためのカスタムポリシーを使用する場合は、`ds:GetAuthorizedApplicationDetails` アクションを許可する必要があります。Directory Service API の変更により、この要件は、2019 年 7 月から有効となります。
次の IAM ポリシー `AmazonRDSDirectoryServiceAccess` は、Directory Service へのアクセスを提供します。
**Example Directory Service へのアクセスを提供する IAM ポリシー**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ds:DescribeDirectories",
"ds:AuthorizeApplication",
"ds:UnauthorizeApplication",
"ds:GetAuthorizedApplicationDetails"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
リソースベースの信頼関係では [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) および [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) のグローバル条件コンテキストキーを使用して、サービスに付与する特定のリソースへのアクセス許可を制限することをお勧めします。これは、[混乱した使節の問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)に対する最も効果的な保護方法です。
両方のグローバル条件コンテキストキーを使用し、`aws:SourceArn` 値にアカウント ID を含めます。この場合は、`aws:SourceAccount` 値と `aws:SourceArn` 値のアカウントは、同じステートメントで使用する場合、同じアカウント ID を使用する必要があります。
+ 単一リソースに対するクロスサービスアクセスが必要な場合は `aws:SourceArn` を使用します。
+ そのアカウント内の任意のリソースをクロスサービス使用に関連付けることを許可する場合、`aws:SourceAccount`を使用します。
信頼関係では、`aws:SourceArn` グローバル条件コンテキストキーに、必ず、ロールにアクセスするリソースの完全な Amazon リソースネーム (ARN) を使用します。Windows 認証の場合、次の例に示すように DB インスタンスを含めてください。
**Example Windows 認証のグローバル条件コンテキストキーとの信頼関係**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceArn": [
"arn:aws:rds:Region:my_account_ID:db:db_instance_identifier"
]
}
}
}
]
}
```
この IAM ポリシーと信頼関係を使用して IAM ロールを作成します。IAM ロールの作成の詳細については、*IAM ユーザーガイド*の「[カスタマー管理ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html#create-managed-policy-console)」を参照してください。
## ステップ 3: ユーザーとグループを作成して設定する
Active Directory ユーザーとコンピューターツールを使用して、ユーザーとグループを作成できます。このツールは、Active Directory Domain Services ツールおよび Active Directory Lightweight Directory Services ツールの 1 つです。ユーザーは、ディレクトリにアクセスできる個別の人またはエンティティを表します。グループは、個別のユーザーごとに権限を付与するのではなく、ユーザーのグループに権限を付与または拒否するために非常に便利です。
Directory Service ディレクトリにユーザーとグループを作成するには、Directory Service ディレクトリのメンバーである Windows EC2 インスタンスに接続する必要があります。また、ユーザーとグループを作成する権限を持つユーザーとしてログインしている必要があります。詳細については、*AWS Directory Service 管理ガイド*の「[ユーザーとグループを追加する (Simple AD および AWS Managed Microsoft AD)](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/creating_ad_users_and_groups.html)」を参照してください。
## ステップ 4: ディレクトリと DB インスタンス間のクロス VPC トラフィックを有効にする
同じ VPC 内にディレクトリおよび DB インスタンスを配置する場合は、このステップをスキップして [ステップ 5: SQL Server DB インスタンスを作成または変更する](#USER_SQLServerWinAuth.SettingUp.CreateModify) に進みます。
ディレクトリと DB インスタンスを別の VPC に配置する場合は、VPC ピア接続または [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) を使用してクロス VPC トラフィックを設定します。
次の手順では、VPC ピア接続を使用して VPC 間のトラフィックを有効にします。*Amazon Virtual Private Cloud ピアリング接続ガイド*の「[VPC ピア機能とは](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html)」の手順に従います。
**VPC ピア接続を使用してクロス VPC トラフィックを有効にするには**
1. 適切な VPC ルーティングを設定し、ネットワークトラフィックが双方向にフローするようにします。
1. DB インスタンスのセキュリティグループが、ディレクトリのセキュリティグループからのインバウンドトラフィックを受信できることを確認します。
1. トラフィックをブロックするネットワークのアクセスコントロールリスト (ACL) ルールがないことを確認します。
別の AWS アカウントがディレクトリを所有している場合は、ディレクトリを共有する必要があります。
**AWS アカウント間でディレクトリを共有するには**
1. DB インスタンスを作成する AWS アカウントとの間でディレクトリの共有を開始するには、*AWS Managed Microsoft AD 管理ガイド*の「[チュートリアル: Directory Service ディレクトリを共有して、シームレスに EC2 ドメインを結合する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html)」の手順を実行します。
1. DB インスタンスのアカウントを使用して、Directory Service コンソールにサインインし、続行する前にドメインが必ず `SHARED` ステータスであることを確認します。
1. DB インスタンスのアカウントを使用して Directory Service コンソールにサインインしている間に、[**ディレクトリ ID**] の値を書き留めておきます。このディレクトリ ID は、DB インスタンスをドメインに結合するために使用します。
## ステップ 5: SQL Server DB インスタンスを作成または変更する
ディレクトリで使用する 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)」を参照してください。
Windows 認証は、VPC 内の SQL Server DB インスタンスにのみサポートされています。
DB インスタンスが、作成したドメインディレクトリを使用できるようにするには、次が必要です。
+ [**ディレクトリ**] では、ディレクトリの作成時に生成されたドメイン識別子 (`d-ID`) を選択する必要があります。
+ VPC セキュリティグループに、ディレクトリとの通信を DB インスタンスに許可するアウトバウンドルールがあることを確認します。
![\[Microsoft SQL Server の Windows 認証ディレクトリ\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/WinAuth1.png)
AWS CLI を使用する場合は、DB インスタンスが、作成したディレクトリを使用できるように、以下のパラメータが必要です。
+ `--domain` パラメータには、ディレクトリの作成時に生成されたドメイン識別子 (`d-ID`) を使用します。
+ `--domain-iam-role-name` パラメータには、マネージド IAM ポリシー `AmazonRDSDirectoryServiceAccess` を使用する作成済みのロールを使用します。
例えば、以下の CLI コマンドはディレクトリを使用するように DB インスタンスを変更します。
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--domain d-ID \
--domain-iam-role-name role-name
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--domain d-ID ^
--domain-iam-role-name role-name
```
**重要**
Kerberos 認証を有効化するために DB インスタンスを変更する場合、変更後 DB インスタンスを再起動します。
## ステップ 6: Windows 認証の SQL Server ログインを作成する
Amazon RDS マスターユーザーの認証情報を使用して、他の DB インスタンスと同じように SQL Server DB インスタンスに接続します。DB インスタンスは AWS Managed Microsoft AD ドメインに参加しているため、SQL Server のログインとユーザーをプロビジョニングできます。これは、ドメイン内の Active Directory のユーザーとグループから行われます。データベースへのアクセス許可は、これらの Windows ログインに付与され無効化されている標準の SQL サーバーのアクセス許可によって管理されています。
Active Directory のユーザーが SQL Server で認証するには、ユーザー、またはそのユーザーがメンバーとして含まれているグループに、SQL Server の Windows ログインが存在する必要があります。これらの SQL Server ログインでアクセスを許可したり取り消したりして、細分化されたアクセスコントロールを処理します。SQL Server ログインを持たないユーザー、またはそのようなログインを持つグループに属さないユーザーは、SQL Server DB インスタンスにアクセスできません。
Active Directory の SQL Server ログインを作成するには、ALTER ANY LOGIN 許可が必要です。このアクセス許可を持つログインをまだ作成していない場合は、SQL Server 認証を使用して DB インスタンスのマスターユーザーとして接続します。
次の例のようなデータ定義言語 (DDL) コマンドを実行して、Active Directory ユーザーまたはグループへの SQL Server ログインを作成します。
**注記**
`domainName\login_name` の形式で Windows 2000 以前のログイン名を使用して、ユーザーまたはグループを指定します。ユーザープリンシパル名 (UPN) を *`login_name`* `@` *`DomainName`* の形式で使用することはできません。
T-SQL ステートメントを使用することによってのみ、RDS for SQL Server インスタンスで Windows 認証ログインを作成することができます。SQL Server Management Studio を使用して Windows 認証ログインを作成することはできません。
```
USE [master]
GO
CREATE LOGIN [mydomain\myuser] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english];
GO
```
詳細については、Microsoft Developer Network ドキュメントの「[ログインの作成 (Transact-SQL)](https://msdn.microsoft.com/en-us/library/ms189751.aspx)」を参照してください。
ドメインのユーザー (人およびアプリケーション) が Windows 認証を使用して、クライアントマシンを結合したドメインから RDS for SQL Server インスタンスに接続できるようになりました。
# ドメインの 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 オペレーションを使用します。
## ドメインのメンバーシップを理解する
DB インスタンスを作成または変更した後、そのインスタンスは、ドメインのメンバーになります。AWS コンソールは、DB インスタンスのドメインメンバーシップのステータスを示します。DB インスタンスのステータスは、以下のいずれかです。
+ **joined (参加済み)** – インスタンスはドメインのメンバーになっています。
+ **joining (参加中)** – インスタンスは、ドメインのメンバーになる途中です。
+ **pending-join (参加保留中)** – インスタンスのメンバーシップは保留中です。
+ **メンテナンスまで参加保留中** – 次に予定されているメンテナンスウィンドウ中に、AWS がインスタンスをドメインのメンバーにできるよう試みます。
+ **pending-removal (削除保留中)** – ドメインからのインスタンス削除は保留中です。
+ **メンテナンスまで削除保留中** – 次に予定されているメンテナンスウィンドウ中に、AWS がドメインからのインスタンスの削除を試みます。
+ **failed (失敗)** – 設定の問題により、インスタンスはドメインに参加できませんでした。インスタンスの変更コマンドを再発行する前に、設定を確認して修正してください。
+ **removing (削除中)** – インスタンスをドメインから削除しています。
ドメインのメンバーになるリクエストは、ネットワーク接続の問題や正しくない IAM ロールが原因で失敗する場合があります。例えば、DB インスタンスを作成した、または既存のインスタンスを変更したが、DB インスタンスをドメインに参加させられない場合があります。この場合、コマンドを再発行して DB インスタンスを作成または変更するか、新しく作成されたインスタンスを変更してドメインに参加させます。
# Windows 認証を使用して SQL Server に接続する
Windows 認証を使用して SQL Server に接続するには、ドメインのユーザーとしてドメイン結合されたコンピュータにログインしている必要があります。SQL Server Management Studio の起動後、認証タイプとして **Windows 認証**を選択します (以下参照)。
![\[Windows 認証を使用して SQL Server に接続\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/WinAuth4.png)
## SQL Server DB インスタンスを復元してドメインに追加する
SQL Server DB インスタンスの DB スナップショットまたはポイントインタイムリカバリ (PITR) を復元し、ドメインに追加できます。DB インスタンスが復元されたら、「[ステップ 5: SQL Server DB インスタンスを作成または変更する](USER_SQLServerWinAuth.SettingUp.md#USER_SQLServerWinAuth.SettingUp.CreateModify)」で説明している手順に従ってインスタンスを変更し、DB インスタンスをドメインに追加します。