The company I work for is using SharePoint as a CMS for it's public facing website. I recently enabled FBA (Forms Based Authentication) for the site in order to provide some user specific functionality, but this has caused a side effect with Word / Excel files when opened from the site using Office 2007 / 2010.
Some users are challenged for authentication when opening a Word / Excel document from IE (but not when they're select "save file" instead of "open file"). A window pops up behind IE / Word / Excel (so you often don't realise it's there) showing the sites login page. If the window is dismissed then the document continues to open normally.
It seems to be environmental. Most Office 2007 / 2010 users internally experience this and we've had one report externally of this happening.
Anyone know how to prevent this behaviour?
In case it's relevant: The company also has an internal SharePoint site using NTML authentication allowing internal users to edit the same content visible externally.
I originally suspected the SharePoint header added to responses may be alerting Office to check for authentication to allow extended functionality, but I remove the response header in IIS and it didn't make any difference.
In the Authentication Provider for the FBA enabled site, do you have Enable Client Integration? set to Yes?
Central Administration > Application Management > Authentication Providers > Edit Authentication
Related
We have a site used by Outlook addin hosted on sharepoint, when a user tried to access it they had a browser window open on the Sharepoint Online site, our front end is hosted there but it doesn't bring us to site location it just brings to Sharepoint home page.
We resolved this for a lot of users by adding runtimes in our manifest (this will force Outlook to use IE, whereas before browser is determined on a combination of 365 and windows versions). Still for some users it will bring us to a new browser, we have checked they are on the same Windows and Office 365 version as others who have the plugin working in Outlook task pane.
Also to note there is no issue with anyone using the plugin from OWA (web mail in a browser) and the redirect from desktop outlook looks like it for SSO then verifies user in browser and brings us to Sharepoint.
anyone have any idea what could be causing this?
The problem was caused by any sites or domains trying to be accessed by outlook addin need to be added to app domains in the manifest file. We ran a fiddler trace on the users machine and took a list of the domains that were being hit (for SSO) once we added them this issue was resolved.
Our environment is Sharepoint 2010, with a web application created (and site collection on top), using claims based authentication. The first site is using port 881. It is using integrated windows authentication. Another web application is created, extending the first application, using port 882. This site is using Forms Based Authentication, the membership provider is System.Web.Security.ActiveDirectoryMembershipProvider, named admembers. I have turned off Client Integration on both sites.
When I login to the 881 site, on my corporate network, logged into the machine with the same domain account that sharepoint uses, I can open an Office file saved in a document library, and it subsequently opens in the appropriate Office application, without asking me login again. But, If I login to Sharepoint from a computer that is not on our network, or login to the computer with an account that is not a domain account, I get prompted again to login when openning an Office document. If I choose the option to save, it does not prompt, but if I choose open in the dialog window, I am forced to enter my domain credentials again.
When I login to the 882 site, which uses FBA, I experience the same problem. If I open an Office document, the appropriate Office application opens, and asks me for my credentials, by showing me a dialog window with the sign in page loaded. If I choose to save the file, then I am not prompted to login, and the file saves to a local folder.
I can't expect my users that are off site to login again everytime they open an Office document, like Work, Excel, Powerpoint, etc. I have tried numerous fixes, including disabling client integration, changing the browser handling mode (strict/permissive), changing internet explorer settings (for integrated windows authentication), changing the integrated windows authentication site to use basic authentication, even hacking the page using jquery to call the sharepoint javascript function that execute the "download a copy" function. None of them work: when choosing to "open" the Office document in the browser, the user has to login again, or just close the dialog window without logging in (as long as client integration for the zone is turned off).
I'm looking to get this accomplished using windows authentication or forms based authentication.
Help!
I found this answer in a similar post which seemed to fix the problem for me when I tested it. The gist of it is you need to deny the HTTP Verbs OPTIONS and PROPFIND in IIS. Having said this, I'm not an IIS guru and am not exactly sure what this means or what else it might affect. Can anyone else shed some light on this?
A bit of background, I'm using SharePoint 2010, on an FBA site.
You have the standard three use cases:
Employee intranet access
Employee remote access
Partner remote access
Employee intranet access
This normally always works out of the box, and it looks like it is working for you.
Employee remote access
The only way that i have seen this work (and i have tried many ways) is to get TMG or ISA. Basically ISA is setup in FORMS auth with SSL, it captures the auth details, and then passes them to the sharepoint server. (and other servers if you have them eg OWA for sharepoint mail web parts)
If you select the "Is private computer" option on the ISA login screen, then Office documents share the auth cookie and don't prompt for another login. I had so many problems, but as soon as i installed TMG, they all went away. I would not recommend any other approach now.
The added bonus of this method, is that remote employees are treated as the same account as the intranet user. The way you are setup with a seperate web application, means that they will be different accounts, so things like [checkout/modifiedby/createdby/personalisation] will be different accounts (though they look the same)
Partner remote access
This may never ever work on some clients (especially Vista), as IE needs to share the authentication with Office
If this is sharepoint 2010, try this.
Get-SPSecurityTokenServiceConfig
Look at your UseSessionCookies value in the output. If True, apply the powershell below.
$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $false
$sts.Update()
If UseSessionCookies is true, you will have to login to any docs u want to download...
I am getting an error when trying to sync some calendars with Outlook. The error is
"Task 'SharePoint' reported error (0x80070005): 'You do not have permission to view this SharePoint List (Site Name - Calendar Name). Contact the SharePoint site administrator. HTTP 302'"
This error is intermittent (removing the calendar from Outlook and re-syncing it sometimes resolves it temporarily) and does not effect all users at the same time.
I have full control of the site as well as the calendar in question. I have tried breaking permission inheritance and setting unique permissions on the calendar with no change. I have checked AAM and all is correct (site is accessed the via the same URL internally and externally)
Our site uses both Forms Based Authentication and Windows Authentication. This issue is experience by users using AD (have not tried any FBA users).
Setup the URL for default and intranet (I know, I know) - just try it. We thought internet was right too - but kept hitting our heads against the wall. If it breaks something, try setting the value for all 3 zones - default, internet and intranet... may the luck be with you.
Go into SharePoint Central
Administration
Go to Operations Under Global
Configuration, select Alternate
access mappings
Choose your Alternate Access Mapping
Collection from the dropdown (e.g.
SharePoint - 80)
Make the Default zone your new DNS
name, including if it's SSL'ed or not
(e.g. http://portal.company.com or
https://portal.company.com)
They were having the same errors
We are facing Login problems while Logging to our site. We (the Developement Team) can log in to the site with only one prompt but many users are getting login prompts several times. After pressing ESC for 5-6 times they can login to site. Is there any AD setting that needs to be changed?
If so not even the Site Admin (Full Permission) can log in without prompts.
I have already added the site in trusted sites in Internet Explorer.
Is this a publishing site? If so, have you ensured that all of your content is published? If anything is still in draft and has never been published then they will receive authentication prompts as ordinary users can't see draft content. Make sure you check CSS files and other assets such as images.
Add your site to the Trusted Sites in Internet Explorer
I suggest you check out this link here and check your settings compared to these. I have set up several MOSS 2007 servers following this guide with no problems at all...except for small mistakes on my part :P
After I log into my sharepoint website, I have to login everytime I access a document from the library. Is there a way to fix this?
Thanks
User Level:
If your SharePoint site always prompts for username/password on accessing it you can set your browser to not prompt
In Internet Explorer, go to Tools
Click Internet Options
add your site URL to Internet Explorers "Local Intranet Sites" section.
Open Security tab
Click Custom Level button
Scroll down to this screen and select "Automatic logon with current username and password" radio button
Click OK.
Administrator Level:
you can add your site's internal zone URL in Alternate Access Mappings section on Central Administration>Operations site, The SharePoint server always does not prompt for username/password and you can enjoy.
When using Windows Vista or Windows 7 the office tools (e.g. Word) do not look at the Local Intranet list of Internet Explorer. But they look at the following registry location:
HKEY__LOCAL__MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\AuthForwardServerList
If your sharepoint site is located at share.myserver.com you can set the above registry entry to *.myserver.com (including the *) so that all addresses ending with myserver.com are trusted by the office applications. This will prevent the login popup box from appearing.
For more info see this microsoft article. It solved the problem for me.
Add the SharePoint site to your trusted sites or local intranet in Internet Options.
This is to do with the way Word does the request for a file It sends an anonymous request first. What solves this is setting the session cookie to be valid for a year.
Are you using AD for the Authentication ?
Are you browsing the site from same network where it is hosted or on a Different N/W ?
If in the Same new work "Add the SharePoint site to your trusted sites or local intranet in Internet Options" and in the Trusted Sites Security Custom Level , User Authentication Section select the Option Automatically Login with the Current User Name and Password.
If you are browsing from Different n/w its bit tough to get it .
I experience this every day. My local machine is on a different domain to the SharePoint server so I have to log in every time I access SharePoint with a different application. This includes IE, Word, InfoPath, etc...
There is no way I've found to avoid it as it's simply part of using Windows authentication. Saving your password can help but still shows a dialog.
There are quite a few things that could cause this and you don't give much detail on your setup in the Q to give you an answer but...
The most comprehensive article I've found for troubleshooting this is
Unwanted Authentication Prompts
This issue is familiar to me and I've previously used the upvoted solution to the problem. However, recently I discovered that using Google Chrome rather than Internet Explorer makes this problem go away!
Solution: Use Chrome.
Switching to Basic Authentication will resolve this issue at a cost of passing credentials in clear text.