views:

794

answers:

10

Here's my scenario. I created an application which uses Integrated Windows Authentication in order to work. In Application_AuthenticateRequest(), I use HttpContext.Current.User.Identity to get the current WindowsPrincipal of the user of my website.

Now here's the funny part. Some of our users have recently gotten married, and their names change. (i.e. the user's NT Login changes from jsmith to jjones) and when my application authenticates them, IIS passes me their OLD LOGIN . I continue to see jsmith passed to my application until I reboot my SERVER! Logging off the client does not work. Restarting the app pool does not work. Only a full reboot.

Does anyone know what's going on here? Is there some sort of command I can use to flush whatever cache is giving me this problem? Is my server misconfigured?

Note: I definitely do NOT want to restart IIS, my application pools, or the machine. As this is a production box, these are not really viable options.

+1  A: 

Restarting IIS, not the whole machine, should do the trick.

Nick
The server has the old user name cached from the authentication service. This should work.
Mark Roddy
-1: He clearly stated that he does not want to restart IIS
Robert MacLean
+1  A: 

When these users' names were changed, did you change only their NT Login names, or their UPN names too? the UPN names are the proper names, and used by Kerberos - which is the default protocol for IWA; however, if you just click to change their name in ActiveDirectory, only the NT Login name changes - even though thats what they would use to login (using the default windows GINA). Under the covers, windows would translate the (new) NT Login name to the (old) Kerberos name. This persists until AD is forced to update the Kerberos name according to the NT Login name...

AviD
+1  A: 

AviD -

Yes, their UPN was changed along with their login name. And Mark/Nick... This is a production enterprise server... It can't just be rebooted or have IIS restarted.

Dave Markle
+1  A: 

You look for something like "FLUSH PRIVILEGES:" (MySQL Server) for Active Directory to reread the Userdatabase?

BOFH
rather use comments to ask questions than posting answers (not sure if your level allows comments yet so no -1)
Robert MacLean
+2  A: 

If it's not an issue of changing only the NT Username, then it does seem that the authentication service is caching the old username.
You can define this to be disabled, go to the Local Security Settings (in Administrative Tools), and depending on version/edition/configuration the settings that are possible relevant (from memory) are "Number of previous logons to cache" and "Do not allow storage of credentials...".

Additional factors to take into account:

  • Domain membership might affect this, as member servers may inherit domain settings
  • You may still need to restart the whole server once for this to take affect (but then you won't have to worry about updates in the future).
  • Logon performance might be affected.

As such, I recommend you test this first before deploying on production (of course).

AviD
+2  A: 

The problem as AviD identified is the Active Directory cache which you can control via the registry. Depending on your solution Avid's group policy options will fail or work depending if you are actually logging the users on or not.

How it is being cached depends on how you are authenticating on IIS. I suspect it could be Kerberos so to do the clearing if it is being caused by Kerberos you may want to try klist with the purge option which should purge kerberos tickets, which will force a reauth to AD on the next attempt and update the details.

I would also suggest looking at implementing this which is slightly more complex but far less error prone.

Robert MacLean
+2  A: 

I know we've had cached credentials problems in IIS in the past here, too, and after Googling for days we came across an obscure (to us, at least) command you can use to view and clear cached credentials.

Start -> Run (or WinKey+R) and type control keymgr.dll

This fixed our problems for client machines. Haven't tried it on servers but it might be worth a shot if its the server caching credentials. Our problem was we were getting old credentials but only on a client machine basis. If the user logged in on a separate client machine, everything was fine, but if they used their own machine at their desk that they normally work on it had the cached old credentials.

Yadyn
A: 

Login to the server that runs the IIS using the new login name in question. This will refresh the credential without re-starting IIS or rebooting the server.

+1  A: 

This should help.

A: 

Was there ever a definitive answer to this issue?

I have the same issue (IIS 6.0) - the only solution which works is to reboot the web server. I have tried all the suggestions above and none have worked with the exception of disabling cached logons policy as this refers to 'interactive' logons.

Cheers,

Andy

Pants
Sadly, I never got an answer which left me totally satisfied. I have a feeling it was something fundamentally broken on the server.
Dave Markle