The Secure Store Service provides a more flexible solution to the problems partially addressed Single Sign-On (SSO) in MOSS 2007. It allows for the secure storage of usernames and passwords for shared resources and the mapping of users to specific access identities. It is commonly used for access to data for Business Connectivity Services, Excel Service Applications and Visio Service Applications.
Microsoft have some really good documentation on this topic. Their planning guide is http://technet.microsoft.com/en-us/library/ee806889.aspx and their own more detailed configuration guide is http://technet.microsoft.com/en-us/library/ee806889.aspx.
However, for many (especially for dev and piloting) this provides a quick guide to getting it up and running.
You should check that you are a Service Application Administrator for the instance of the Secure Store Service you will be configuring.
The first step is to initialize the Secure Store Service:
- From Central Administration, choose Manage service applications from the Application Management group:

- Click on the Secure Store Service link (either is OK – they both link to the same place):

- If this is the first time the Secure Store Service has been accessed, you will need to Generate New Key (from the ribbon):

- To generate a new key you must provide a passphrase. This is used for encrypting information stored in the secure store so it is wise to choose a strong passphrase. There is no way (at least that I know) of recovering the passphrase, so do not forget it!
At this point the Secure Store Service is ready for you to start adding the target applications that you want to store credentials for. For each application you want to access, do the following:
- Click on the New target application ribbon button:

- Complete the Target Application Settings using the notes below:
- The target application id is the unique name of the application (and cannot be changed), although the display name can.
- Contact e-mail is pretty self explanatory.
- Then we get to the Target Application Type. The first choice to make is either:
- Individual – meaning that each user connecting to SharePoint will be mapped to a unique set of credentials to connect to this target applications; or
- Group – meaning that all users connecting to SharePoint in a specific group will be mapped to a shared set of credentials to connect to this target application.
- Now we need to decide whether the type should be normal, Ticket, or Restricted. Maybe its just me, but I found the on-screen help not very useful and online help took a few seconds longer than usual to find. Essentially, these options have the following meaning:
- Ticket – this applies to target applications who support ticket (or “claim”) based authentication. Claims based identity management is a big theme in Microsoft.NET 3.0 and if you want a primer in this topic please see http://msdn.microsoft.com/en-us/magazine/cc163366.aspx;
- Restricted – allows you to provide implementation specific additional authentication in the target application;
- Normal – this is the more traditional method of providing authentication credentials (username, password and maybe other information) with each connection.
- I am interested at this point in a connection to SQL Server, and a single set of Windows logon credentials for all users is what I’m after, so I choose Group, and click Next.
- Next I’m prompted to specify the authentication field names and type. The default of Windows User Name and Windows Password is exactly what I need, but if you are connecting to a target application that needs more information you can add fields of various types to this target application:

- I’ve chosen to have a single set of credentials for a group of SharePoint users, so next I need to specify who can administer this target application and who are the members of the group of users that will use these credentials:
Note that in Administrators and Members I can use the new People and Groups picker dialog, which is a big improvement on the 2007 version:

- Finally, click OK and you’re done: target application created.
That’s it – you’re done. Using this target application is for another post, but to give you an idea, the screen shot below shows specifying this target application from Excel (with the really cool PowerPivot in the background – see http://calvisblog.wordpress.com/2010/06/10/powerpivot-and-real-estate):
Brian Coughlan
October 6, 2010
Hi Chris!
I just used your instructions to get my excel sheet refreshable in the browser; next stop web parts!!!
Appreciate the help.
Regards,
Brian.
Morna Tirona
December 3, 2010
Great post; helped me out alot.
anil
April 6, 2011
Hi I have a question . we want to implement secure store service in our organization. But according to our policies we have to change our password every 3 months .So if we implement the secure store service for a user group , Is their a way that when the user changes his password the password change will also be implemented in secure store service .
Chris Lees
April 19, 2011
Anil – apologies for taking some time to reply.
The short answer, I think, is no. However, I am not 100% sure I understand your question completely. Is it one of the following:
1. You want each user to have an individual secure store identity to connect to the external system which is their own (AD) user account; or
2. Do you want everyone in this particular user group to share a (distinct) user account for access to the external system; or
3. Does each user have their own (unique) user account for the external system distinct from their AD user account.
I don’t believe it can be scenario 3 from what you have described, unless the external system also used AD accounts subject to the same password expiration policy and for some reason the users needed separate accounts to access the system. So I’m assuming it is sceanrio 1 or 2.
If it is 2, then you are effectively using a service account for accessing the external system. I would, in those circumstances, make the case that this service account should not be subject to the password expiration policy.
Scenario 1 is a little different. I would like to understand what you are using the secure store service to achieve in this context, because what you are effectively looking to get is pass-through authentication. This may need some Kerberos configuration if you don’t already have Kerberos set up, but many SharePoint 2010 service applications do support pass-through authentication. Perhaps most importantly, Business Connectivity Services (BCS) supports pass-through, and this would allow you to pull through data into External Content types from an external system using the user’s identity.
I hope this helps!
Sam Trna
July 31, 2011
Hi Chris, Thanks for your post, saved me a lot of time, much appreciated mate. Keep up the good work. Sam