Freigeben über

Provided User Name was not Encoded as a Claim

  • Artikel

So today's lesson is quite bizarre.. and I'm not sure where *exactly* the problem lies just yet. I was going through the process of configuring my SharePoint 2013 (SP2013) farm to test something with an external list that is bound to an external content type (ECT) backed by a SQL Server database. Simple enough on the surface:

  1. In your SP2013 farm, create and configure Business Data Connectivity (BDC) and Secure Store (SS) Service Applications
  2. Create the SQL database
  3. Add a SQL login to use with Secure Store (for my situation I chose not to use Kerberos Delegation)
  4. In SharePoint Designer (SPD), create an ECT and connect it to the database in step 1
  5. Create a custom list from this ECT

Now obviously there are a lot of details that I'm leaving out above, but the purpose of this post is not to show you how to create an ECT. Step 1, specifically, is where I encountered my issues today. I had already previously created the required service applications, but I had not configured them for use. Creating the SS application went without a hitch for the most part, but with the BDC service application it was not that easy.

You need to grant rights to the Metadata Store within the BDC service application in order for users to create an ECT so my first stop was to Central Admin and in to Manage the BDC service application.

Once in the service application management page, you will need to add a user to the Metadata Store Permissions

You may notice a bit of a problem in the screenshot above in that my user has not been resolved properly. (you may not have noticed it depending on how much sleep you've had, but that's another discussion) As it so happens, I'm rather stubborn, so I proceeded to click the Add button anyway. Much to my surprise AdamB was added to the user list and I was allowed to select the permissions I wanted this user to have. However, when I clicked OK is when the real fun began.

As you can see, it didn't work very well and resulted in the following error:

A provided user name was not encoded as a claim. Parameter name: aces

Now considering the fact that I occasionally enjoy a game of cards here and there "aces" got me rather excited until I realized it was trying to tell me that something failed and I had to now fix it. So where is the first place you go to unravel errors in SharePoint? The ULS logs, of course!! And here a list of a couple of the entries (scrubbed and filtered) around this error:

ULS Log Entries

01/07/2015 17:37:20.65    w3wp.exe (0x30F8)    0x3B7C    Business Connectivity Services    Business Data    9f4h    Unexpected    'BDC' BdcServiceApplication logging server side ArgumentException before marshalling and rethrowing on client side: System.ArgumentException: A provided user name was not encoded as a claim. Parameter name: aces at Microsoft.SharePoint.BusinessData.SharedService.IndividuallySecurableMetadataObjectAccessor.SetAccessControlEntries(MetadataObjectStruct metadataObjectStruct, AccessControlEntryStruct[] aces, String settingId, DbSessionWrapper dbSessionWrapper) at Microsoft.SharePoint.BusinessData.SharedService.BdcServiceApplication.<>c__DisplayClass2c.<Microsoft.SharePoint.BusinessData.SharedService.IBdcServiceApplication.SetAccessControlEntries>b__2b() at Microsoft.SharePoint.BusinessData.SharedService.BdcServiceApplication.Execute[T](String operationName, UInt32 maxRunningTime, ExecuteDelegate`1 operation)    858bdd9c-f650-b0dd-7410-7cdb3f5cb1fd

01/07/2015 17:37:20.65    w3wp.exe (0x3618)    0x340C    SharePoint Foundation    General    8nca    Medium    Application error when access /_admin/BDC/ManageBDCPermissions.aspx, Error=A provided user name was not encoded as a claim. Parameter name: aces at Microsoft.SharePoint.BusinessData.SharedService.IndividuallySecurableMetadataObjectAccessor.SetAccessControlEntries(MetadataObjectStruct metadataObjectStruct, AccessControlEntryStruct[] aces, String settingId, DbSessionWrapper dbSessionWrapper) at Microsoft.SharePoint.BusinessData.SharedService.BdcServiceApplication.<>c__DisplayClass2c.<Microsoft.SharePoint.BusinessData.SharedService.IBdcServiceApplication.SetAccessControlEntries>b__2b() at Microsoft.SharePoint.BusinessData.SharedService.BdcServiceApplication.Execute[T](String operationName, UInt32 maxRunningTime, ExecuteDelegate`1 operation)    858bdd9c-f650-b0dd-7410-7cdb3f5cb1fd

