2

A user in the Active Directory has had a change of his SAM account name, but a web application running IIS still recognizes him under his old SAM Account name. I presume this is because the AD principals are cached.

The IIS server variables in the request indicates the mismatch:

  • LOGON_USER: Old user name
  • AUTH_USER: New user name

How can the principal be purged from the cache on the server so that it picks up the new SAM account name (preferably without rebooting the server or waiting for the 720 minute cache expiry duration)?

PHeiberg
  • 121
  • 4

2 Answers2

2

see http://support.microsoft.com/kb/946358 for a possible solution (set LsaLookupCacheMaxSize 0)

also see http://technet.microsoft.com/en-us/library/ff428139(WS.10).aspx ( How SIDs and Account Names Can Be Mapped in Windows )

bkr
  • 835
  • 1
  • 8
  • 20
0

You were pointed into the right direction with KB946358. LSA cache is being purged when server restarts or may be disabled entirely (but this will require restart first).
I'm very interested in finding precise reproduction steps for this. See my question about this - still no answer so far, but it contains a solution which doesn't require reboot to fix your renamed user. You have to run following PS script on your sever where you have stale date in LSA cache once after rename:

$objuser = new-object system.security.principal.ntaccount "domain\<new account name>" 
$objuser.translate([system.security.principal.securityidentifier])

Source: http://www.myfatblog.co.uk/index.php/2012/07/kerberos-web-services-and-getting-married/
I tried this solution and confirm that it works.
Also you may find the following an interesting read on this subject: https://marclsitinfrablog.wordpress.com/2011/06/25/lsa-lookup-cache/

I will appreciate is somebody will be able to explain how I can reproduce this or at least give me some idea how I can recreate the situation when "recurring queries by applications keep the existing cache entry alive for the maximum lifetime of the cache entry." (this is short and laconic explanation of issue's cause from KB946358)

Community
  • 1
Mikhail
  • 1,287
  • 3
  • 18
  • 35