Skip to main content


 

Symptoms


Whenever the ticket owner or a member of his team would try to load up and run a given SmartForm everything worked as one would expect. If however this was being done by one of his end users, the SmartForm would render and as the underlying SmartObject would load the user would be greeted with the following error:

Failed to initialize Context: URL: YOUR URL] Username: Error Details: The remote server returned an error: (401) Unauthorized. Method: SharePointService.initializeContext.
 

Diagnoses


The first thing checked was that the User Profile Service had been set up and synced correctly as it is necessary for retrieval of the oAuth token that is used to auth the user and therefore allow SharePoint apps to work.

Next the ticket owner verified that all the UPN's for the users had been properly synced with AAD and SharePoint User Profile Service so that the correct User Profile Name can be had when resolving users.

When looking through the ULS logs it was noticed that the following error was captured:

3895972","2015-04-10 16:49:22","Error","IdentityService","64005","ResolvingException","IdentityService.ProviderCacheIdentity:RoleProvider.GetUser","64005 Failed to resolve 'AAD:DACCOUNT@DOMAIN.local]': Resource ' ACCOUNT@DOMAIN.local]' does not exist or one of its queried reference-property objects are not present..","anonymous","0.0.0.0","i-6645dd003:C:K2Slots4NETUBBK2 blackpearlHost ServerBin","3895972","07997fe75cf944d1a3a3f29f830c769a

The fact that the UPN carried a .local rather than .net indicated a synchronization error. The ticket owner reverified that User Profile Synchronization was working which it was. However the sync was set to look at the eDOMAIN].local level with in Active Directory for syncing though the users were set as UPN NDOMAIN].net.

THIS IS INTERESTING: When the unauthed users were moved in to the Organizational Unit that housed the developer's (ticket owner's) team things worked.

The ticket owner tested moving users out of their AD Security Group and into the AD Users Group and this seems to have stopped initial 401 Errors and uncovered another. Users in a given SharePoint group set as an element of the SharePoint members but not in the Members group in their own right we seeing the following and different error:

Failed to Initialize the Context: URL: :YOUR URL] Username: Correlation ID: :ID] Error Details: Access denied. You do not have permission to perform this action or access this resource. Method: SharePointService.initializeContext.

One of our own Appit team members was able to successfully reproduce the above error.

In the midst of that reproduction this error was caught:

Permission check failed. asking for 0x10000, have 0x200000000 which translates to Request has SPBasePermissions.UseRemoteAPIs permission.

So users added directly to the SharePoint members group worked fine and Users contained within subgroups did not.

One of our technical specialists (the one that reproduced the error) noticed that the claims for the hydrated user (contained within a subgroup) were less than those of the users added directly.
 

Resolution

By adding an Audience to the user profile service (http://blog.arjanfraaij.com/2011/05/adding-active-directory-ad-group-to.html) for AD Groups and waiting for a synchronization cycle the claims count equalized and the hydrated users were able to work with the forms as expected.




 
Be the first to reply!

Reply