Directory Programming .NET

We are experiencing an interesting problem where if a user clicks on a link to our claims aware application from within word/excel/powerpoint then IE displays a error message after the user authenticates to their account server.  If the user closes their browser, clears their cookies, opens up a new instance of the browser and enters the URL directly into the address bar then it works fine.

At this point, I tracked it down to an error in the AD FS claims aware agent log file when the agent attempts to parse through the cookie being sent from our resource server.  This is a snippet from the logs when the user clicks on our URL from within MS word (failure):

2010-02-02T17:52:26 [VERBOSE] Could not load context from cookie so ba960bdd-5874-411c-b19e-6db22f9eae20 will be used as the actual value.
2010-02-02T17:52:26 [INFO] Loaded context ba960bdd-5874-411c-b19e-6db22f9eae20.
2010-02-02T17:52:26 [VERBOSE] WebSSO data has been received in the POST body.
[VERBOSE] Sign In Response Dump
--------------------
wcontext = ba960bdd-5874-411c-b19e-6db22f9eae20
wresult to follow
XML Data Follows
----------------

Here is a snippet of the log when they enter the URL directly into the address bar (success).  Note that I replaced our URLS in this log with a <url> escape sequence.

2010-02-02T17:53:14 [COOKIE] READING (/) - _AdfsWctx7b403390-c594-42a3-b761-9e6e291b36db=https://<url>
2010-02-02T17:53:14 [VERBOSE] Loaded context https://<url> from cookie.
2010-02-02T17:53:14 [INFO] Loaded context https://<url>.
2010-02-02T17:53:14 [VERBOSE] WebSSO data has been received in the POST body.
[VERBOSE] Sign In Response Dump
--------------------
wcontext = https://<url>
wresult to follow
XML Data Follows
----------------

To me, this indicates that there is a problem with the cookie being sent from the resource server to the claims aware application.  The agent also dumps out the SAML token immeidately after those statements in BOTH cases; however, I haven't been able to notice any differences between them except for GUIDs and timestamps.

Has anyone encountered this problem?

Can you use Fiddler to get a header trace of the problem? That might help. This bug is related to the recent hotfix to ADFS that changed the behavior of how the wctx parameter is used to implement URL retention for deep linking. There was a serious security flaw in the previous implementation.

It sounds like the cookie is getting dropped somehow during a switchover from Office to the browser, but it isn't exactly clear how or why.

You may end up needing to talk to MS support on this issue. They've been fielding many inquiries related to the patch.

I took a closer look at the IIS logs for the application I'm trying to get to and found some interesting things.  Take note of the client IPs in the failure case.  I added some comments to each request at the end of the line in bold/italics.  Again, I removed IPs and replaced as follows:

<ServerIP /> = application IP
<ClientIP-A /> = client IP when MS Word makes the [initial] request
<ClientIP-B /> = client IP when IE makes the request

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken

Starting from MS Word (failure):
2010-02-03 13:46:23 <ServerIP /> GET / - 443 - <ClientIP-A /> 302 0 0 1937 MSWord makes request and the claims aware agent detects no token so redirects to FS resource server URL, but first establishes a context via a cookie
2010-02-03 13:46:29 <ServerIP /> POST / - 443 - <ClientIP-B /> 302 0 0 125 IE POSTS back a token generated from the resource server.  Cliams aware agent cannot extract the context from the cookie and redirects to an error page within the application.
2010-02-03 13:46:29 <ServerIP /> GET /Error.aspx aspxerrorpath=/ 443 - <ClientIP-B /> 302 0 0 125 IE attempts a GET of the error page, but it also requrires authentication and we redirect back to the FS resource server, which ultimately stops this process and displays an error page that does not require authentication

Starting from IE (success):
2010-02-03 13:47:51 <ServerIP /> GET / - 443 - <ClientIP-B /> 302 0 0 125 IE makes a request and the claims aware agent detects no token so redirects to FS resource server URL, but first establishes a context via a cookie
2010-02-03 13:47:55 <ServerIP /> POST / - 443 - <ClientIP-B /> 302 0 0 1156 IE POSTS back a token generated from the resource server.  Claims aware agent extracts the context correctly from the cookie and redirects the user to the appropriate URL they originally requested.

Also, the user agent for ALL requests appear to be identical and all start with:
Mozilla/4.0+(compatible;+MSIE+7.0;

So, my question is, where does the cookie go that gets generated by the claims aware agent in step 1 of the failure case?  Which process owns the cookie (word or IE)?  Seems like this is a GOOD thing that the problem is occuring from a security perspective; however, it would be nice to know why the source IP from the MS Word request is different.  Note that my desktop is behind firewalls and proxies and that <ClientIP-B> is the proxy server configured in IE.

I think the problem is that Word gets the set-cookie header in the 302 from the web app but then when it "switches" over to continue processing the 302, IE starts with a clean slate and loses the cookie. This would not be surprising if IE was a separate process from word since session cookies don't cross process boundaries (except in IE8 which is a little weird and interesting in that regard).

The fiddler trace will verify the behavior of the client.

Unfortunately, I'm not sure what (if anything) you can/should do to fix this. You might need to open a case with MS to get a real resolution. They'll probably want to the Fiddler trace though so go ahead and try to get that. It is the most useful tool for debugging this stuff by far.

I have no idea if the mix of IP addresses is relevant or not. Interesting that the client thinks it has two different ones and the different user agents select different values. :)