I am investigating how to convert an existing outlook add-in to authenticate to one of our APIs via Azure Active Directory. The way the add-in works, it would severely limit the user experience if they were constantly prompted with a dialog. If I were to base my solution off this sample project, how often could we expect the user to have to interact with a dialog or login?
Related
I've developed a VSTO add-on for Outlook that my company uses which connects to a SQL database to read/write data. I'd like to change the data source to SharePoint Online since all employees have M365 accounts. This will also allow the add-on to operate outside of the corporate network.
If I setup a SharePoint online site with a few lists, is there a way to have the Outlook VSTO Add-on read/write from the lists?
Also, since the Outlook client is already authenticated, is there a way to bypass any sort of authentication and use the already authenticated Outlook client when talking to SharePoint?
No, you need to consider your add-in as a standalone .Net based application. You can use the SharePoint client object model (CSOM) to retrieve, update, and manage data in SharePoint. Read more about that in the Complete basic operations using SharePoint client library code article.
Can I track why a user didn't install our Outlook add-in because of Microsoft features for IT Admin ? For example, the user can't install add-in with following situations. My team want to track it and set next actions for acquisitions.
Example1: IT admin disables App Store from office client, but a user see our add-in in App Source web page. The user try to install it, but finally he/she can't install it.
Example2: IT admin doesn't allow users to install add-in before they approve it, even though the user can see our app.
I don't know all cases when a user can't install our add-in by IT admin's policy, so I just wrote what I could imagine.
Currently the feature to track the why user didn't install add-in is not a part of the product.We track Outlook add-in feature requests on our user-voice page. Please add your request there. Feature requests on user-voice are considered, when we go through our planning process.
Can you tell us how do you plan to use this information?
We have setup and are hosting a centrally deployed Add-in for Excel developed with the OfficeJS API. We have had success in building, hosting, and testing the Add-in, but are now seeing a very strange issue that we are having trouble debugging. For context, the Add-in is developed with React, the OfficeJS API, and is intended to be loaded within Excel and primarily interacted with via the taskpane window.
Now that we have a working Add-in, we have deployed the Add-in to our first client using Centralized Deployment (https://learn.microsoft.com/en-us/office/dev/add-ins/publish/centralized-deployment) for the Client's associated Office 365 account. When deploying, we originally only deployed to a certain subset of users while finalizing testing, but since we have updated the "Assign Users" setting to "Everyone". We are now running into a strange issue where some of our users in the account are able to access the add-in, and some are not. It should also be noted that all of the users who originally had access still have access; it seems only a subset of the newly authorized users are unable to access the add-in.
So far, we have tried a number of things to re-create and/or resolve the issue, but have had no success:
Setting up new accounts - when setting up a new account, the new account seems to have access to the Add-in as expected. We are unable to re-create the bad state some users are experiencing.
Clearing Excel Cache - we have had users clear their Excel application and web cache, but nether has resulted in changes to access.
Logging in/out - we have worked with users to sign-out, clear cache, and sign-in again but this does not update any access settings for the Add-in.
Attempting to Manually "Insert" the Add-in - when opening the "Insert" tab and selecting "My Add-ins" menu from Excel, the user does not have the Add-in listed under the "Admin Managed" tab. If the user attempts to "Refresh" it still does not change anything.
We are starting to meet with some of the users who are experiencing the issue to further investigate, so any advice or further debugging tips would be greatly appreciated!
I would like to write an Excel Task Pane app to interact with CRM Online - to take data from the Excel worksheet, process it and push it into a CRM entity record. My Excel users are on Office 365, as is CRM Online (obviously). We are using ADFS 2.0.
The specific problem I am experiencing is that I do not know how to get authentication to work for the Task Pane app: specifically, to the OData endpoint via JavaScript. Authentication is not my area, so I don't know how to precisely phrase this next requirement, but as we are using Office 365/CRM Online/ADFS then I need to use the logged-in user's Windows AD credentials to authenticate the request.
As far as I can tell, it is not possible to authenticate the Task Pane app directly with CRM Online, and I would like to know if that is known to be true, and if not what method(s) I can use.
I do know that there is a hack for indirect authentication published by a couple of people (http://survivingcrm.com/2013/12/connecting-crm-online-odata-feed-excel-2013-power-query/ or http://www.crmconsult.co.uk/connecting-to-crm-20112013-with-odata-in-excel-2013/) which authenticates the user via the CRM plug-in and then allows other OData connections to succeed - but it doesn't work for me, and I'm averse to rolling out functionality to users which relies on back-door methods.
In the end, I ended used using SOAP in VBA instead of oData in the Task Pane, which meant I was able to use Jason Lattimer's hard work from http://jlattimer.blogspot.co.uk/2015/02/soap-only-authentication-using-vba.html - I don't think there is any way I would have figured out the Authentication piece without that post, so many thanks to him.
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...