schleep (7/13/2012)
Ah sorry, posted answer in other forum...The OS reboot solved everything, the SQL service reboot changed nothing.
Excellent, that was what I was hoping.
Renamed 3 more accounts today.
Last week, netguys created copies of 2 of them with newnames.
I deleted those 2 before proceeding.
The one that never had a newname account is perfect. SQL Server recognizes it instantly.
The other 2, SQL Server does not recognize, and when I select the newnames from AD, the New Login window replaces the newname w/ the oldname.
I think the problem lies somewhere the Access Control tokens? I need to know if there is some way to force an update for the newnames.
P
Force an update where? In SQL Server?
The GUI may be playing games. I would try using T-SQL to create new logins.
What is created when you run this?
CREATE LOGIN [domain\Newname] FROM WINDOWS;
If you already created the login using the GUI using oldname then you can try this:
ALTER LOGIN [domain\oldname] WITH NAME = [domain\Newname];
I just picked up this capability of ALTER LOGIN on another thread recently where it had to do with migrating users to a new domain, but it may work for you since the idea is the same. The idea being that the newname AD account has multiple SIDs associated with it since it was renamed. Prior to the rename it was named oldname and had one SID, oldSID. Then you renamed it and now it's named newname and has a new SID, newSID. But, AD is smart and it tucks oldSID into a collection on the AD object called SID History and can therefore serve auth requests for oldname/oldSID because it finds it in the SID history for newname. SQL Server may have a hold of oldSID but renaming the LOGIN per the above ALTER may work because oldSID is in the SID History of newname.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato