We recently enabled User Licensing in our environment and I ran into some issues getting it to work properly. With licensing enabled I was unable to access the protected functions even though I was a member of the proper groups. I had ran into a similar issue in the past with MySites not provisioning properly when licensing enabled and had a case open with Microsoft. The end result was they told us we needed to map the claim identity since we were using ADFS as our trusted claims provider.
I had put that on the back burner since we had decided to hold off on using MySites and it required learning a bit more about claims encoding. Since the issue had come up again I decided to get to the bottom of it.
I had found this article talking about enabling licensing for claims, however, I was unable to get it working as described.
This article was excellent for learning the specifics of claims encoding and how I needed to build the claim for my uses.
SharePoint 2013 can be configured to allow specific users perform certain actions. For example with Office Web Apps Server 2013 integrated with the SharePoint environment only certain users may be allowed to edit documents within OWA due to licensing constraints. This can be achieved by enabling and configuring user licensing.
The following command is used to enable licensing in the SharePoint farm. Once licensing is enabled explicit license mappings must be created to allow users to use license protected actions. Such as Office Web Apps editing and Enterprise features.
Once licensing is enabled, user mappings need to be executed. These mappings represent which security groups are allowed to execute what actions.
There are four individual groups that licenses can be assigned. These can be seen by using the Get-SPUserLicense cmd-let. For my use we will only be using Enterprise, Standard and OfficeWebAppsEdit in our environment since there is no Project Server installed:
For a web application that is configured to use the default Windows claims provider the security group is simply passed to the New-SPUserLicenseMapping and Add-SPUserLicenseMapping cmd-lets.
$map = New-SPUserLicenseMapping –SecurityGroup “SPEnterpriseUser” –License Enterprise
$map | Add-SPUserLicenseMapping
To verify the license mapping has taken effect use the Get-SPUserLicenseMapping cmd-let:
Repeat this command for each Security Group and License required. Creating a license mapping for the Standard features isn’t required, but adding it provides consistency.
When using a Trusted Claims Provider such as ADFS the mapping becomes a bit more challenging. You need to encode the claim before mapping the license. This require a little bit of knowledge of the claims encoding format. A good article to reference is located at:
This article tells you what each part of the claims encoding means. First we need to build a new claims string using the following reference:
Referencing the above article I’ve constructed the following claim:
c = indicates this is a claim other than an identity claim
:0 = place holder
– = indicates the ClaimType is a “role” or security group
. = indicates the ClaimValueType is a string.
t = indicates the AuthMode is for a trusted issuer
ADFS20 = is the name of the trusted issuer of the claim
SPOWAEditor = is the value of the claim. In this instance the SPOWAEditor security group.
NOTE: The Claim Value is case sensitive. “spOWAEditor” will not work it must be exactly as it is in the provider. Here in Active Directory it is listed as “SPOWAEditor”.
Since I’ve built the claim string. I can now create a claim string from it using the New-SPClaimsPrincipal cmd-let:
$claimString = New-SPClaimsPrincipal -EncodedClaim “c:0-.t|ADFS20|SPOWAEditor”
Since the claim string is built and populated I can go ahead and perform the license mapping using the newly created claim string variable and add the mapping:
$map = New-SPUserLicenseMapping -Claim $claimString -License OfficeWebAppsEdit
Retrieve the current mappings using Get-SPUserLicenseMapping. We can see that the new mapping has taken effect and shows the ADFS20 provider as the trusted provider for that mapping.
Repeat the same steps to complete the remaining mappings. Now the three new ADFS mappings should be present and mapping is completed for both NTLM and ADFS providers.