Monday, February 2, 2009

Office Applications and their Interaction with SharePoint Document Libraries

One of the cool things about Office 2007 applications is that you can work with SharePoint document libraries from directly within the application. For example, if you click on, say, a PowerPoint document in a document library and open it directly without saving it first, Office will make a connection to the document library and give you additional functionality. Things like the Document Management task page, the enhanced save as dialog, etc. all use this voodoo magic to make your interaction with SharePoint seamless from with your application.

It’s all fun and games while everything is on the same side of the router – as long as you and your SharePoint server are all in an intranet scenario, everything works together nicely and seamlessly – you authenticate once against the SharePoint server, probably using the same domain credentials you used to log onto your own machine, open your document, work with it, save it, manipulate your document library, whatever – all without having to re-authenticate.

What happens when you and your SharePoint server are separated by a router – an extranet scenario? That’s where things get a little dicey. I recently helped set up such a system by exposing a SharePoint site to the internet using ISA Server 2006. I plan to go into detail on how I set this up in a future blog, but for now, know that ISA handles all the authentication using LDAP connections to active directory, and users are then authenticated to SharePoint using NTLM from ISA to the SharePoint server. The login is done with Forms authentication on ISA, and Office applications have no problem performing their own voodoo magic to recognize ISA’s form prompt and turn it into a regular windows prompt when the need arises.

One of the first things my client noticed during testing was that even though they had logged in to the system already, when they opened office documents, they were getting prompted for credentials again. Twice. That’s right – two prompts for credentials, after already logging into the SharePoint server.

Since this was the client and I did most of the ISA server configuration to get this site on the internet, it was up to me to figure out what was going on. As it turns out, that voodoo magic I was actually speaking of that works quite well on the intranet causes all kinds of extra network calls on the internet that are guaranteed to confuse users when they encounter them.

The first thing I did was turn on monitoring in ISA server to find out what was causing the prompts to appear. I tested with a PowerPoint document, but the same problem exists with all Office applications. I ran several experiments to try to figure out what was causing the two prompts to appear, with various combinations of entering credentials and canceling the prompts without entering credentials. Here’s an ISA log entry for the file trying to be retrieved on the first prompt:

Allowed Connection

Log type: Web Proxy (Reverse)

Status: 404 Not Found

Rule: My SharePoint Extranet Rule

Source: External (555.555.555.555)

Destination: (mysharepointsite.mycompany.com 777.777.777.777:443)

Request: POST http://mysharepointsite.mycompany.com/_vti_bin/shtml.exe/_vti_rpc

Filter information: Req ID: 08843636; Compression: client=No, server=No, compress rate=0% decompress rate=0% ; FBA cookie: exists=no, valid=no, updated=yes, logged off=no, client type=unknown, user activity=yes

Protocol: https

User: (LDAP)myusername

Additional information:
1.Client agent: MSFrontPage/12.0
2.Object source: Internet (Source is the Internet. Object was added to the cache.)
3.Cache info: 0x40000008 (Request includes the AUTHORIZATION header. Response should not be cached.)
4.Processing time: 16 ms

The first thing that caught my eye was the client agent: MSFrontPage. I thought we were done with FrontPage already with the rename to SharePoint Designer, but it turns out this was something else. Look at the request – it’s a POST for /_vti_bin/shtml.exe/_vti_rpc. The Google tells me this is a test to see if the site supports FrontPage Server Extensions. A little more research tells me that when Office applications access files in a SharePoint document library, the first thing they do is check to see if the server supports FrontPage extensions. In my case they don’t, but the file PowerPoint is trying to post to exists on a secured server, being accessed over the internet, from a machine not on the domain. Yep – that’s going to require credentials. And there’s no way to turn it off.

So fine, you enter your credentials, hit OK, and PowerPoint tries to open your file. But wait – you’re prompted again! “Didn’t I just enter my credentials” you say to yourself. And you’re right, you did, but Office wants to make extra sure you are who you say you are. Or something like that…

What Office is actually doing is making another connection to the server with a different Client Agent. The credentials from the failed FrontPage server extensions do nothing to help avoid this prompt:

Allowed Connection

Log type: Web Proxy (Reverse)

Status: 200 OK.

Rule: My SharePoint Extranet Rule

Source: External (555.555.5555)

Destination: (mysharepointsite.mycompany.com 777.777.777.777:443)

Request: OPTIONS http://mysharepointsite.mycompany.com /

