Amazon RDS for Db2 でセルフマネージド AD の Kerberos 認証を有効にする

本記事は 2026 年 6 月 30 日 に公開された「Enable self-managed AD Kerberos authentication with Amazon RDS for Db2」を翻訳したものです。

Amazon Relational Database Service (Amazon RDS) for Db2 は、AWS、オンプレミス、他のクラウドのいずれで稼働している場合でも、お客様自身の Active Directory ドメインを利用した Kerberos 認証をサポートしています。Amazon RDS for Db2 をお客様が管理する Microsoft Active Directory に直接接続することで、データベースユーザーの認証を一元化し、シングルサインオンを実現できます。この構成の要となるのは、正確に絞り込んだ一連の AD 権限を専用のサービスアカウントに委任し、その認証情報を RDS へ安全に受け渡すことです。

本記事では、Amazon RDS for Db2 向けに Windows Active Directory を Kerberos 認証で構成する方法と、ドメイン参加済みのクライアントから構成を検証する方法を紹介します。aws-samples/sample-rds-db2-tools リポジトリで公開されている一連の手順を、最初から最後まで順を追って説明します。

• 専用の OU とサービスアカウントを作成する。
• Amazon RDS for Db2 が AD と連携するために必要な AD 権限を委任する。
• 認証情報を AWS Key Management Service (AWS KMS) で暗号化したシークレットとして AWS Secrets Manager に保存する。
• 生の GUID を人間が読める権限名に変換する PowerShell スクリプトで構成を検証する。

続いて、ドメイン参加済みの Db2 クライアントから構成を検証する方法を紹介します。

• EC2 インスタンスを起動する。
• インスタンスをドメインに参加させる。
• Db2 Runtime Client をインストールする。
• Kerberos チケットで接続する (パスワード不要)。

さらに、多くの人がつまずく分かりにくいステップも 1 つ取り上げます。User オブジェクトに対して servicePrincipalName の読み取り/書き込み権限を付与するには、標準の Active Directory ユーザーとコンピューター スナップインではなく、ADSI エディター (adsiedit.msc) が必要です。

ソリューションの概要

次の図は、お客様が管理する Active Directory に対して Amazon RDS for Db2 を認証する際のアーキテクチャを示しています。

この設計では、RDS for Db2 がお客様のセルフマネージド AD ドメインに直接参加します。専用の AD サービスアカウントのユーザー ID とパスワードは AWS Secrets Manager に保存され、AWS KMS キーで暗号化されます。ドメイン参加の際、RDS はこれらの認証情報を Secrets Manager から取得し、ディレクトリにインスタンスを登録します。ドメイン参加済みの Db2 クライアントは AD の KDC から Kerberos チケット (TGT) を取得し、そのチケットを使ってパスワードのやり取りなしに RDS for Db2 へ接続します。RDS、クライアント、ドメインコントローラー間の通信は、標準的な AD のポート、すなわち DNS (53)、Kerberos (88、464)、LDAP (389、3268)、RPC 動的範囲 (49152〜65535) を利用します。

構築するもの

• RDS for Db2 用に範囲を絞った専用の OU と AD サービスアカウント、および RDS for Db2 が必要とする権限を委任した ACL。
• 認証情報を RDS へ安全に受け渡すための AWS KMS キーと Secrets Manager シークレット。
• セルフマネージド AD 変数を設定した Amazon RDS for Db2 インスタンス。
• AL2023 の EC2 ドメイン参加済みクライアントを使ってテスト済みの接続。

1. AD 権限を委任する

専用の OU とサービスアカウントを作成し、[制御の委任] ウィザードと ADSI エディターを使って必要なアクセス制御エントリ (ACE) を付与します。

• OU 内で User オブジェクトと Computer オブジェクトを作成/削除する。
• 子孫の User オブジェクトに対して、パスワードのリセットと msDS-SupportedEncryptionTypes の読み取り/書き込みを行う ([制御の委任] ウィザードを使用)。
• 子孫の User オブジェクトに対して servicePrincipalName の読み取り/書き込みを行う — ADSI エディターを使用 (adsiedit.msc)。

あるいは、提供されている PowerShell スクリプト を実行すれば、9 つの ACE すべてを冪等な 1 回の処理で適用できます。

