IE8 not applying cookies across domain appropriately -- only on one machine

Question

I have any interesting problem that has me totally stumped.

I have a piece of production code that I built that reads an IBM LTPA token cookie set by a machine managed by another dept, validates it, and uses it to log into a system my group manages (by setting some special cookies). This single sign-on process is entirely transparent to the end user, and has been working fine in production for several years across all browsers.

Recently, I noticed it does not work properly on my development machine with IE8. I recently upgraded from Vista to Windows 7. I'm not sure if this wasn't working on my machine before or after the upgrade however, as it's something that has worked for so long and I have no reason to test it reguarlly. FireFox 3.5 and Chrome 4 dev on this same machine both work as expected. IE6 on an XP SP3 virtual on this machine works fine. IE8 on multiple machines at home work fine (both Windows Server 2008 and Windows 7).

For diagnostic purposes, I cleared all cached data out of my dev IE8 (WinInet cache) to start with a clean slate. I fired up Fiddler to trace the the process and determine what wasn't working. What I found was rather interesting, and I cannot explain it.

After logging in at the intial site -- lets call it ltpa.domain.com, the session cookies are pushed down from the server as expected with the Set-Cookie header. I verify that the domain is properly set to .domain.com and that the path is /. All subsequent requests from the browser after login push all the cookies back up to the server with the each request as expected. In fact, this is a portal and there is some additional content from, lets says, portal.domain.com that is retrieved as well; all cookies are passed correctly to that server as well.

Now to the interesting bit -- when I make a request to myserver.domain.com -- the domain level cookies set by ltpa.domain.com are not pushed up to myserver.domain.com, even though they should be. The single sign-on process automatically redirects back to ltpa.domain.com if the cookies are missing (and pushes a cookie to the client which the ltpa login process uses to redirect) -- the domain level cookie set by myserver is not being pushed back up to ltpa.domain.com.

Again, this only happens on this one instance of IE8 on my dev machine that I'm aware of. This process is used thousands of times a day with a fairly large user base, and we've received no other complaints from end users -- so no indication that this is a systemic problem with IE8 or anything like that.

The behavior appears to me that it's treating myserver.domain.com and ltpa.domain.com as separate domains, even though they are not.

There are two points of interest that might be worth mentioning -- but could be red herrings as it has always been this way, and has never caused an issue.

• DNS is a little funky here. LTPA.domain.com resolves to the external IP. However, myserver.domain.com resolves to the internal IP. Doing a reverse lookup on that IP gives the internal dns name -- let's say myserver.internal.domain.com. I theorized that maybe IE8 was doing some sort of reverse lookup to prevent DNS based attacks -- so I modified my HOSTS file and pointed myserver.domain.com to the external IP for test purposes. I verifed in Fiddler that requests were going to the external IP -- but it made no difference with the cookies. They still weren't passed.

• Previously, myserver.domain.com was under 'Trusted Sites' within the IE WinInet security config pages. I removed it and the one other site that was there. Let's call this machine, my2.domain.com; this machine coincidentally (or maybe not?) is not being passed domain cookies set by ltpa.domain.com either. In this instance, I don't need the cookies passed, but I tested it anyway to see if this problem was affecting other machines. In the IE status bar, ltpa.domain.com, portal.domain.com and myserver.domain.com all show up under the 'Internet' zone. What's weird is that my2.domain.com is still showing 'Trusted Sites' in the status bar, even though it's not listed in the dialog?? Yes, I rebooted after making changes.

Other points of note.

• I'm aware of the other issues with IE and non .com domains, quoted cookie values, and other cookie anomalies -- mentioned here on stackoverflow and elsewhere on the Interwebs. None of these apply. I've read through Eric Law's IEInternals article on cookie internals -- http://blogs.msdn.com/ieinternals/archive/2009/08/20/WinINET-IE-Cookie-Internals-FAQ.aspx

• There are no funky addons enabled in IE. Just Flash, Silverlight, Live ID sign-in helper, and Fiddler2.

• There are no InPrivate rules for filtering out content specific to my domain.

• Since I'm on a laptop, I have tried IE8 from my home network (after a reboot) to rule out the DNS issues. I experience the same behavior at home, so the funky DNS isn't a problem as far as I can tell.

• I have plowed through all of the IE settings, multiple times, thinking that I might have missed an obscure cookie settings. Privacy settings are on 'Medium' and there are no sites with special handling.

• With the dev tools, I have made sure that 'Always Refresh From Server' is unchecked.

• I don't think this is anything I can report to Microsoft as I can't reproduce the problem anywhere else.

So at this point, I'm at a loss. Short of turning on some sort of diagnostic mode within IE8 that I'm unaware of, or having the code for it to debug... I've run out of good ideas.

I'm thinking I've either encountered a bug, some registry setting or similar has been tweaked, or something, somewhere has become corrupt.

Any ideas?

Answer 1

You need to be very careful with the word "domain", as many people use it to mean many different things.

http://blogs.msdn.com/ieinternals/archive/2009/09/19/Private-Domain-Names-and-Public-Suffixes-in-Internet-Explorer.aspx

From the description, it sounds very much like you're hitting issue #3 in the section "Troubleshooting Login Cookies" described in this post: http://blogs.msdn.com/ieinternals/archive/2009/09/11/Troubleshooting-Stored-Login-Problems-in-IE.aspx

You need to resolve the Zone / Integrity Level issue in order to resolve the cookie problem.

Answer 2

I think I've tracked down the issue here.

This has to be a bug in IE. Well, two actually if we're splitting hairs.

Even though I had deleted myserver.domain.com and my2.domain.com from the Trusted Sites site list in the IE security dialog pretty early on, these sites both remained in the zone configuration in the registry! I was able to figure this out by searching the registry for the names of my servers and voila, a little detective work proved fruitful.

There is a subkey under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains

for domain.com

And under domain.com remained two subkeys for the two different servers that I had deleted from the 'Trusted Sites' list dialog -- both with REG_DWORD for value * set to 2. This of course means, put the site in Trusted Sites.

I was able to dig up an old article from 'Scripting Guy' discussing this particular key and the values available to change the zones. http://blogs.technet.com/heyscriptingguy/archive/2005/05/02/how-can-i-add-a-site-to-internet-explorer-s-restricted-sites-zone.aspx

Perhaps these settings are deprecated in the UI in some way, but are still read / used? I don't know, but clearly there's a mismatch b/w what's shown in the UI and what's actually used.

Furthermore, as mentioned in a previous comment, when hitting the root of myserver.domain.com (which resulted in a 403 from the server btw), the status bar showed 'Internet | Protected Mode: Off' which only added to the confusion because it should have read as 'Trusted Sites | Protected Mode: Off'.

So the solution ended up being either

a - delete the reg keys specified above so that everything moved to the Internet zone OR b - add *.domain.com to the list of Trusted Sites so that everything moved to the Internet zone

Hopefully you can file these issues with the IE team Eric?

Thanks for getting me pointed in the right direction!