Filter information: Req ID: 08843643; Compression: client=No, server=No, compress rate=0% decompress rate=0% ; FBA cookie: exists=no, valid=no, updated=yes, logged off=no, client type=unknown, user activity=yes

Protocol: https

User: (LDAP)myuseraccount

Additional information
1.Client agent: Microsoft-WebDAV-MiniRedir/6.0.6001
2.Object source: Internet (Source is the Internet. Object was added to the cache.)
3.Cache info: 0x42220008 (Request includes the AUTHORIZATION header. Response includes the CACHE-CONTROL: PRIVATE header. Response includes the CACHE-CONTROL: MAX-AGE or S-MAXAGE header. Response includes the SET-COOKIE header. Response should not be cached.)
4.Processing time: 47 ms

 

This is the actual magical connection that is going to allow Office to do it’s document library voodoo – good old WebDAV. Or a version of it anyway that appears to be specific to SharePoint.

Ok, so now that we know what the prompts are for, what about supplying credentials for what we’re actually trying to do – open a file. Remember the file? It turns out that you need to enter your credentials on one of the two prompts, it doesn’t matter which one, in order to access your file. The second prompt has the added bonus of giving you access to the document library, but either one will suffice for gaining access to the file. If you hit cancel on both dialogs, you won’t get access to your file.

Unless of course you’ve already successfully supplied credentials during your current session (since the last time you logged on to the computer you’re using to access your document). If that’s the case, your credentials are cached, and you can click cancel to both prompts and still get access to your file. I’ll wait while you scratch your head…

So, the first time you access a file, you have the following four combinations of options:

Cancel both dialogs No access to file or document library
Enter credentials in the first dialog, cancel the second Access granted to the file, not the document library
Hit cancel on the first dialog, enter credentials in the second dialog Access granted to the file, access granted to the document library.
Enter credentials in both dialogs Same as above – Access granted to the file, access granted to the document library

If you look over those options closely, something may jump at you – you can always click cancel on the first prompt. If you get prompted a second time, enter your credentials there. I say If you get prompted a second time, because that second prompt may not be necessary if you’ve already entered your credentials during your current session.

Another way to avoid having to enter credentials into that second prompt is to add an entry in your network passwords:

  • Go to control panel >> user account >> manage your network passwords.
  • Click Add
  • Enter the name of your SharePoint server and your user credentials
  • Select “A web site or program credential

Note these are instructions for Vista, but I believe something similar works for XP.

You’ll still get that first prompt when Office tries to determine if FrontPage extensions exist on the server. If anyone knows how to get rid of that prompt, please let me know.

5 comments:

  1. Wow - I struggled with exactly this problem about a year ago, and searched extensively at the time for a solution without success. I didn't look as closely as you have at the ISA monitoring, but you explanation makes sense. I originally thought that I could bypass this issue by using NTLM authentication, thereby passing the cached credentials of the user to Sharepoint and avoiding a login request. The problem I had was that ISA can't delegate NTLM authentication requests (something about a double hop), so I was restricted to forms auth. The problem you highlight is that in place of forms authentication, applications which can't support it (ie Office suite for open from sharepoint), ISA will revert to basic auth - hence the login request that won't save the password. I'm about to set up a new MOSS install, and am thinking of trying this again. So I'll let you know if anything else is possible. I'm going to try direct NTLM auth without ISA (NAT ports through our Cisco router).

    ReplyDelete
  2. This has been an interesting series certainly going a level below the rest of the blogs out there. Does the multiple go away with an ISA server setting ? or is the way to avoid this issue to use a more intelligent switch

    ReplyDelete
  3. Hi! Very interesting - I am trying to learn the woodoo... I wonder how to create an item in a document library and attach a document stream I have created AND allow the user to to save the document in the library or cancel it (and hopefully the item is deleted automatically).

    ReplyDelete
  4. Thanks for the information.
    Can i get rid of the prompts without setting in control panel. Did you find any solution for htis. if so please let me know. iam also facing the same problem and the clients are frustated with this prompts.

    Thanks in advance.

    Anu

    ReplyDelete
  5. Anu - you can get rid of the prompts by switching to Office 2010 on the client.

    Roger - As far as I can tell, there's nothing you can do in ISA to make this issue go away. Switching to Office 2010 on the client does seem to work (more testing required - something else may be going on), which leads me to believie that this is/was a bug in the office client software all along.

    ReplyDelete