Wednesday, 30 July 2008

Vista Problem Accessing Office Documents from SharePoint Document Libraries That Are Published Using ISA Server 2006

After recently upgrading my own work laptop to Windows Vista, I have been experiencing problems accessing Microsoft Office documents that are contained in SharePoint libraries which are published by ISA Server 2006. I have quite a lot of experience with SharePoint publishing and these problems appear to continue even when ISA Server is configured to utilise persistent cookies and all other ISA Server publishing configuration elements are correctly configured.

After quite a lot of investigation, it appears that a change has been made in Vista that alters the way that documents are accessed from SharePoint libraries. This change now utilises the Web Client service included with Vista (which acts as s WebDAV redirector). I think this is where the problem begins, as this service does not appear to support persistent cookies in the same way as other Office applications. Consequently, when trying to open Office applications you are now prompted to provide authentication details as ISA Server interperests the request as a new anonymous connection because the persistent cookie is not being used.

An example extract from the ISA Server logs is shown below:


After a bit of investigation of the ISA Server logs it can clearly be seen that this behaviour has changed for Vista machines compared to Windows XP; with the Web Client service enabled the ISA Server logs shows several denied entries for anonymous connections using a WebDAV client agent. Comparing the behaviour with my Windows XP SP2 virtual machine, documents are accessible seamlessly by way of the persistent cookies and the ISA Server logs show the standard Microsoft Office/12.0 client agent.

An example extract from the ISA Server logs is shown below:

At this time, the only way I can solve the problem is to stop the Web Client service on my Vista machine and add the SharePoint external URLs to my trusted sites. Upon doing this, I can open documents seamlessly (just like on my Windows XP SP2 VM) and the client agent in the ISA Server logs shows Microsoft Office/12.0 or Mircosoft Office Existence Discovery client agents as opposed to the WebDAV one.

Bizarrely enough, I have also found that if you cancel the password prompt the document will actually open. From looking at the ISA Server logs, it appears that when cancel is pressed the client falls back to the historic method and starts using the Microsoft Office/12.0 and Microsoft Office Existence Discovery client agents. This can be seen below:

However, with the Web Client service disabled, I can now no longer open a document in Read-only mode and then click the Edit Document link in the document information bar. This is not essential, as I can still open document in edit mode by using the Edit in Microsoft Word option from the document library interface, but this is potentially quite annoying for unknowing users.

I am not sure why the Web Client service is not able to consume the persistent cookies in the same way of Office applications, but until it can, I cannot see a clear way to provide a fully functional solution with Windows Vista. I could of course just tell people to click the cancel button when prompted are prompted for credentials, but this is not really an elegant solution! :)

Any ideas or suggestions, please comment!

Please Note: During my investigation I have tried the fix detailed in KB943280 but I have come to the conclusion that this fix is for a different problem although it appears to have similar symptoms.

8 comments:

  1. Thanks a lot for a very interesting issue, Jason. It's really stange behavior of web client in Vista.

    ReplyDelete
  2. Hi JJ,

    excellent posting.I have similar problems using WinXP SP2/SP3 Clients. Your article gave me some hints to investigate the traffic a little bit deeper using a Network Monitor and trace the log files on ISA. If there´s some time left you should publish a guide or “Best Practice” how to publish Web Server Farms (i.e. Project Server 2007, MOSS2007) via ISA 2006 showing the different authentication methods on the publishing servers and what type of ruleset you apply on ISA.


    Best Regards,
    Roland

    P.S.: Thanx to Jens Baier posting the link to your blog

    ReplyDelete
  3. If you use Kerberos it won't have this problem. I am a using this case in our place and have tested on my laptop with Vista Home and it works fine.

    ReplyDelete
  4. >>esad

    I am curious how you would use Kerberos authentication over the Internet when SharePoint is published via ISA Server 2006?

    Keberos relies upon having access to the KDC server which is not really practical across the Internet...

    I have no doubt the issue does not occur internally.

    Can you explain further?

    ReplyDelete
  5. >>Roland

    I think there are already quite a few guidelines on publishing SharePoint with ISA Server, so I have tried to concentrate on the elements that are not documented.

    I have started to look at using the same approach that I have used for Outlook Anywhere and apply it to SharePoint so that I can enabled transparent authentication for external users. However, not being a SharePoint guy, the kerberos requirements seem a bit more difficult than for Exchange. This is on my "to do" list though!

    ReplyDelete
  6. We had users who had similar issues with this scenario. I got them to apply the http://support.microsoft.com/?id=943280 fix but also make sure that they also delete any existing Stored Passwords on their machines. (Start | Control Panel | User Accounts | Manage User Accounts | Advanced Tab | Manage Passwords ). This has seemed to work for us.

    ReplyDelete
  7. >> ViewState

    Intersting, I think I included that fix whilst doing my testing, but I will do a quick review to make sure.

    Are you sure it is the same issue though? Do you get the same ISA log entries?

    Cheers

    JJ

    ReplyDelete
  8. Hi Jason,
    I have multiple questions (all related to the goal of securing the corporate data by ensuring we connect via trusted client machines, bear with me...)
    1. First of all does this work with Exchange 2003? I have not been able to get confirmation on KCD fully supported with with Exchange 2003 with Outlook 2007 RPC/HTTPS other than in Thomas shinder’s http://www.isaserver.org/tutorials/Configuring-ISA-Firewalls-ISA-2006-RC-Support-User-Certificate-Authentication-using-Constrained-Delegation-Part2/.html. Here is appears it is not Microsoft supported.
    2. Secondly, I'm a little confused about the comments on non-joined machines being able to receive the prompt: that would be insecure as we are back to any client on the internet being able to connect. I contacted Microsoft, who indicated "KCD will still allow users to log in from any client". So our company's security goal is to prevent access from ANY old client (read, my home pc) and only allow corporate imaged pcs, i.e. domain members with cached credentials. My understanding of KCD is that it must be with a domain member machine, which is the whole reason for going to KCD.
    3. Comment by above reader: "Of course, for non-domain joined clients the logged on user wouldn't have valid AD credentials in the first place. But previous poster's suggestion of saving the username/password in the User credential cache will work" suggests we can now bypass the whole transparent KCD setup. What's the point then??(sorry said in frustration, not at your comment)
    4. Are user certs not involved in KCD as well? I asked Microsoft, and who seemed to indicate certs were only usable in a IAG/UAG scenario: "I also talked to our IAG/UAG team and the only way to use certs to authenticate would be to setup a SSL VPN.” Shinder’s article suggests certs are optional.
    Your thorough article suggests KCD is doable for what I want to accomplish, but Microsoft and some readers are saying otherwise.
    Thanks for any input.
    Mike

    ReplyDelete