Follow me on Twitter @AntonioMaio2

Friday, December 7, 2012

Understanding User License Enforcement in Microsoft SharePoint 2013

Previously, SharePoint (and still today with SharePoint 2013) can be purchased through either a standard or enterprise license CAL (client access license). The standard or enterprise CAL either enables or disables certain features depending on which one is purchased. In addition, there are additional components that can be licensed for SharePoint from Microsoft, on top of these CALs. Traditionally, customers had to purchase either standard or enterprise for all their end users. If customers were in a situation where features from the enterprise CAL would be accessed by only a very small number of users, that didn’t matter – they still had to purchase the enterprise CAL for all their users. At times, for some customers, this made SharePoint prohibitive to purchase simply because of the cost of licensing the enterprise CAL for every user, even though most would not be using the enterprise features.

Well, SharePoint 2013 solves that in a very elegant way by allowing customers to delegate which users are entitled to enterprise CAL features and which are entitled to only standard CAL features, and SharePoint elegantly deals with the situation when a standard CAL user navigates to a page where an enterprise CAL feature is present.

Lets start by talking about which features are available to only enterprise CAL licenses and which are available to standard CAL licenses. The following features in SharePoint 2013 are only available through an enterprise CAL license:
  • InfoPath Form Web part
  • Excel Web Access
  • Visio Web Access
  • PerformancePoint Filter, Report, Scorecard and Stack Selector
  • Indicator Details (deprecated feature – may be present when upgrading from 2010 to 2013)
  • Status List (deprecated feature – may be present when upgrading from 2010 to 2013)
  • Taxonomy Refinement Panel
  • Catalog-Item Reuse
  • Business Data Actions
  • Business Data Connectivity Filter
  • Business Data Item
  • Business Data Item Builder
  • Business Data List
  • Business Data Related List
  • Search-Driven Content (all web parts)


All other features are available through the standard CAL license.

The following components can be licensed for SharePoint from Microsoft separately:
  • AccessServices
  • BCS
  • Duet
  • InfoPath
  • PPS
  • Project
  • EntSearch
  • VisioServices
  • WAC (Office Web Apps)
  • ExcelServices
  • MySites

Enabling, Disabling and Validating User License Enforcement

By default, user license enforcement is disabled in a new deployment.  It must be enabled manually before you can begin assigning user licenses and having those licenses enforced.  Once it is enabled, then access to features is blocked at runtime for users that do not have the appropriate license… and of course, data about which features a user attempted to access is logged.

To get more specific, you need to enable user license enforcement using the PowerShell command:

Enable-SPUserLicensing

In fact, you simply need to do the following:

  • Click Start > … > SharePoint 2013 > SharePoint Management Shell
  • Enter Enable-SPUserLicensing and click Enter

You can check if user license enforcement is enabled by doing the following:

  • Click Start > … > SharePoint 2013 > SharePoint Management Shell
  • Enter Get-SPUserLicensing and click Enter
  • If user license enforcement is disable then it will return False and if its enabled it will return True

To disable user license enforcement, simply do the same but at the command prompt call:

Disable-SPUserLicensing

Its pretty simple.  In fact, SharePoint 2013 provides the following list of PowerShell commands to manage user license enforcement:


License Assignment and Enforcement

The license that is assigned to a user is based on their active directory group membership.  The way this is done is by mapping an active directory group to a particular license category, and then assigning users that are supposed to have a particular license to that group.  There are 5 categories in total that can be mapped:

  • Standard
  • Enterprise
  • Project
  • Duet
  • WAC

You map a license category to an active directory group using the following PowerShell commands:

  • $stdLicenseGroup = New-SPUserLicenseMapping -SecurityGroup “CONTOSO\StandardCAL” -License Standard
  • Add-SPUserLicenseMapping -Mapping $stdtLicenseGroup

Then you would do the following:

  • $entLicenseGroup = New-SPUserLicenseMapping -SecurityGroup “CONTOSO\EntepriseCAL” -License Enterprise
  • Add-SPUserLicenseMapping -Mapping $entLicenseGroup