.\Grant-ADDomainJoinPrivileges.ps1 `
    -ServiceAccount "CORP\rdsdb2svc" `
    -TargetOU "OU=RDSDb2,DC=company,DC=com" `
    -Verbose

同梱の、人間が読める形式で表示する ACL ビューアー スクリプトで検証します。

.\Show-OUDelegation.ps1 -OU "OU=RDSDb2,DC=company,DC=com" -SamAccountName rdsdb2svc

ServiceAccount 名はお好みの名前に置き換えるか、rdsdb2svc のままにします。TargetOU では、OU 名をお好みの名前に変更するか RDSDb2 のままにできますが、DC 名は必ずお使いの AD のドメイン名に合わせて変更してください。例: "OU=RDSDb2,DC=corp,DC=mycompany,DC=com"。

リポジトリでは、この委任について 2 つの同等な方法を説明しています。ADUC の [制御の委任] ウィザードと ADSI エディターを使う UI での手順と、上記の PowerShell スクリプトです。どちらも同じ ACL を生成するため、運用モデルに合った方を選んでください。始める前に、リポジトリの README を読んで一連の手順の全体像を把握してから、委任そのものについては詳細な UI での手順 (または PowerShell ガイド) に従ってください。

リポジトリの詳細な手順: README-UI.md

2. KMS キーと Secrets Manager シークレットを作成する

対称 KMS キーを作成し、サービスアカウントの認証情報を Secrets Manager シークレットとして保存します。このとき、RDS が読み取れるようにするリソースポリシーを設定します。

aws kms create-key --key-usage ENCRYPT_DECRYPT --key-spec SYMMETRIC_DEFAULT ...

aws secretsmanager create-secret --name "rds-db2-self-managed-ad-secret" ...

リポジトリの詳細な手順: README-KMS-Secret.md

3. サービスアカウントの認証情報を AWS Secrets Manager に保存する

AD サービスアカウントのユーザー名 (sAMAccountName のみで、DOMAIN\ プレフィックスは付けない) とパスワードを、前のステップで作成した KMS キーで暗号化した Secrets Manager シークレットとして保存し、RDS が読み取れるようにするリソースポリシーをアタッチします。RDS for Db2 は、ドメイン参加の際にこのシークレットを取得します。

aws secretsmanager create-secret --name "rds-db2-self-managed-ad-secret" ...

UI と CLI の詳しい手順はリポジトリにあります: README-KMS-Secret.md

4. RDS for Db2 インスタンスを構成する

DB インスタンスを変更または作成し、[ディレクトリ] セクションでシークレットの ARN を指定します。CLI の場合は次のとおりです。

aws rds modify-db-instance \
--db-instance-identifier your-db-instance \
--domain-fqdn "company.com" \
--domain-ou "OU=RDSDb2,DC=company,DC=com" \
--domain-auth-secret-arn "arn:aws:secretsmanager:..." \
--domain-dns-ips "<dc-ip-1>" "<dc-ip-2>" \
...

リポジトリの詳細な手順: README-RDS-Db2.md

5. ドメイン参加済みの Db2 クライアントから接続をテストする

同じ VPC 内で Amazon Linux 2023 の EC2 インスタンスを起動し、AD ドメインに参加させて、Db2 Runtime Client をインストールします。

ステップ 1 – AD に参加する

realmd、sssd、adcli、krb5-workstation をインストールします。

curl -sL https://bit.ly/domainjoin | bash
source joindomain.sh

ステップ 2 – Db2 RT クライアント をインストールする

REGION=<region>
./db2-driver.sh

ステップ 3 – DSN エントリを構成する

ドメイン参加を自動検出し、ローカル認証用と Kerberos 用の両方の DSN を書き込みます。

sudo su - db2inst1
REGION=<region> source db2client-configure.sh

ステップ 4 – 接続する

kinit user@COMPANY.COM
db2 terminate
db2 "connect to RDSAKS"  # Kerberos, no password
db2 "connect to RDSAS user admin using '$MASTER_USER_PASSWORD'"  # local auth

リポジトリの詳細な手順: README-Db2-Client.md

重要なポイント

1. User オブジェクトの SPN には ADUC ではなく ADSI エディターを使う。 ADUC スナップインは、User オブジェクトの属性一覧から servicePrincipalName を除外して表示します。ADSI エディターはスキーマ全体を表示します。ここが最もよくあるつまずきポイントです。
2. スコープが重要。 User オブジェクトではなく Computer オブジェクトに SPN の読み取り/書き込みを付与すると、一見正しく見えても実行時に失敗する ACL になります。Amazon RDS for Db2 は、自身が作成する User オブジェクトの権限をチェックするのであって、Computer オブジェクトではありません。
3. UI ではなく PowerShell で検証する。 ADUC の [セキュリティ] タブは、属性レベルの ACE を空白の行にまとめて表示してしまいます。提供されている Show-OUDelegation.ps1 スクリプトは、GUID を名前に解決して ACL を読みやすくします。
4. Secrets Manager でのユーザー名の形式。 シークレットには sAMAccountName のみを含める必要があり、DOMAIN\ プレフィックスは付けません。ドメインプレフィックスを含めると、インスタンスの作成に失敗します。

ネットワーク

AD と RDS の間には、複数のネットワーク構成が考えられます。次の 3 つのネットワークトポロジーについては、この ガイド を参照してください。

• AD と RDS が同じ VPC 内にある構成。
• AD を Microsoft Azure でホストする構成 (VPN または AWS Direct Connect + ExpressRoute)。
• AD が別の VPC または AWS アカウントにある構成 (VPC ピアリングまたは AWS Transit Gateway)。

主要なポートは DNS (53)、Kerberos (88、464)、LDAP (389、3268)、RPC 動的ポート (49152〜65535) です。RPC の範囲を開け忘れることが、最初のドメイン参加が成功した後に断続的な障害が起きる最もよくある原因です。

クリーンアップ

継続的な課金を避け、この手順で Active Directory に作成したプリンシパルを削除するには、作成した順序とは逆の順序でリソースを削除します。

1. EC2 の Db2 クライアントを終了する — ドメインから離脱し (realm leave)、自身のコンピューターオブジェクトを削除してから、インスタンスを終了し、専用の IAM インスタンスプロファイル/ロールがあれば削除します。
2. RDS for Db2 からセルフマネージド AD を削除する — インスタンスを残す場合は aws rds modify-db-instance --disable-domain でドメインをデタッチして (再起動)、不要になった場合は aws rds delete-db-instance でインスタンスを削除します。
3. サービスアカウントの認証情報を保持している Secrets Manager シークレットを削除する。
4. KMS キーの削除をスケジュールし、そのエイリアスを削除します。いずれかのインスタンスがストレージ暗号化にそのキーをまだ使用している間はキーを削除しないでください。削除するとスナップショットが復元不能になります。
5. AD オブジェクトを削除する — サービスアカウントと専用の OU を削除します (RDS がドメイン参加時に作成した Computer/User オブジェクトをすべて消去するため、再帰的に削除します)。OU は残して委任した権限だけを外したい場合は、OU の ACL をリセットします。

これらそれぞれについて、コンソールと CLI のオプションや検証チェックを含む手順ごとのコマンドは、GitHub リポジトリの クリーンアップガイド にあります。

まとめ

本記事では、セルフマネージド Active Directory を使って Amazon RDS for Db2 の Kerberos 認証を有効にする方法を紹介しました。9 つの AD 権限を正確に専用のサービスアカウントに委任し、その認証情報を KMS で暗号化した Secrets Manager シークレットとして RDS へ安全に受け渡し、DB インスタンスをドメインに参加させ、ドメイン参加済みの Db2 クライアントから Kerberos チケットを使ってパスワードなしで接続することで、結果を最初から最後まで検証しました。その過程で、多くの人がつまずきやすいステップも取り上げました。すなわち、servicePrincipalName の ACE には ADSI エディターを使うこと、権限を User オブジェクトに絞ること、そして RPC の動的ポート範囲を開けることです。

本記事全体で参照した PowerShell スクリプト、CLI コマンド、検証ツールは、aws-samples/sample-rds-db2-tools GitHub リポジトリで入手できます。リポジトリをクローンし、変数をお使いのドメインに合わせて調整すれば、RDS for Db2 ワークロード向けに一元化されたシングルサインオン認証をすぐに稼働させられます。詳細については、Amazon RDS ユーザーガイドの Kerberos authentication for Amazon RDS for Db2 を参照してください。ご質問やご提案があれば、コメントをお寄せください。

著者について

この記事はSolutions Architect の 矢木 覚が翻訳しました。