AWS AmazonRDS: Fixed session_id variable in Kerberos check
Summary
Changed `@@SSPID` to `@@SPID` in Kerberos authentication verification query.
Security assessment
Corrects a typo in a diagnostic query but doesn't impact security functionality.
Evidence
- WHERE session_id = @@SSPID;
Diff
diff --git a/AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.Joining.md b/AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.Joining.md index cdda5199d..20e0d9166 100644 --- a//AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.Joining.md +++ b//AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.Joining.md @@ -162 +162 @@ To check if your connection is using Kerberos, run the following query: - WHERE session_id = @@SSPID; + WHERE session_id = @@SPID; @@ -185,0 +186,4 @@ Specify users and groups using the pre-Windows 2000 login name in the format ``m +###### 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. +