Monday, August 13, 2012

Permissions Error on Application Discovery and Load Balancer Service Application

Recently when I was reviewing the permissions on my service accounts, I received the below error message after clickign the Permissions ribbon button for my Application Discovery and Load Balancer Service Application.

Digging through the trace log I was able to capture the stack trace which was slightly more helpful:
System.ArgumentException: Exception of type 'System.ArgumentException' was thrown. Parameter name: claim at Microsoft.SharePoint.Administration.Claims.SPSystemClaimProvider.GetFarmClaimDisplayValue(SPClaim claim) at Microsoft.SharePoint.Administration.SPAce`1.get_DisplayName() at Microsoft.SharePoint.Administration.AccessControl.SPAclAccessRule`1..ctor(SPAce`1 ace) at Microsoft.SharePoint.Administration.AccessControl.SPAclSecurity`1.d__c.MoveNext() at Microsoft.SharePoint.Administration.AccessControl.SPObjectSecurity.d__0.MoveNext() at Microsoft.SharePoint.WebControls.AclEditor.OnPreRender(EventArgs e) at System.Web.UI.Control.PreRenderRecursiveInternal() at Sys...
Based on this I was able to assume that one of the claims in the ACL for the service app was invalid, the challenge is to find out which one.


How to troubleshoot the issue


First, we have to get a list of the permissions for the service application. To do this, we'll need to query the config database. Disclaimer: Querying the database is something you should only do for troubleshooting purposes. ALWAYS use the (nolock) query hint and NEVER update a table


Copy the results into a text editor (I prefer Notepad++) and you'll be able to see each entry. In the ACL for a service application you may see two different types of entries; remote farms and service accounts.
A service account entry will look like this:
ace identityName="i:0#.w|domain\serviceaccount" displayName="serviceaccount" sid="" binaryIdType="1" binaryId="aTowKS53fHMtMS01LTIxLTEzMDg3MDU0MzctMTc3OTk1JUDOwOC0xTMgyNzM5MzA1LTMwMTc0NzQ=" allowRights="18446744073709551615" denyRights="0" />&lt

and a remote farm entry will look like this:
ace identityName="c:0%.c|system|57c9c598-d677-4abb-9682-54fa17a2d8ae" displayName="Remote Farm: 57c9c598-d677-4abb-9682-54fa17a2d8ae" sid="" binaryIdType="1" binaryId="YzowJS5jfHN5c3RlbXw3MWH5YzU5OC1kNjc3LTRhYmItOTY4Mi01NGZhMTdhMmQ4YWU=" allowRights="18446744073709551615" denyRights="0" /><

The key difference is in the identityName field.

After reviewing every single entry, I found one entry where the identityName was configured for a remote farm, yet the claim was for a service account and not a farm. My guess is that when someone on my team was configuring a new farm to consume this service, they accidentally used a service account instead of the SPFarm Id in our script. Oops!

This is what the entry looked like : ace identityName="c:0%.c|system|domain\serviceaccount" displayName="0%.c|system|domain\serviceaccount" sid="" binaryIdType="1" binaryId="YzowJS5jfHN5c3RlbXxsbVxzYXNwbWxwYXBwcGxfdHN0" allowRights="18446744073709551615" denyRights="0" /><

As you can see, the indentityName was structured like a remote farm, yet it contained a service app instead of a farm id.


How to fix the issue


Luckily the fix is a very simple powershell script. Since we added remote farm claim with a service account name, we just need to revoke the claim. Below is the script I used. You can simply put in your service account for the -ClaimValue field

$security = Get-SPTopologyServiceApplication | Get-SPServiceApplicationSecurity
$claimProvider = (Get-SPClaimProvider System).ClaimProvider
$principal = New-SPClaimsPrincipal -ClaimType "http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid" -ClaimProvider $claimProvider -ClaimValue domain\serviceaccount
Revoke-SPObjectSecurity -Identity $security -Principal $principal

After I did this, I was able to see the permissions from central admin again.

No comments:

Post a Comment