"Access is Denied" error thrown for entity with valid permissions

Question

We have two roles currently being used:  Tester and Sys Admin.  "Sys Admin" has no issues.  "Tester", however, is not able to save one records for one entity.  I will call it the Entity A from here on out.  This error log shows what happens when a "Tester" user tries to save an Entity A record:

Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 099b52c5-52cc-e111-97a5-005056bf000b, OwnerId: b04c0b80-9b7a-e111-a588-005056bf000b,  OwnerIdType: 8 and CallingUser: d2ce25aa-efeb-e111-b73b-005056bf000b. ObjectTypeCode: 10149, objectBusinessUnitId: 6e86137a-9b7a-e111-a588-005056bf000b, AccessRights: AppendToAccess Detail:

<OrganizationServiceFault xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/xrm/2011/Contracts">

  <ErrorCode>-2147187962</ErrorCode>

  <ErrorDetails xmlns:d2p1="http://schemas.datacontract.org/2004/07/System.Collections.Generic">

    <KeyValuePairOfstringanyType>

      <d2p1:key>CallStack</d2p1:key>

      <d2p1:value xmlns:d4p1="http://www.w3.org/2001/XMLSchema" i:type="d4p1:string">   at Microsoft.Crm.Extensibility.VersionedPluginProxyStepBase.Execute(PipelineExecutionContext context)

   at Microsoft.Crm.Extensibility.Pipeline.Execute(PipelineExecutionContext context)

   at Microsoft.Crm.Extensibility.MessageProcessor.Execute(PipelineExecutionContext context)

   at Microsoft.Crm.Extensibility.InternalMessageDispatcher.Execute(PipelineExecutionContext context)

   at Microsoft.Crm.Extensibility.ExternalMessageDispatcher.ExecuteInternal(IInProcessOrganizationServiceFactory serviceFactory, IPlatformMessageDispatcherFactory dispatcherFactory, String messageName, String requestName, Int32 primaryObjectTypeCode, Int32 secondaryObjectTypeCode, ParameterCollection fields, CorrelationToken correlationToken, CallerOriginToken originToken, UserAuth userAuth, Guid callerId, Guid transactionContextId, Int32 invocationSource, Nullable`1 requestId, Version endpointVersion)

   at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.ExecuteRequest(OrganizationRequest request, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType)

   at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.Execute(OrganizationRequest request, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType)</d2p1:value>

    </KeyValuePairOfstringanyType>

  </ErrorDetails>

  <Message>SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 099b52c5-52cc-e111-97a5-005056bf000b, OwnerId: b04c0b80-9b7a-e111-a588-005056bf000b,  OwnerIdType: 8 and CallingUser: d2ce25aa-efeb-e111-b73b-005056bf000b. ObjectTypeCode: 10149, objectBusinessUnitId: 6e86137a-9b7a-e111-a588-005056bf000b, AccessRights: AppendToAccess </Message>

  <Timestamp>2012-08-22T01:08:11.982914Z</Timestamp>

  <InnerFault i:nil="true" />

  <TraceText i:nil="true" />

</OrganizationServiceFault>

No other entities have issues.  I have checked the Tester role and the create level is set to User for Entity A so there should be no issues creating records.  Can anyone help me troubleshoot this error?  Thanks

Answer 1

Check out this thread - could be your new role is missing "Append To" on the System User entity.

---

Jason Lattimer

Answer 2

Here is the User entity for the Tester role:

 It covers the Business Unit which makes me think this isn't the issue.  Does it have to be completely green in this case?  Any other suggestions?

Answer 3

Is entity 10149 your Entity A? 

Run this query to find out:

SELECT * from EntityView
ORDER BY ObjectTypeCode

That would probably be the other spot to start looking at permissions - specifically Append To as the error mentions.

Otherwise try copying one of the existing role, adding permissions for your custom entity, they try saving. If that succeeds, start taking away permissions until it breaks. 

---

Jason Lattimer

Answer 4

The culprit was the 'Append To' permission for the security role.  It needed to be bumped up to the Business Unit level.