In an earlier post, I ranted how opening Office documents (Word, Excel, PowerPoint) from SharePoint is a pain when you are using SharePoint from a different domain than your computer is logged in to. We finally found a workaround, which now seems obvious. Here's a review of the situation:
If your Windows machine logs into Active Directory domain "Homer," but the SharePoint site you access is on the domain "Lois" in a different location, you have to deal with login prompts instead of a streamlined integrated login. This is expected behavior.
In addition, Word, Excel, and PowerPoint documents opened from SharePoint need to authenticate the user as well, because the documents are actually opened from the web server, not the local browser cache. This is also intended functionality: the idea is that the user can edit the files and save them back to the server directly from Word, Excel, or PowerPoint. The user must type their username and password when each separate Office application is opened via the link for the document in Internet Explorer. Usually this is not a big deal.
However, opening documents from a SharePoint site in Internet Explorer is sometimes impossible when a third-party single-sign-on system is in place and the user doesn't actually have the Active Directory username and password handy. If the SSO doesn't know how to handle Office applications, it's impossible to open the files at all because they get stuck at the SSO login process. A workaround is to have users right-click the documents in SharePoint and "Save as," but chances are users would not get the message or forget.
So we finally came up with a workaround while we wait for a permanent solution via the SSO: Convert all Office documents to Adobe PDF. For documents that need to be available in the native Office format (.doc, .xls, .ppt, .vsd, etc.), compress them as .zip files. Use the .pdf and .zip files in the document libraries instead of native Office files.
This can work well for sites where SharePoint isn't being used for document collaboration, or where collaboration doesn't rely heavily on document editing. As far as I know, there's no other way around this problem other than converting the documents to non-Office formats or using a browser like Firefox, which doesn't try to open Office documents for editing from the web server.
We will figure out a permanent solution, but for the meantime the workaround will suffice.
Subscribe to:
Post Comments (Atom)
Posts
37 comments:
Has anyone checked with the Microsoft Team to see if they have a solution for this?
Not directly. There wasn't anything I could find online.
I will try to hunt down the right person to ask.
Mmm. Only for Word, including version 11 (2003), http://support.microsoft.com/?kbid=324328 seems to solve the problem, which would indicate this is a client problem. I can not find similar keys for the other Office products.
However, the IIS over HTTPS will show only to accept Basic Authentication, since Windows Integrated won't get through the firewall, indicating it is a server problem.
These opposites puzzle me. Are they both true? Then why does the registry hack work for Word?
Who can shed a light here?
It's definitely a client problem, though it also depends on how the web browser provides the document. IE makes Word open the document from the server. Firefox makes Word open the document from the browser's cache, eliminating the login prompt (and any collaborative features).
Fixing registry keys is out of the question for us--this is an extranet deployment, so we don't have control over any users' desktops.
Our answer will need to lie in fixing the SSO to handle authentication when files are opened through Microsoft Office applications like Word.
so if the user is not able to open the .xls file from the SharePoint website, I will have to convert all of her files into .pdf or zip them up and only then she might have a chance to open it? How come I am not running into this problem with other users and they have no problems opening the file from SharePoint? Is there another workaround for this?
If your users are all part of the Active Directory domain in Windows, log in to the domain with their domain accounts, and access the site in Internet Explorer and Office 2003, you probably won't have any issues. This typically is the case on an intranet.
This problem I have described happens if your user is outside of your Active Directory network, typically if your users are not part of your domain use computers outside of your company's firewall. Alternately, this may occur if you use some sort of single-sign-on (SSO) system that overrides Integrated Authentication in IE and Office applicaitons.
You don't necessarily have to convert the files. This is just what we decided to do.
An alternative is to have users right-click and select "Save target as..." to save the file locally, then open it. That works to, but requires instructing the user and/or training.
I'm a new user to Sharepoint so I apologize if this question is elementary for you. What it happening when a Sharepoint user cannot open an a file in Sharepoint that was created in Excel format? He has the permissions to do so, but he gets an error message when trying to open the file. Thanks for your help
Hi Mary, What error message is your user getting? How is the user opening the file?
Saw this post and your workaround. Is there any other technical documentation explaining this problem?
I have not found anything, no.
Following up question on this blog....
Will WSS 3.0 / 2007 solve the issues of the login promt requirement when opening a documnet in IE?
Kevin, I am looking into this.
Anyone have any luck with this. We've just put up a WSS 3 site and want to use it for an extranet scenario and users don't like the extra logins.
I have not been able to try it myself, but I believe if you are using forms authentication or anything other than integrated authentication, Office applications cannot automatically authenticate. So I would assume you are stuck in needing each application to re-authenticate.
However, I have not tested this so if anyone has please let us know!
Here's some intel I got from Stefan and Spence: If using persistent cookies on an extranet (non-Integrated auth) for WSS 3.0, the documents open in Word, Excel, etc. as editable.
I haven't tried it myself but it's worth a shot!
Thanks joelsef
The workaround is just that ... a workaround! Now consider how you might work with this in an educational setting, where each computer may have up to a dozen users in a day. No chance to locally store the username and password.
This is a real show-stopper for education, who are looking for as few barriers to learning as possible. It doesn't take a genius to work out that this compeomises single sign-on, and adds to teacher workload.
Regardless of the technical reasons, it just shouldn't be so. How can this be a valued feature when it is so obstructive?
This is a serious issue that compromises the usefulness of the MOSS 2007 architecture for education!
There are quite a few portals for education that don't have this problem. This needs a real solution and a recognition from Microsoft that this is a 'naf' feature that needs to be sorted quickly ... or lose customers!
hi joel i was wondering when we open a document..from where the contents are displayed.. in case of checkout the documents gets cached in temporary internet files...but i do not see it in case of open..does it get displayed directly from server...i would really appreciate your great help..thnks in advance...
AFAIK, the document is always "opened" from the server but it should be cached locally somewhere in Temporary Internet Files. That said, I am not 100% sure how IE and Office handle it.
Hi,
it is unbelievable... To fix this problem you should use Mozilla Firefox as browser, as the Microsoft browser doesn't work as it should...
However, when using Firefox, other features seem to be disabled (I get messages all over the place as 'requires a Windows SharePoint Services-compatible application and Microsoft Internet Explorer 6.0 or greater.')
So, Firefox is great for opening Office documents without getting the annoying password prompt, but it seems to be locked out by Microsoft for some other functions, which is a pity.
Anyway, I hope Microsoft comes out with a fix for this annoying password prompts all over the place. This is really a show-stopper in demos, and it is really not appreciated by my end-users.
Moreover, I am getting this password prompt over and over again also in my Outlook 2007 client, as some SharePoint lists are added for synchronisation reasons. Is there also no solution to avoid this?
You can completely get around this by publishing your Sharepoint from behind an ISA 2006 server when in Form Based Authentication.
When you publish using Form Based Auth and select "Private Machine" at login, you will be given a cookie that both IE and Office will read that will authenticate you to the AD/Sharepoint for each request.
You will no longer need to re-auth each time you go to open or save a document. Even if you navigate out of sharepoint and back you don't need to log in again. Only if you completely close your IE which will also clear the cookie do you need to sign in again.
What if you don't want to implement ISA? We only use this for intranet but I still can't find reasonal solution MOSS 2007...
In order to resolve that issue, you nedd to add the domain to the intranet zone in Internet explorer. You also need to activate the use the integrated logon feature in Internet Explorer. You can do both in the security tab.
I tried doing the intranet settings and pass through auth. It didn't work for our sharepoint sites.
Do u find another solution for this problem until now ?
Unfortunately, I have not.
Reinstall MDAC components
http://www.eggheadcafe.com/software/aspnet/29196156/files-opening-in-readonl.aspx
http://support.microsoft.com/kb/287402
We have found that if it is an intranet zone and sharepoint does not necessarily have to have authentication then you can change your browser security settings for the local intranet zone for user authentication | logon to Anonymous logon. And then no more annoying dialogue box. Looking for a reg hack to push out to 2000 machines though.
Found the solution at a microsft site for the reghack. Here it is:
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]
"1A00"=dword:00030000
Just an FYI we have ISA 2006 and we have similar problems - the bottom line is client integration does not work with external partners!
right click save as. get a clue MS fix it!
These are old posts. Is there a recent fix that MS has brought out?
Hey Anthony, have you read the MSFT SPPT blog regarding FBA patches in early May?
I believe MS has an explanation take a look at this:
http://support.microsoft.com/kb/871155
Unfortunately, the fix listed did not solve the problem of having to reauthenticate when opening an office document on a sharepoint server. If anyone knows of a fix, please list it here.
It's a problem related to Security Trust Center on each Office 2007 program.
Please try this:
Meke a Registry file with this data:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains]
@=""
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\mydomain.com]
"*"=dword:00000001
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Security\Trusted Locations]
"AllowNetworkLocations"=dword:00000001
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\PowerPoint\Security\Trusted Locations]
"AllowNetworkLocations"=dword:00000001
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Security\Trusted Locations]
"AllowNetworkLocations"=dword:00000001
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Security\Trusted Locations]
"AllowNetworkLocations"=dword:00000001
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Security\Trusted Locations\Location12]
"AllowSubFolders"=dword:00000001
"Path"="http://test.mydomain.com/SiteDirectory/"
"Description"="SharePoint 2007 SiteDirectory"
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\PowerPoint\Security\Trusted Locations\Location12]
"AllowSubFolders"=dword:00000001
"Path"="http://test.mydomain.com/SiteDirectory/"
"Description"="SharePoint 2007 SiteDirectory"
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Security\Trusted Locations\Location12]
"AllowSubFolders"=dword:00000001
"Path"="http://test.mydomain.com/SiteDirectory/"
"Description"="SharePoint 2007 SiteDirectory"
(you must to replace test.mydomain.com by your website)
(you must create new locations belong to diferents web subfolder)
Has anyone tried this registry hack and does it work?
To solve this problem , you can , force checkout of the document and then click the edit document. This will prompt you to check in the document when finished editing it.
Post a Comment