Then users that are only licensed to access standard CAl features would be added to the StandardCAL AD group, and users licensed for enterprise CAL features would be added to the AD group EnterpriseCAL.  Users that are not part of the EnterpriseCAL group will be denied access to those features.  Users can be part of more than 1 group, and the user license enforcement feature will check all groups mapped to ensure that user has a sufficient license to access a particular feature.  Mapping the Standard CAL category might seem redundant since the SharePoint installation must at least have the standard CAL installed, but it is not.  If user license enforcement is enabled and a user does not exist in any mapped group, then they will not get access even to the standard CAL features.

So, if you’re going to use the User License Enforcement feature, planning of your license mappings is important, because a poorly mapped set of licenses or a poor assignment of users to AD groups will result in features being inaccessible to some users that should have access.

If a user that is only licensed for standard CAL features, so they are not part of the EnterpriseCAL group, comes across a page where an enterprise CAL feature is used, that feature will be hidden at run time.  In fact, SharePoint will display a nice message to the user inline in the page telling them that “…a license could not be found for this feature… please contact your administrator”.

The enforcement of the user license extends not only to site pages, document libraries and web parts, but also to the Web Part Gallery so that if a user that is not licensed for a web part then they will not be able to add it to a page either.  Very nice!

In addition to mapping an AD group, you can also map a forms based role or even a claim to a user license.  The example above will map the Enterprise CAL license category to the AD group for the entire SharePoint farm.  If you wish to map it just for a web application, that is possible as well by using the web application commandlet parameter.


Another Reason to Use Claims Based Authentication

This feature only appears to work in claims enabled web applications.  If you’re web application is used classic mode authentication, none of this works.

So, if you needed another reason to move to claims based authentication (other than the fact that the default in SharePoint 2013 is now claims based auth, and they’ve actually removed the configuration UI for classic mode auth) then here it is.  User license enforcement only works in claims enabled web applications.

Logging

Whether user license enforcement is enabled or not, usage data is logged about which features a user accesses and which licenses they have.

If user license enforcement is disabled, then the log entries are simply mapped to the installed SKUs which are standard or enterprise.  So, a user accessing a SharePoint deployment that has the Enterprise CAL will be logged as an Enterprise CAL user.  If a user accesses a SharePoint deployment with the Standard CAL, then log entries will contain the Standard CAL for that user.  Only standard and enterprise are logged in this case.

If user license enforcement is enabled, then access to unlicensed features will be logged as ‘unlicensed’.  If a user belongs to more than 1 CAL group, a seperate log entry will be added for each CAL pertaining to the user.  As well, user CAL and device CAL information will be included so that a user’s name that is attempting to access the feature, along with their IP address.

Conclusion

Organizations that could not previously afford SharePoint for all their users will take another look.  Enterprises now have more options about how they license SharePoint and can restrict Enterprise features and other CAL based features to just specific groups within the organization, making deploying a SharePoint Server a much more reasonable investment.

Sunday, December 2, 2012

Understanding Information Rights Management in Microsoft SharePoint 2013

An interesting SharePoint feature that helps organizations to protect against leaks of sensitive documents is the Information Rights Management capabilities (IRM). One session I attended at SPC12 covered this feature and this blog post is going to cover the highlights and what’s new for SharePoint 2013. In this article I’m going to focus on the on-premise deployment of Information Rights Management in SharePoint 2013, but there will be the occasional mention of SharePoint Online.