01/07/2015 17:37:20.65    w3wp.exe (0x3618)    0x340C    SharePoint Foundation    Runtime    tkau    Unexpected    System.ArgumentException: A provided user name was not encoded as a claim. Parameter name: aces at Microsoft.SharePoint.BusinessData.SharedService.IndividuallySecurableMetadataObjectAccessor.SetAccessControlEntries(MetadataObjectStruct metadataObjectStruct, AccessControlEntryStruct[] aces, String settingId, DbSessionWrapper dbSessionWrapper) at Microsoft.SharePoint.BusinessData.SharedService.BdcServiceApplication.<>c__DisplayClass2c.<Microsoft.SharePoint.BusinessData.SharedService.IBdcServiceApplication.SetAccessControlEntries>b__2b() at Microsoft.SharePoint.BusinessData.SharedService.BdcServiceApplication.Execute[T](String operationName, UInt32 maxRunningTime, ExecuteDelegate`1 operation)    858bdd9c-f650-b0dd-7410-7cdb3f5cb1fd

01/07/2015 17:37:20.65    w3wp.exe (0x3618)    0x340C    SharePoint Foundation    General    ajlz0    High    Getting Error Message for Exception System.Web.HttpUnhandledException (0x80004005): Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.ArgumentException: A provided user name was not encoded as a claim. Parameter name: aces ---> System.ArgumentException: A provided user name was not encoded as a claim. Parameter name: aces at Microsoft.SharePoint.BusinessData.SharedService.IndividuallySecurableMetadataObjectAccessor.SetAccessControlEntries(MetadataObjectStruct metadataObjectStruct, AccessControlEntryStruct[] aces, String settingId, DbSessionWrapper dbSessionWrapper) at Microsoft.SharePoint.BusinessData.SharedService.BdcServiceApplication.<>c__DisplayClass2c.<Microsoft.SharePoint.BusinessData.SharedService.IBdcServiceApplication.SetAccessControlEntries>b__2b() at Microsoft.SharePoint.BusinessData.SharedService.BdcServiceApplication.Execute[T](String operationName, UInt32 maxRunningTime, ExecuteDelegate`1 operation) --- End of inner exception stack trace --- at Microsoft.SharePoint.BusinessData.SharedService.BdcServiceApplicationProxy.Execute[T](String operationName, UInt32 maxRunningTime, ExecuteDelegate`1 operation, Boolean performCanaryCheck, Boolean isChannelThatDelegatesIdentity) at Microsoft.SharePoint.BusinessData.SharedService.BdcServiceApplicationProxy.SetAccessControlEntries(MetadataObjectStruct metadataObjectStruct, AccessControlEntryStruct[] aces, String settingId) at Microsoft.SharePoint.BusinessData.Infrastructure.BdcAccessControlList.SaveAs(MetadataObjectStruct metadataObjectStruct, String settingId, BdcServiceApplicationProxy serviceProxy) at Microsoft.SharePoint.BusinessData.Administration.IndividuallySecurableMetadataObject.SetAccessControlList(IAccessControlList acl, String settingId) at Microsoft.SharePoint.ApplicationPages.ManageBDCPermissions.OkButton_Click(Object sender, EventArgs e) at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.HandleError(Exception e) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest() at System.Web.UI.Page.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)    858bdd9c-f650-b0dd-7410-7cdb3f5cb1fd

So while the ULS information did put me at ease that I was not going to be shot by Wild Bill and it helped me to understand that the problem was with adding entries to Access Control Entries (ACEs) I still wasn't any closer to a resolution. Thinking about the error a bit, though, did help me arrive at a path of investigation. The error is specifically talking about a user name that wasn't "encoded as a claim". So internally in SharePoint between the service applications we are utilizing windows claims for user identities. Within my farm specifically, my Central Administration web application is configured for NTLM Classic mode authentication and my content web applications are all configured for Windows Claims.

On a whim I tried to enter my user name in the People Picker in its claims format: i:0#w|contoso\adamb, but that provided no benefit and resulted in the same error series. So thinking about this a bit more I started wondering why we were looking for a claims encoded user name and remembered that although my content web applications were not using SAML claims I did, in fact, have a SAML Claims provider configured in the farm.

So we go on another whim and remove the SPTrustedIdentityTokenIssuer and try again. This time it worked without errors… neither the People Picker name resolution error, nor the "user name provided was not encoded as a claim" error appeared.

SYNOPSIS

When trying to add a user to the Metadata Store permissions of your BDC service application, if you receive name resolution errors and more specifically an error stating that the user name provided was not encoded as a claim, then you may need to remove any configured SAML claims providers in order to add the users to the permissions list.

Comments

  • Anonymous
    January 08, 2015
    What was the "c" and/or "i" provider name? This is what SPClaimEncodingManager.IsEncodedClaim leverages to determine if it is claim encoded or not. By default, CA doesn't have these entries, but I don't have an ADFS-enabled server to look at at the moment.
  • Anonymous
    February 01, 2015
    Thanks for this info. In my case I was just using the fully qualified domain name  (eg. sharepoint.local:5555) and I didn't have an alternate mapping for it. I switched the url to sharepoint:5555, and it worked fine. I guess I could add the fqdn into the alternate mappings to resolve the issue too. - hope it helps someone.
  • Anonymous
    March 04, 2015
    I had same problem. In my case resolution was to add the permissions to Model, External Systems and then to External Content Type.BRMarcin