User Windows login name has been changed in AD yet session in SQL 2008 Profiler shows the old Windows login name

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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.