This feature existed in SharePoint Server 2010 and continues to be enhanced with some additional capabilities in SharePoint Server 2013. This feature is now also available for SharePoint Online (which is awesome) where it is known as Windows Azure AD Rights Management (AADRM). It is available only as part of Office365 Enterprise Plan 3 or Plan 4, and Academic Plan 3 or Plan 4. This feature is not activated by default, and must be configured (this applies for both on-premise and SharePoint Online.


Enabling AADRM in SharePoint Online
In SharePoint Online to enable AADRM you need to be a tenant admin and you need to first enable it for your tenancy. You can do this by clicking Refresh IRM Settings on the Tenant Settings page and then navigating to the Rights Management page. You can also access this page through the Information Protection menu in the Office365 Admin page.

Another method to enable AADRM is through PowerShell. This can be done as follows:

  • Access the Windows Azure AD Rights Management administration module for PowerShell (this is WindowsAzureADRightsManagementAdministration.exe and may need to be downloaded from http://go.microsoft.com/fwlink/?LinkId=257721). Running this file will install the Rights Management module on your computer.

  • Once installed, open PowerShell and run the following script:

Import-Module AADRM
Connect-AadrmService -Verbose

  • Enter the Office365 tenant admin credentials when prompted and then run the following script:

Enable-Aadrm
Disconnect-AadrmService



Enabling IRM in SharePoint 2013 On-Premise

As with the previous release, enabling IRM in SharePoint 2013 is done by associating a pre-installed/configured Active Directory Rights Management Services (ADRMS) server role with the SharePoint farm. Once you have an ADRMS server setup and running, associating a SharePoint farm to it must be done by a SharePoint Farm Admin in Central Admin on the Information Rights Management page. Typically an ADRMS server is identified through Active Directory, and you can configure the SharePoint farm to use this, or you can configure the SharePoint farm to point to a particular ADRMS server that is not identified in Active Directory.

The Information Rights Management page has the following radio button options:
  • Do not use IRM on this server
  • Use the default RMS server specified in Active Directory
  • Use this RMS server (and then you must specify the path to the server)
There is an additional checkbox option on this page titled:

Check this box in multi-tenant configurations to allow tenants to configure tenant level IRM settings

Setting IRM to specific SharePoint on-premise subscriptions in a multi-tenant deployment requires this check box to be checked on, and then PowerShell is used to set the specific RMS server URL for each tenant. However, multi-tenant configurations is beyond the scope of this article.

Note: SharePoint 2013 on-premise can only target on-premises RMS servers, and SharePoint Online can only target AADRM.


Configuring Document Library Level IRM Settings
Once IRM or AADRM has been enabled, then site collection administrators can configure individual document libraries to use IRM to protect documents.

“Some Things Change while Some Things Stay the Same”

-somebody

Capabilities from SharePoint 2010 that are the same in SharePoint 2013
As with the previous version, the following capabilities of IRM in SharePoint have not changed in 2013:
  • IRM settings are configured on individual document libraries
  • Once IRM settings are configured for a document library these settings will be applied to every (supported) document in the library
  • It is still not possible to configure different IRM settings for different documents in the same library
  • Once IRM settings are configured, only supported document formats are protected and those documents are protected (encrypted with embedded usage rights) when they are downloaded from SharePoint – supported documents still include only the Microsoft Office document formats (Word, Excel, PowerPoint)
  • Documents within IRM protected document libraries are not protected while they are sitting “at rest” in SharePoint – this is done to allow the search crawler to index the contents of documents
  • IRM within SharePoint will only protect documents in document libraries, and attachments to list items – it will not protect the list items themselves
  • Within the detailed IRM usage rights for a document library, only ad-hoc settings can be specified – you cannot configure it to use an ADRMS template
  • When a document is protected upon downloading/opening it from SharePoint it can be protected for the individual downloading it so that only they can open it or print it

New IRM Capabilities in SharePoint 2013
The following capabilities are new or enhanced in SharePoint 2013:
  • The configuration user interface for IRM settings has been improved slightly – you can now create a permission policy with a title and description, and then specify detailed usage rights for it
  • The detailed options and usage rights include the previous options from SharePoint 2010, along with a few new options:
    • Enable users to print the document
    • Run scripts to enable screen readers
    • Enable users to write/save on a copy of the document locally
    • Set an expiration date, after which the document can no longer be opened
    • Automatically stop protecting the document library with IRM after a certain date
    • Do not permit unsupported documents (document formats not supported by IRM) to be added to the document library
    • Control whether Office Web Apps can display documents from the library in the browser
  • You can now specify in the IRM usage policy if documents will be protected for an AD group
  • PDF files are now a supported IRM document format (woohoo!)
    • This is an extension to the PDF format however, and you’ll need to ensure your PDF reader can support it; he PDF reader from Foxit already supports this feature
  • A number of PowerShell interfaces are now available to programmatically control and configure IRM in SharePoint 2013

Protecting Files for a Group
This last option is really powerful – in the past and by default in SharePoint 2013, each file type that is supported will be encrypted and rights restricted by IRM to the authenticated user who downloaded the document. Other users who had rights to the same library always had to download their own copy from the library. Now in SharePoint 2013 (and Office 2013) if documents are IRM protected in a document library for an AD group, when I download that document I can share that document between members of the AD group. The document is no longer only protected for me. This feature is also supported in SharePoint Online with AADRM.

Prevent Opening Documents in the BrowserRegarding the setting for ‘controlling whether Office Web Apps can display documents from the library in the browser’, Office Web Apps in 2013 are now able to render and display protected documents in the web browser. So, if a user does not have Microsoft Office client applications installed they can still view a read-only copy of the document through the Office Web Apps in their web browser. However, there are a couple of security notes about this:

  • When viewing a copy of a protected document in the web browser through the Office Web Apps, IRM and the Office Web Apps do not prevent screen capturing (just to be clear, you can take screen captures of a document in this case). The Microsoft Office client applications do prevent screen capturing of IRM protected documents.
  • When you are done viewing a protected document in the Office Web Apps, the document information is cleared from the web browser’s cache (at least!)

So, if being able to screen capture protected documents when they are viewed through the Office Web Apps is a serious security hole, its recommended that you check on the Prevent opening documents in the browser for this Document Library option in the detailed IRM usage rights. In doing so, this will prevent the Office Web Apps from opening the documents.

PowerShell Scripting and Programmability for IRM in SharePoint
A great new feature in SharePoint 2013 is the following PowerShell scripts that are now available:

Set-SPIRMSettings -IrmEnabled -UseActiveDirectoryDiscovery

Enable IRM for the farm and configure it to use the default RMS server that is configured in Active Directory.



Set-SPIRMSettings -IrmEnabled -CertificateServerUrl http://RMS_Server

Enable IRM for the farm and specify the URL of the RMS server to use.



Set-SPIRMSettings –IrmEnabled -SubscriptionScopeSettingsEnabled

Enable IRM for the specified tenant and specify the URL of the RMS server to use. For example:

$site = Get-SPSite http://myspserver
$subscription = $site.SiteSubscription
Set-SPSiteSubscriptionIrmConfig -Identity
$subscription -IrmEnabled -CertificateServerUrl http://RMS_Server



Set-SPIRMSettings -IrmEnabled:$false

Disable IRM for the farm.

As well, there are a number of APIs available in the object model to configure similar settings programmatically. You can learn more about this here: http://msdn.microsoft.com/en-us/library/jj175397(v=office.15).aspx.

Client Support Matrix
The following matrix from Microsoft details which client applications support IRM Protected documents:

App​ SharePoint 2013 SharePoint Online 2013​ RMS Server RMS Online
​Word, PowerPoint, Excel 2013 (windows)  ​Yes ​Yes ​Yes ​Yes
​Word, PowerPoint, Excel 2013 RT ​Yes ​Yes ​Yes ​Yes
​Word, PowerPoint, Excel 2010   ​Yes ​Yes (After you install the Office 365 sign-on assistant.) ​Yes ​Yes
​Office for Mac 2010   ​Yes ​ No   ​Yes ​No
​Outlook on Windows Phone 7 ​NR   ​NR  ​Yes ​No
​Word on Windows Phone 7   ​Yes ​No  ​Yes ​No
​Foxit PDF reader on Windows ​Yes ​Yes (After you install the Office 365 sign-on assistant.) ​Yes ​Yes

 

Conclusion

IRM for SharePoint is a great way to protect sensitive documents and list item attachments in SharePoint from leaking out of the organization or from being shared inappropriately within the organization (an example of this is emailing a spreadsheet with executive salaries widely within a company). Some additional options have been added to SharePoint 2013 to make this feature a bit more flexible and easier to use.

That said, this feature is still not fine grained enough for many organizations I’ve spoken to due the fact that all documents within a library get the same IRM settings. As well, this feature is still a bit too limiting for those organizations because only the main Microsoft Office files are supported (Word, Excel and PowerPoint). PDF files are now supported, which is a great addition, but organizations need to ensure that have a supported PDF reader to open and read protected PDF files.

Now, what happens when you want to share an IRM protected document with someone outside the organization? This is the classic issue with AD RMS. Does anyone have a solution to that challenge?