March 13, 2026 at 3:38 pm
Hi,
I have a SQL Server instance where users connect to via Windows Authentication, so for each user there is a row in sys.server_principals with (as example) "DomainA\JohnDoe". Recently a lot of users were migrated to DomainB (same forest) using the ADMigration wizard. Although I haven't created a new "DomainB\JohnDoe" login, this user is still able to connect to the SQLServer as "DomainB\JohnDoe". Even "sp_who" shows me "DomainB\JohnDoe".
What is the best way to change (ALTER) the login, so that it reflects the proper user (DomainA\JohnDoe --> DomainB\JohnDoe)?
Thanks,
Adri
March 14, 2026 at 4:10 pm
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
March 15, 2026 at 4:16 pm
If your domain admins alsomigrated the SIDs to the new domain's SIDHistory, this should keep on working
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data and code to get the best help
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Who am I ? Sometimes this is me but most of the time this is me
March 18, 2026 at 8:41 pm
Hi Johan,
Thanks for the answer, yes this indeed happened. I only wonder: How can I determine if "DomainA\JohnDoe" is the same as "DomainB\JohnDoe" (migrated) versus "DomainA\PeggySue" and "DomainB\PeggySue" (not migrated)?
Thanks,
Adri
March 27, 2026 at 12:02 am
Hi Adri
I went through the same domain migration and had to clone existing windows logins/groups to the new domain which looks like you're attempting to do. Here are 2 steps to clone existing windows logins and users to the new domain (if the new domain account just happens to not exist, then the script will error out and will tell you which login doesn't exist).
The first step generates scripts to clone server logins to the new domain.
The second step generates scripts to clone database users to the new domain and must run in every database. This is most likely a one time domain change event so there's no need to automate it.
--// STEP 1 run in master database. Clone NEWDOMAIN accounts based on OLDDOMAIN accounts
select 'CREATE LOGIN [NEWDOMAIN\' + right(name, len(name) - charindex('\', name)) + '] FROM WINDOWS WITH DEFAULT_DATABASE=[' + dbname + '];', *
from syslogins
where name like 'CALPINENA\%'
order by name
--// Step 2 run on each database. Updates each database user to switch to new domain
declare @command varchar(4000)
while exists ( select name from sysusers where name like 'OLDDOMAIN\%' )
begin
set @command = ( select top 1 'ALTER USER [' + name + '] WITH NAME = [NEWDOMAIN\' + UPPER(right(name, len(name) - charindex('\', name))) + '], LOGIN = [NEWDOMAIN\' + UPPER(right(name, len(name) - charindex('\', name) )) + '];'
from sysusers
where name like 'OLDDOMAIN\%')
select @command
-- execute (@command)
end
Tung Dang
Azure and SQL Server DBA Contractor / Consultant
SQL Brainbox
Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply