We recently ran into an Access Denied problem using the Secure Store Service. The environment has a Shared Services Farm which publishes the Secure Store Service (along with BCS, Managed Metadata, User Profile, FAST Query SSA, and Web Analytics) to consuming farms (http://technet.microsoft.com/en-us/library/ff621100.aspx). Each farm has unique Farm Administrator accounts; as well as, unique service accounts for application pools and service applications.
After publishing the services, we set up a trust relationship between farms by exchanging certificates; and then in the consuming farm, we connected to the published shared services (http://technet.microsoft.com/en-us/library/ee704552.aspx). The consuming Farm Administrator account was given Full Control permission to all shared services, including the Secure Store Service. So far everything was working as planned. Search worked, user profiles and My Sites worked, we were feeling good.
Trouble occurred when the consuming farm administrator tried to create the unattended accounts for the local Excel and Visio service applications. As you know, unattended accounts required you to create Target Applications in the Secure Store Service. Creating a Target Application ID walks you through a wizard of 3 pages. In one case, every other page submission resulted in an Access Denied error. In the other case, we couldn’t get past the first page due to access denied. A look at the ULS logs of both the consuming and publishing farms didn’t reveal any clues, other than an access denied exception was being thrown in the web service call from the consuming farm to the topology service of the publishing farm. We kept asking ourselves, why would an account with Full Control permission to the service application get access denied? We even tried to create the Target Applications directly in the publishing farm logged in as the consuming farm account, thereby eliminating inter-farm trust as a factor. Still got access denied.
Searches of TechNet, the web, and Microsoft’s KBs didn’t provide any solution. We tried recreating the service application, recycling application pools, resetting IIS, even rebooting servers. The access denied error persisted. We must be missing something, but what?
We started looking at every aspect of the Secure Store Service configuration on the publishing farm, and then we found it! Even though there is a Full Control permissions displayed when you click the Permissions tool bar button, this permission apparently doesn’t really give full control. We discovered by clicking the Administrators tool bar button there are granular administrator rights for Create, Delete, and Manage Target Application. I can’t explain why these rights are administrative rights not covered by the Full Control permission; however, granting the consuming farm account these administrator rights solved the problem! Any other accounts needing these rights will also have to be added.
The step-by-step solution follows.