Background: a user had her name changed in Active Directory from Domain\oldname to Domain\newname and successfully logged into the network with Domain\newname and yet Domain\oldname appears in columns LoginName and NTUserName in Profiler.

User's SQL Server permissions are granted via a group set up in SQL Server security.

The question: Has anyone observed this behavior and know why SQL Server is still picking up Domain\oldname (sp_who2 shows same information)?

BTW, have spent considerable time researching before posting question here and it appears to me that is no real issue with Profiler/SQL 2008 R2.

6 Answers 6


I guess I can't comment on your question since this is the first time I've used stack exchange but is this an AD group that the user is in? Sometimes people say group when they mean SQL role so I just wanted to get some clarification.

The reason I ask is because if the user has a login on the server of domain\olduser when you change the name in AD to domain\newuser you have to go into SQL and change the login to domain\newuser. I've done this and it works perfectly fine and you don't have to do anything as drastic as restart SQL. I do not know if the account name will eventually change to the new one over time but my guess would be no.

I do not know, however, what happens when the user is just part of an AD group that has permissions and doesn't actually have a login on the server. Hence the need for clarification so I can look into that.

  • It is an Active Directory group and not a SQL Server role. There are a number of users with similar access needs and it is easier for me to get an AD group created and grant permissions to just one security entry.
    – jl01
    Feb 23, 2012 at 15:57
  • I can actually confirm that restarting the SQL service does not fix the problem. I created a domain\testuser in a test AD group. Added the test AD group into sql and gave it permissions to a table in a test database I had. When I change my test users login to domain\testuser123 it still shows as domain\testuser before and after restarting the SQL service. My guess is that we need to look outside of SQL for an answer. Feb 23, 2012 at 16:27
  • 1
    A reboot of my SQL test box did do the trick however. It now shows up as domain\testuser123. Feb 23, 2012 at 16:42

I ran into the same problem in a SQL Server 2012 instance (SP2 applied). I haven't found the root cause yet, but we will be looking at the AD caching mechanism, as suggested by StanleyJohns.

By accident I have found a simple solution that worked for me without rebooting the server. I created a Windows Authenticated login for the old username (yes, that worked) and then dropped it - problem solved.

After the create / drop I was unable to create the same login a second time, so it looks like the "drop login" is another way of forcing the old username out of the AD cache.


SQL Server may take some time to work out the change
It caches based on the "sid" which is unchanged. No harm done though.

I don't know the exact rules, but I've seen it happen. At the extreme, it will clear after a SQL Server restart if it's important

Also, check sys.server_principals and the relevant sys.database_principals for any entries. This can happen if the users owns any objects (eg CREATE TABLE without a schema qualifier).


Since she is a member of the AD Group she still has access. Her old username showing up in SQL Server could be from login cache.

You might try closing any connections the old login name has, since it might cache the SID for her login. Since the login was just renamed in AD I don't think that it will change the SID so the mapping is still there for SQL Server to function with the old name.

  • She was logged out and her desktop shutdown when AD was changed. That being said I cannot rule out the possibility of a SPID from her last connection prior to the name change in AD persisting in SQL Server and causing the issue.
    – jl01
    Feb 23, 2012 at 14:53
  • We tried closing the Domain\oldname connections in this mix.
    – jl01
    Feb 23, 2012 at 15:56

The AD changes will take some time to propagate. Also, the authentication token in cached and that is what is providing access, while still showing the older login name.

You can try purging the cache: net use * /delete /y at the command line.

Or try forcing the AD credentials to update: control userpasswords2 at the command line. Then go to the 'Advanced' tab and select "Manage Passwords", this will let you modify saved network passwords.

This will save you from having to restart the server.


In my case the only thing that worked is to drop user and re-add user. Note you have to check and remove ownership from SQL jobs as well DBO from any database.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.