AWS Security ChangesHomeSearch

AWS AmazonRDS medium security documentation change

Service: AmazonRDS · 2025-08-19 · Security-related medium

File: AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.SettingUp.md

Summary

Updated Active Directory setup steps to use domain service accounts instead of generic users, added Kerberos authentication configuration details, removed DB instance creation/modification steps, and restructured documentation

Security assessment

The change promotes security best practices by replacing generic AD user accounts with dedicated service accounts (reducing attack surface) and explicitly adds Kerberos authentication configuration steps. The addition of 'Write servicePrincipalName' permission and DNS security configuration helps prevent authentication vulnerabilities. These changes directly impact authentication security in AD integration.

Diff

diff --git a/AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.SettingUp.md b/AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.SettingUp.md
index 3ae4f016b..eb668f500 100644
--- a//AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.SettingUp.md
+++ b//AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.SettingUp.md
@@ -5 +5 @@
-Step 1: Create an Organizational Unit in your ADStep 2: Create an AD domain user in your AD.Step 3: Delegate control to the AD user.Step 4: Create an AWS KMS key.Step 5: Create an AWS secret.Step 6: Create or modify a SQL Server DB instanceStep 7: Create Windows Authentication SQL Server logins
+Step 1: Create an Organizational Unit in your ADStep 2: Create an AD domain service account in your AD.Step 3: Delegate control to the AD domain service accountStep 4: Create an AWS KMS key.Step 5: Create an AWS secret.
@@ -7 +7 @@ Step 1: Create an Organizational Unit in your ADStep 2: Create an AD domain user
-# Setting up Self Managed Active Directory
+# Setting up self-managed Active Directory
@@ -9 +9 @@ Step 1: Create an Organizational Unit in your ADStep 2: Create an AD domain user
-To set up Self Managed AD, take the following steps.
+To set up a self-managed AD, take the following steps.
@@ -15 +15 @@ To set up Self Managed AD, take the following steps.
-  * Step 2: Create an AD domain user in your AD
+  * Step 2: Create an AD domain service account in your AD
@@ -17 +17 @@ To set up Self Managed AD, take the following steps.
-  * Step 3: Delegate control to the AD user
+  * Step 3: Delegate control to the AD domain service account
@@ -23,4 +22,0 @@ To set up Self Managed AD, take the following steps.
-  * Step 6: Create or modify a SQL Server DB instance
-
-  * Step 7: Create Windows Authentication SQL Server logins
-
@@ -53 +49 @@ We recommend creating a dedicated OU and service credential scoped to that OU fo
-## Step 2: Create an AD domain user in your AD
+## Step 2: Create an AD domain service account in your AD
@@ -55 +51 @@ We recommend creating a dedicated OU and service credential scoped to that OU fo
-The domain user credentials will be used for the secret in AWS Secrets Manager.
+The domain service account credentials will be used for the secret in AWS Secrets Manager.
@@ -57 +53 @@ The domain user credentials will be used for the secret in AWS Secrets Manager.
-###### To create an AD domain user in your AD
+###### To create an AD domain service account in your AD
@@ -72 +68 @@ The domain user credentials will be used for the secret in AWS Secrets Manager.
-## Step 3: Delegate control to the AD user
+## Step 3: Delegate control to the AD domain service account
@@ -74 +70 @@ The domain user credentials will be used for the secret in AWS Secrets Manager.
-###### To delegate control to the AD domain user in your domain
+###### To delegate control to the AD domain service account in your domain
@@ -84 +80 @@ The domain user credentials will be used for the secret in AWS Secrets Manager.
-  5. On the **Select Users, Computers, or Groups** section, enter the AD user you created and click **Check Names**. If your AD user check is successful, click **OK**.
+  5. On the **Select Users, Computers, or Groups** section, enter the AD domain service account you created and click **Check Names**. If your AD domain service account check is successful, click **OK**.
@@ -86 +82 @@ The domain user credentials will be used for the secret in AWS Secrets Manager.
-  6. On the **Users or Groups** section, confirm your AD user was added and click **Next**.
+  6. On the **Users or Groups** section, confirm your AD domain service account was added and click **Next**.
@@ -107,0 +104,2 @@ The domain user credentials will be used for the secret in AWS Secrets Manager.
+    4. To enable Kerberos authentication, keep **Property-specific** selected and select **Write servicePrincipalName** from the list.
+
@@ -109,0 +108,8 @@ The domain user credentials will be used for the secret in AWS Secrets Manager.
+  11. For Kerberos authentication, open the DNS Manager and open **Server** properties.
+
+    1. In the Windows dialog box, type `dnsmgmt.msc`.
+
+    2. Add the AD domain service account under the **Security** tab.
+
+    3. Select the **Read** permission and apply your changes.
+
@@ -249,140 +254,0 @@ JSON
-## Step 6: Create or modify a SQL Server DB instance
-
-You can use the console, CLI, or RDS API to associate an RDS for SQL Server DB instance with a self-managed AD domain. You can do this in one of the following ways:
-
-  * Create a new SQL Server DB instance using the console, the [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) CLI command, or the [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) RDS API operation.
-
-For instructions, see [Creating an Amazon RDS DB instance](./USER_CreateDBInstance.html).
-
-  * Modify an existing SQL Server DB instance using the console, the [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI command, or the [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API operation.
-
-For instructions, see [Modifying an Amazon RDS DB instance](./Overview.DBInstance.Modifying.html).
-
-  * Restore a SQL Server DB instance from a DB snapshot using the console, the [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) CLI command, or the [RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) RDS API operation.
-
-For instructions, see [Restoring to a DB instance](./USER_RestoreFromSnapshot.html).
-
-  * Restore a SQL Server DB instance to a point-in-time using the console, the [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 command, or the [RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) RDS API operation.
-
-For instructions, see [Restoring a DB instance to a specified time for Amazon RDS](./USER_PIT.html).
-
-
-
-
-When you use the AWS CLI, the following parameters are required for the DB instance to be able to use the self-managed Active Directory domain that you created:
-
-  * For the `--domain-fqdn` parameter, use the fully qualified domain name (FQDN) of your self-managed Active Directory.
-
-  * For the `--domain-ou` parameter, use the OU that you created in your self-managed AD.
-
-  * For the `--domain-auth-secret-arn` parameter, use the value of the **Secret ARN** that you created in a previous step.
-
-  * For the `--domain-dns-ips` parameter, use the primary and secondary IPv4 addresses of the DNS servers for your self-managed AD. If you don't have a secondary DNS server IP address, enter the primary IP address twice.
-
-
-
-
-The following example CLI commands show how to create, modify, and remove an RDS for SQL Server DB instance with a self-managed AD domain.
-
-###### Important
-
-If you modify a DB instance to join it to or remove it from a self-managed AD domain, a reboot of the DB instance is required for the modification to take effect. You can choose to apply the changes immediately or wait until the next maintenance window. Choosing the **Apply Immediately** option will cause downtime for a single-AZ DB instance. A multi-AZ DB instance will perform a failover before completing a reboot. For more information, see [Using the schedule modifications setting](./USER_ModifyInstance.ApplyImmediately.html). 
-
-The following CLI command creates a new RDS for SQL Server DB instance and joins it to a self-managed AD domain.
-
-For Linux, macOS, or 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"
-
-For 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"
-
-The following CLI command modifies an existing RDS for SQL Server DB instance to use a self-managed Active Directory domain.
-
-For Linux, macOS, or 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"
-
-For 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"
-
-The following CLI command removes an RDS for SQL Server DB instance from a self-managed Active Directory domain.
-
-For Linux, macOS, or Unix:
-    
-    
-    aws rds modify-db-instance \
-        --db-instance-identifier my-DB-instance \
-        --disable-domain
-
-For Windows:
-    
-    
-    aws rds modify-db-instance ^
-        --db-instance-identifier my-DB-instance ^
-        --disable-domain
-
-## Step 7: Create Windows Authentication SQL Server logins
-
-Use the Amazon RDS master user credentials to connect to the SQL Server DB instance as you do for any other DB instance. Because the DB instance is joined to the self-managed AD domain, you can provision SQL Server logins and users. You do this from the AD users and groups utility in your self-managed AD domain. Database permissions are managed through standard SQL Server permissions granted and revoked to these Windows logins.
-
-In order for a self-managed AD user to authenticate with SQL Server, a SQL Server Windows login must exist for the self-managed AD user or a self-managed Active Directory group that the user is a member of. Fine-grained access control is handled through granting and revoking permissions on these SQL Server logins. A self-managed AD user that doesn't have a SQL Server login or belong to a self-managed AD group with such a login can't access the SQL Server DB instance.
-
-The ALTER ANY LOGIN permission is required to create a self-managed AD SQL Server login. If you haven't created any logins with this permission, connect as the DB instance's master user using SQL Server Authentication and create your self-managed AD SQL Server logins under the context of the master user.
-
-You can run a data definition language (DDL) command such as the following to create a SQL Server login for an self-managed AD user or group.
-
-###### Note
-
-Specify users and groups using the pre-Windows 2000 login name in the format ``my_AD_domain`\`my_AD_domain_user``. You can't use a user principal name (UPN) in the format ``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
-
-For more information, see [CREATE LOGIN (Transact-SQL)](https://msdn.microsoft.com/en-us/library/ms189751.aspx) in the Microsoft Developer Network documentation.
-
-Users (both humans and applications) from your domain can now connect to the RDS for SQL Server instance from a self-managed AD domain-joined client machine using Windows authentication.
-
@@ -397 +263 @@ Requirements
-Managing a DB instance in a self-managed Active Directory Domain