You can use the Layouts page called securestoresetcredentials.aspx to allow the user to set their credentials. Fortunately most of the plumbing is already done for this. For Individual Applications you need to set the credentials for each and every user through Central Admin or create some custom Web Part or similar that the user can use to fill in it’s credentials. For a Group Application you use Central Administration or PowerShell to set the credentials to be used by the group of users. When the application is configured we need to set the credentials for it. On the final page you give permissions to the Target Application itself and if it is a Group application then you also configure what users/groups that are mapped to the credentials. Otherwise, if you’re using for instance SQL credentials, you have to set up two new fields using the User Name and Password type of fields. By default it assumes that it is Windows credentials that we would like to store, if that is the case you only need to click Next. On the next wizard page you set up the “fields” for the application. If you choose Individual you have to set the credentials for each user individually and for Group you have one set of credentials per application. Use Individual or Group, where Group is preferred from a management perspective. Then we have to choose what type of Target Application Type to use. Also give it a descriptive name as well as a contact. First of all we need to give the Target Application an ID, this is what we later use to reference this application from Excel (and other sources). To create the Target Application use the New button in the Ribbon. Once that is done and you have generated the encryption key, we need to add a new Target Application. Configuring the Secure Storeįirst of all we need to have the Secure Store Service Application up and running in our SharePoint farm.
Let’s take a look on how you can get this to work: an Excel sheet with an external data connection using Secure Store to store credentials and then using Office Web Apps 2013 to refresh the data. The WOPI Suppression made sure that the rendering of the Excel book was done by Excel Services in SharePoint 2013 rather than with Office Web Apps 2013.īut if you have Excel documents with external data and do not rely on delegating the account (and don’t do the Negotiate, SPN and delegate dance), but instead like to store the credentials to the data in the connection string (not recommended) or like to take advantage of the Secure Store in SharePoint 2013 – then you actually have the option to not do any WOPI Suppressions. That post talked about how you needed to do, so called, WOPI Suppressions if you had Excel files with Data Connections and had those data connections configured to use the authenticated users account. This is a follow-up post on the SharePoint 2013, Office Web Apps 2013 and Excel files with Data Connections post that I previously wrote.
0 kommentar(er)
