Trusted Login Issues

Had a massive issue negative testing the Trusted Setup for OI SQL2005. The application was behaving as expected during the “first load” for any user on any machine. Default access was denied.

Step 2: Added the EG user to the Server\MyUsers group the user was gaining access (see caveat below) and the login name was being successfully populated in the User text field.

However when the EG user was then removed from the MyUsers group, to do the negative test, I expected to see the authentication challenge repeated. It was not.

Infact no combination of IE restart, IIS restart or machine restart could seem to break the authentication that had been created in step 2.

Lots of searching revealed little information about negative testing. A tool was found in the Windows Resource Kit to show and purge the Kerberos certificates that had been issued (kerbtray.exe). I couldn’t figure out whether the cert are stored on the server or the client, but purging from both didn’t help anyway.

Utlimatley the fix put in place to sort the issue was:

• Remove all privileges in Windows and IIS for the entire OI folder structure.
• Re-add permissions for ASPNET, MyUsers, MyService, IUSR, IIS_WPG, SYSTEM, Administrator to Windows and IIS and ensure these inherit across the application.
• Uncheck the Enable Integrated Windows Authentication (requires restart) option in IE | Tools | Advanced

This seemed to have the desired effect, but during the course of the modifications and manipulations it is possible that some setup steps weren’t completed or set incorrectly.

Email thread with Adrian:

Hi Mark, 
Depending upon your browser settings, closing the browser window may not terminate the IEXPLORE process and session settings may be cached here. 
I believe the Enable Integrated Windows Authentication setting in IE6 relates to the Negotiate/Kerberos authentication mechanisms. When you uncheck it, this makes IE default to NTLM and avoid Kerberos. 
Glad you’ve got something working. 
Adrian. 
-------------------------------------------------------------------------------- 

From: Mark Cooper [mailto:…Sent: 24 August 2006 08:32 To: Adrian … Subject: RE: IIS6 Security Cache[EG] 
Hi Adrian, 
I was resetting IIS but not IEXPLORE.EXE. I was closing the browser and opening fresh and figured this should be enough to purge and security cache. At this time we have a working example that can be negative tested, this was achieved by unchecking the option in Internet Explorer “Enable Integrated Windows Authentication (requires restart)”. Seems to me that this setting is the wrong way round? 
Anyway this is working and in test at the moment. 
Thanks, 
Mark -------------------------------------------------------------------------------- 

From: Adrian … [mailto:…] Sent: 23 August 2006 15:27 To: Mark Cooper Subject: RE: IIS6 Security Cache[EG] 
Hi Mark, 
Apologies for not replying sooner – I’ve been out of the office for a couple of days. 
Are you resetting IIS and restarting the IEXPLORE.EXE process once you’ve made the changes? It might be worth using something like proxytrace, Fiddler, or tcptrace to see what is going over the wire in the subsequent requests and looking for the authentication headers passed in the request. 
Adrian. 
-------------------------------------------------------------------------------- 

From: Mark Cooper [mailto:…] Sent: 18 August 2006 08:45 To: Adrian … Subject: IIS6 Security Cache 
Hi Adrian, 
We are experiencing some odd results during security test for a trusted login OI environment, and I wonder if you’d be able to help. 
I have setup the environment with minimum permission and get challenged for a network credentials on the very first attempt to login to the site from any machine. If I then add permissions on the server for the user to connect, the OI login page loads, and the trusted name is correctly picked up and trusted logins work. All this is good and as expected. 
The problem I have is if I then try a negative test, by removing the users credentials on the server, I’d expect to be challenged for a network password again, but I am not. The login page loads as previous. 
I’m pretty sure that this issue is at the network / IIS level, rather than on the web app. I can only assume that somewhere along the line the credentials are being cached. Does this sound right? If so, do you know how I can clear it? 
Thanks for any help you can provide, 
Mark