AWS AmazonRDS: Added SID caching warning for AD user reuse
Summary
Documentation added about SID caching risks when reusing sAMAccountName after user deletion.
Security assessment
Addresses a potential privilege escalation vector where reused usernames might retain old permissions via cached SIDs.
Evidence
+If you delete an Active Directory user and create a new user with the same `sAMAccountName`, then run `CREATE LOGIN [DOMAIN\username] FROM WINDOWS` on your RDS for SQL Server instance, the login might be created with the deleted user's SID instead of the new user's SID, causing Windows Authentication failures.
Diff
diff --git a/AmazonRDS/latest/UserGuide/USER_SQLServerWinAuth.SettingUp.md b/AmazonRDS/latest/UserGuide/USER_SQLServerWinAuth.SettingUp.md index 9e450f973..13ba4b9ab 100644 --- a//AmazonRDS/latest/UserGuide/USER_SQLServerWinAuth.SettingUp.md +++ b//AmazonRDS/latest/UserGuide/USER_SQLServerWinAuth.SettingUp.md @@ -350,0 +351,4 @@ You can only create a Windows Authentication login on an RDS for SQL Server inst +###### Note + +If you delete an Active Directory user and create a new user with the same `sAMAccountName`, then run `CREATE LOGIN [DOMAIN\username] FROM WINDOWS` on your RDS for SQL Server instance, the login might be created with the deleted user's SID instead of the new user's SID, causing Windows Authentication failures. This occurs because the RDS host caches name-to-SID mappings at the OS level, and this cache isn't directly accessible to customers. To avoid this issue, use a unique `sAMAccountName` for each provisioning cycle (for example, by appending a timestamp or version suffix). If you must reuse the same name, run `DBCC FREESYSTEMCACHE('TokenAndPermUserStore')` after recreating the AD user, then wait up to 10 minutes (to allow the OS-level cache to refresh, as this interval is not configurable on RDS managed instances) and validate that `SUSER_SID('DOMAIN\username')` returns the expected SID before creating the login. +