Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 5 down vote accepted

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.

share|improve this answer
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 '12 at 15:57
Yep. Correct you need 50 rep before you get the ability to post comments. See What is reputation? for more explanation. – Martin Smith Feb 23 '12 at 15:58
Yeah that is definitely the way to go. Just wanted to see if the user also had a login on the server as domain\olduser as well. This happens if you wanted to grant specific rights to this one user or add them to a SQL role. – Shane Thompson Feb 23 '12 at 16:00
A reboot of my SQL test box did do the trick however. It now shows up as domain\testuser123. – Shane Thompson Feb 23 '12 at 16:42
Thanks Shane. I suggested to management an off-hours restart of the MSSSQLservice when this first appeared but... – jl01 Feb 24 '12 at 15:09

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).

share|improve this answer
I expected restarting the SQL Server service would handle it. Management may require us to wait until our first outage weekend in March. – jl01 Feb 23 '12 at 16:05
@jl01 restarting the service does not appear to resolve this issue in 08R2/12/14 in my envs – ConstantineK Mar 18 at 21:30

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.

share|improve this answer

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.

share|improve this answer
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 '12 at 14:53
We tried closing the Domain\oldname connections in this mix. – jl01 Feb 23 '12 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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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