本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 搭配 使用 Kerberos 身分驗證 AWS Database Migration Service 從 DMS v3.5.3 開始，您可以將 Oracle 或 SQL Server 來源端點設定為使用 Kerberos 身分驗證連線至資料庫執行個體。DMS 支援 Directory Service Microsoft Active Directory 和 Kerberos 身分驗證。如需 Microsoft Active Directory Services AWS受管存取的詳細資訊，請參閱[什麼是 Directory Service？](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/what_is.html)。 ## AWS DMS Kerberos 身分驗證架構概觀 下圖提供 AWS DMS Kerberos 身分驗證工作流程的高階概觀。 ![Kerberos 身分驗證架構](http://docs.aws.amazon.com/zh_tw/dms/latest/userguide/images/datarep-kerberos-architecture.jpg) ## 搭配 使用 Kerberos 身分驗證的限制 AWS DMS 搭配 使用 Kerberos 身分驗證時，適用下列限制 AWS DMS： + DMS 複寫執行個體支援一個 Kerberos `krb5.conf` 檔案和一個 keycache 檔案。 + 您必須在票證到期前至少 30 分鐘更新 Secrets Manager 中的 Kerberos keycache 檔案。 + 啟用 Kerberos 的 DMS 端點僅適用於啟用 Kerberos 的 DMS 複寫執行個體。 ## 先決條件 若要開始，您必須從現有的 Active Directory 或 Kerberos 驗證的主機完成下列先決條件： + 與您的內部部署 AD 建立 Active Directory 信任關係。如需詳細資訊，請參閱[教學課程：在 AWS Managed Microsoft AD 與自我管理 Active Directory 網域之間建立信任關係](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust.html)。 + 準備簡化版的 Kerberos `krb5.conf`組態檔案。包含有關領域、網域管理員伺服器的位置，以及主機名稱映射到 Kerberos 領域的資訊。您需要驗證`krb5.conf`內容已針對領域和網域領域名稱使用正確的混合大小寫進行格式化。例如： ``` [libdefaults] dns_lookup_realm = true dns_lookup_kdc = true forwardable = true default_realm = MYDOMAIN.ORG [realms] MYDOMAIN.ORG = { kdc = mydomain.org admin_server = mydomain.org } [domain_realm] .mydomain.org = MYDOMAIN.ORG mydomain.org = MYDOMAIN.ORG ``` + 準備 Kerberos keycache 檔案。檔案包含用戶端主體資訊的臨時 Kerberos 登入資料。檔案不會存放用戶端的密碼。您的 DMS 任務使用此快取票證資訊來取得沒有密碼的其他登入資料。在現有的 Active Directory 或 Kerberos 驗證的主機上執行下列步驟，以產生 keycache 檔案。 + 建立 Kerberos keytab 檔案。您可以使用 **kutil** 或 **ktpass** 公用程式產生 keytab 檔案。 如需 Microsoft **ktpass** 公用程式的詳細資訊，請參閱 *Windows Server 文件*中的 [ktpass](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ktpass)。 如需 MIT **kutil** 公用程式的詳細資訊，請參閱 *MIT Kerberos 文件*中的 [kutil](https://web.mit.edu/kerberos/krb5-1.12/doc/admin/admin_commands/ktutil.html)。 + 使用 **kinit** 公用程式從 keytab 檔案建立 Kerberos keycache 檔案。如需 **kinit** 公用程式的詳細資訊，請參閱 *MIT Kerberos 文件*中的 [kinit](https://web.mit.edu/kerberos/krb5-1.12/doc/user/user_commands/kinit.html)。 + 使用 `SecretBinary` 參數將 Kerberos keycache 檔案存放在 Secrets Manager 中。當您將 keycache 檔案上傳至 Secrets Manager 時，DMS 會擷取該檔案，然後約每 30 分鐘更新一次本機快取檔案。當本機 keycache 檔案超過預先定義的過期時間戳記時，DMS 會正常停止任務。為了避免在進行中的複寫任務期間發生身分驗證失敗，請在票證過期前至少 30 分鐘更新 Secrets Manager 中的 keycache 檔案。如需詳細資訊，請參閱 *Secrets Manager API 參考*中的 [createsecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html)。下列 AWS CLI 範例示範如何在 Secrets Manager 中以二進位格式存放 keycache 檔案： ``` aws secretsmanager create-secret —name keycache —secret-binary fileb:{{//keycachefile}} ``` + 授予 IAM 角色從 Secrets Manager 取得 keycache 檔案的 `GetSecretValue`和 `DescribeSecret`許可。確定 IAM 角色包含`dms-vpc-role`信任政策。如需`dms-vpc-role`信任政策的詳細資訊，請參閱 [建立要與 搭配使用的 IAM 角色 AWS DMS](security-iam.md#CHAP_Security.APIRole)。 下列範例顯示具有 Secrets Manager `GetSecretValue`和 `DescribeSecret` 許可的 IAM 角色政策。{{}} 值是您在上一個步驟中建立的 Keycache Secrets Manager ARN。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": "*" } ] } ``` ------ ## 在 DMS 複寫執行個體上啟用 Kerberos AWS 支援 Kerberos 領域與 Windows 中的網域相同。為了解決原則領域，Kerberos 依賴網域名稱服務 (DNS)。當您設定 `dns-name-servers` 參數時，複寫執行個體將使用您預先定義的自訂 DNS 伺服器集來解析 Kerberos 網域領域。解決 Kerberos 領域查詢的另一個替代選項是在複寫執行個體虛擬私有雲端 (VPC) 上設定 Amazon Route 53。如需詳細資訊，請參閱 [Route 53](https://docs.aws.amazon.com/route53/)。 ### 使用 在 DMS 複寫執行個體上啟用 Kerberos 支援 AWS 管理主控台 若要使用主控台啟用 Kerberos 支援，請在**建立複寫執行個體**或修改**複寫執行個體**頁面的 **Kerberos 身分驗證**區段中輸入下列資訊： + 來自您 `krb5.conf` 檔案的內容 + 包含 keycache 檔案之 Secrets Manager 秘密的 ARN + 可存取秘密管理員 ARN 的 IAM 角色 ARN，以及擷取 keycache 檔案的許可 ### 使用 在 DMS 複寫執行個體上啟用 Kerberos 支援 AWS CLI 下列 AWS CLI 範例呼叫會使用 Kerberos 支援建立私有 DMS 複寫執行個體。複寫執行個體使用自訂 DNS 來解析 Kerberos 領域。如需詳細資訊，請參閱 [create-replication-instance](https://docs.aws.amazon.com/cli/latest/reference/dms/create-replication-instance.html)。 ``` aws dms create-replication-instance --replication-instance-identifier my-replication-instance --replication-instance-class dms.t2.micro --allocated-storage 50 --vpc-security-group-ids sg-12345678 --engine-version 3.5.4 --no-auto-minor-version-upgrade --kerberos-authentication-settings'{"KeyCacheSecretId":,"KeyCacheSecretIamArn":,"Krb5FileContents":}' --dns-name-servers {{}} --no-publicly-accessible ``` ## 在來源端點上啟用 Kerberos 支援 在 DMS Oracle 或 SQL 伺服器來源端點上啟用 Kerberos 身分驗證之前，請確定您可以使用用戶端機器的 Kerberos 通訊協定對來源資料庫進行身分驗證。您可以使用 AWS DMS 診斷 AMI 在與複寫執行個體相同的 VPC 上啟動 Amazon EC2 執行個體，然後測試 kerberos 身分驗證。如需 AMI 的詳細資訊，請參閱 [使用 AWS DMS 診斷支援 AMI](CHAP_SupportAmi.md)。 ### 使用 AWS DMS 主控台 在**存取端點資料庫**下，選擇 **Kerberos 身分驗證**。 ### 使用 AWS CLI 指定端點設定參數，並將`AuthenticationMethod`選項設定為 kerberos。例如： **Oracle** ``` aws dms create-endpoint --endpoint-identifier my-endpoint --endpoint-type source --engine-name oracle --username dmsuser@MYDOMAIN.ORG --server-name {{mydatabaseserver}} --port 1521 --database-name {{mydatabase}} --oracle-settings "{\"AuthenticationMethod\": \"kerberos\"}" ``` **SQL Server** ``` aws dms create-endpoint --endpoint-identifier my-endpoint --endpoint-type source --engine-name sqlserver --username dmsuser@MYDOMAIN.ORG --server-name {{mydatabaseserver}} --port 1433 --database-name {{mydatabase}} --microsoft-sql-server-settings "{\"AuthenticationMethod\": \"kerberos\"}" ``` ## 測試來源端點 您必須針對已啟用 Kerberos 的複寫執行個體測試已啟用 Kerberos 的端點。當您未正確建立複寫執行個體或來源端點以進行 Kerberos 身分驗證時，端點`test-connection`動作將會失敗，並可能傳回與 Kerberos 相關的錯誤。如需詳細資訊，請參閱 [ test-connection](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/dms/test-connection.html)。