I very often get cases with the question:
“Why do I have to logon each time when opening a office Document from a SharePoint Library when I’m already authenticated via the browser?”
Well, first of all, the “Multiple logon prompt issue” can occur for al lot of reasons. It depends either on the version of Operating system (Client), Office version and some more circumstances like using ISA Server and FBA, coming from extranet or intranet etc.
So regardless of any special configurations or infrastructure, I’ll try to explain the native process and why we get another logon prompt when opening an office document inside a SharePoint Library.
- Trusted Client – A trusted Client is a computer with a logged on User that both is member of the domain the SharePoint resides. Since we use “Windows integrated authentication” the credentials of the “trusted client” will be passed through. The browser session cookie authenticates against SharePoint and the Office documents will be opened without further authentication request.
- Untrusted Client – A untrusted client is any computer outside the local network that is not member of the domain the SharePoint resides. If you are attempting to gain access, your system is considered untrusted, until you log-in as an authenticated user of that domain. A browser session cookie with the domain credentials will be established and you can now browse inside the SharePoint.
When you access a office document from a library as an Untrusted Client (even though your login credentials are already authenticated by the browser session cookie) when an Office Application opens, IE does not pass authentication/trust/token to the next application to gain the same access that is already trusted with IE. The additional log-in prompts is because the documents opened with Office 2003/2007 are trying to re-establish a trust per application, because the client machine is not trusted from a public web and a new authentication is requested.
This “by design” and you’ll have at least two logon prompts in such a scenario,
1st for the browser to access the SharePoint site,
2nd for the office application when you open a document from a library.
If you once have opened an office document and you do not close the application completely but just the document, the office application is still authenticated (after the 2nd logon) and you can open any other document without further prompts. But this is only a simple workaround and may not be applicable le in all cases.
We have published very detailed KB Articles that you may read to get a complete description and some recommendations on how to deal with this as far as it will be applicable:
Office: Authentication prompts when opening Microsoft Office documents
How documents are opened from a Web site in Office 2003
Persistent cookies are not shared between Internet Explorer 7 and Office applications in Windows Vista
Some related posts from my archive will also give some more information:
SharePoint and Office integration
Office 2003/2007 Integration and Forms based authentication (FBA) with SharePoint (MOSS)
From the ISA Blog:
Unable to “Check Out” a Document in MOSS 2007 Published Through ISA Server 2006
Understand duplicate authentication prompts ISA 2006 publishing MOSS using FBA
24 thoughts on “Multiple Logon while open office Document from SharePoint”
Hi Chris Buchholz,
I don’t know how to fix this in WAP but you may check out the referneces for ISA/UAG/TMG and figure if this is maybe based or cuased by sticky session settings and/or persistent cookies etc. please find the respective advises on those blog posts and try to
transform it in your WAP settings. If this isn’t possible or not applicable, then please open a MS Support case to check this further.
I know this is old but .. is there any way for us to get around this for private computers? This is our extranet so the computers are at people's desks at their companies. We are on WAP over SharePoint 2013. UAG did not force users to enter credentials
every time, but now on WAP this is happening and driving my users crazy.
We have issues with Office 2007 documents on IE 11 when accessing SharePoint 2013 on premise intranet site. Any resolution for 2013?
Its a known issue and there could be multiple causes for SharePoint Keeps Asking for Password Every time. As stated, Try adding your site to "Trusted Sites" list in Internet Explorer as the first step.
Find other possible workaround to fix this issue at: http://www.sharepointdiary.com/…/sharepoint-keeps-asking-for-password.html
Thanks AJ,your solution was fine.I get it work.
Solution IE 9 SP 2007
This is a web client security issue, and no need to change code or registry settings and simply email the below steps to your users.
1. Add site to trusted sites
2. next click custom level
3. check 'display mixed content' to enable
4. Automatic logon with username and password
"By Design"?? So Microsoft decided that, after you are logged into a site, login prompts should come up every time users open documents? I know they neglect a lot of obvious things, but to say they specifically designed this work in this way is rediculous!
Is there a combination of Operating System and office Version in which I can open Office Documents from a document Library within Sharepoint Foundation 2010 from an "Untrusted Client" without being prompted or credentials?
My solution was a combination of using the Trusted Sites with a minor change in addition to a registry change. Both changes can be rolled out using a GPO http://www.networkadminsecrets.com/…/sharepoint-2010-authentication-prompts.html
It seems to me that this only happens when IE is the browser. If, for example, you are using Firefox and you click on a link to open a document, Firefox will download the file first and then use the Windows open file protocol to launch the file.
This may have other restrictions, though, such as not being able to save the document back to the web site.
I think that what would be helpful would be if there was *any* way of getting IE and Office to open the documents without multiple prompts. For example, would client certificates make any difference? In other words, are there *any* scenarios where this can be overcome for disparate domains, i.e. SharePoint in one domain and the user (and their computer) in another domain without a trust in between?
I'm running into this "issue" now with a new Sharepoint environment. What's interesting, is that if I choose to go ahead and enter authentication information, the prompt will come up 3 or 4 times in a row. If I just hit escape, or close the window, the authentication box closes, and the document opens anyway. I've tested editing, and bypassing the login box will allow me to check out the document. When I go to save, or check it back in, the login box will appear again, at which time I can just bypass it again, and it saves the document just fine. This is a very strange problem…
this is unbelievable. how is this supposed to be a workable extranet solution. users are not going to go for entering their password dozens of times a day every time they want to work with a document. ridiculous!
Actually there is another underlying issue that I found – when you click on the link the interaction mechanism tries to query the web server using an HTTP OPTIONS request to get capabilities of the server – unfortunately the URL is to the actual library path and SharePoint forbids these and responds with an http 401 – to which the Office app automatically responds in the UI with a credentials prompt. In certain scenarios cancelling this prompt then allows the office app to go away, download the actual file requested – other times it seems to prompt again and again until it abandons the whole request. This seems to be some kind of nasty behaviour in the Web Client service.
I leave my own solution to this:
Hope it helps.
I cant provide any suggestions if there is no specific description on what exactly is not working or might be wrong.
SharePoint 2013 user experience might be limited with Client version of Office 2007.
Have you tried to repro your problem with Office 2010 or even Office 2013? still same issues?
Are you passing any TMG/UAG or ISA Servers to reach the intranet sites??
These and many more questions may be sorted by a support engineer with a full scope of the entire environment and all involved components.
sorry but you should open a support case with Microsoft for this as it could easily getting quiet complex.
To disable login prompt opening office documents from SharePoint 2010 do the following settings in web.config
<add verb="OPTIONS" allowed="false" />
<add verb="PROPFIND" allowed="false" />
thank you for your comment. AFAIK, this is not enough to get it working in IE8/IE7 but would be a try worth ;-)´
Unfortunately I havent had time to test it entirely in all depth but would be interested in getting the results!
So if anyone out there has the passion to test it, please add your comments here too,
thanks and cheers, Steve
RE: Steve [MSFT]
Hey thanks, its a good forum post with some other links but this one is also some kind of related:
If you cannot find or troubleshhot deeper, its worth to open a support case at MS Support for further assistance as those issues are mostly relying on several circumstances and/or combinations, not limited to only one failing point 😉
I'm very sorry aout your anger ut there is always a edge walk between "usaility" and "security". The multiple prompts are caused for several reaseons, mostly relying on the settings and cross-application process and its communication. For i.e. for security reasons the IE does not share the session cookie with the office word process. When using word, a new, separate process is created which could e as well any maliciuos process that would then e ale to use a shared cookie to compromise your network. So you may see, that if you prefer an easy and smooth way to connect from external to your network, you might consider what will weigh more: Your convinience or your intended security?
Would you give anyonymous access to your internal SharePoint and thus maye sensitve content for everyone?
– got the idea?
Hth Cheers – Steve
thanks for your adds, I think the described behavior depends on what client OS and office version you're using…
There are different behaviors when accessing office documents from XP, Vista/Win7 and/or the combination of the each office and OS version…
So you should tell us also the information, for what configuration and combination you expirienced this odd issue.
thank you for your effort and a "workaround" 😉
But please bear in mind, modifying the "core.js" is just working as long as we do not patch this file (which happened already once on the early post SP1 updates!). So in case we do overwrite the core.js in a future update, then you must reenable your workaorund manually!
just my2cents to answer 😉