Updated SharePoint 2013 Software Boundaries and Limits: Unique Permissions

I am really happy to report a recent update to the SharePoint 2013 Boundaries and Limits web page.  Large enterprises in particular can have extremely large requirements for their SharePoint environments and this site has proven to be invaluable in determining what SharePoint can do, what it can't do and which boundaries can be pushed to the brink.

The update I want to highlight is related to SharePoint security scopes.  Security scopes in SharePoint are also referred to as "unique permissions" or "fine grained permissions".  People often think of fine grained permissions when they refer to a document or library that requires some unique permission for a user or group (for example, a spreadsheet containing senior executive salaries might require unique permission to prevent other individuals from being permitted to view or access it).  In fact, whenever permission inheritance is broken on a document, item, folder, library or subsite, a new security scope is created.

For years, advisors in the SharePoint community have been telling SharePoint administrators and consultants that they should avoid fine grained permissions because this would cause performance issues for end users when navigating through SharePoint or retrieving content that needs to be security trimmed.  As well, there was a lot of confusion in the community about whether the threshold at which performance issues started was 1000 or 5000 security scopes.  There were several Microsoft publications on this topic with differing numbers.  In fact, this limitation was previously true in older versions of SharePoint and in early releases of SharePoint 2010. 

However, this limitation has been seen for some time as a real problem for many organizations that deal with very sensitive information.  Examples of these are the military, governments, defense organizations and large regulated enterprises.  They deal with large amounts of very sensitive information and very strict regulatory compliance requirements, so creating new sites or libraries with specific permissions and having all content within inherit those permissions is simply not practical in these environments.

I'm very happy to say that Microsoft has finally updated this threshold! 

Microsoft actually released an update to SharePoint 2010 in the summer of 2011 to address this issue.  With SharePoint 2010 Service Pack 1, with the August 2011 cumulative update or higher, this threshold on security scopes was actually raised to 50,000.  As well, the point at which multiple round trips to the SQL database occur was clarified - its actually when the number of unique security scopes (unique permissions) in a list or library exceeds the List View Threshold setting.  Its not a hard setting of 5000 items that triggers multiple SQL roundtrips to occur.

Despite this very significant update, the documentation related to this threshold was not updated at that time.  SharePoint 2013 was released with the same security scope threshold of 50,000.  The goal for that release was to hold this line, which is great.  However, again the documentation was not updated.

At last, as of March 5, 2013, the documentation related to this threshold has now been updated to reflect this change! 


Security Scopes Section in SharePoint 2013 Boundaries and Limits Documentation
 

The full site on SharePoint 2013 Boundaries and Limits can be found here: http://technet.microsoft.com/en-us/library/cc262787.aspx.  A big thank you to the Microsoft folks I've been speaking with about this issue for making the update!

At TITUS we have been working in the realm of unique permissions and security scopes for years.  We work with military, government organizations and large enterprises around the world helping them to secure access to sensitive information in SharePoint.  So this is a welcome change.  We have had customers in the field with several libraries and lists containing between 50,000 and 60,000 unique security scopes, and after significant testing after the update to SharePoint 2010 Service Pack 1 (with appropriate CUs)  they've found that their end users are not experience performance issues when navigating these lists and libraries or searching for content. 

Its important to note that the Security Scope value is a threshold and not a hard limit, so you can surpass 50,000 if you really want to or if you can throw enough hardware at the problem.  Remember, the number which can be used without experiencing performance issues is not unlimited, so unique permissions must still be applied appropriately where needed.  That said, they are a useful tool in cases where sensitive information or regulatory compliance requirements requires that permissions be applied at a fine grained level in order to ensure the right users are accessing the right information... and I would suggest that we in the community can stop recommending against their usage.

This is a significant and welcome change for Microsoft SharePoint, especially in environments that deal with sensitive information, or compliance obligations.

     - Antonio

Microsoft Office Arrives in the Cloud on Feb. 27th

I'm very excited that next week Microsoft is hosting two Office 365 Virtual Launch Events on Feb 27^th at 8am and 5pm PDT.

Virtual Launch Event for the new Office 365 for business

Date Wednesday, February 27^th 8 am PDT and 5 pm PDT

Why Attend?

•   Learn how the new Office 365 can help people do
their best work in a world of devices and services

•   Hear customers talk about how Office 365
is transforming the way they deliver productivity
tools across their organization

•   See how Office 365 delivers new experiences
combining the power of social with collaboration,
email and unified communications

•   Join in a live Q&A with Microsoft executives
and product experts

 

Make sure you sign up and attend to learn all about this awesome offering for business.
     - Antonio

Locking Out Farm Admins from Sensitive Content in SharePoint 2010

It’s amazing - I get asked all the time about if there is a way to lock out farm administrators from accessing sensitive content in SharePoint.  Last December, I was asked 3 times within an hour of completing a conference session on SharePoint Security and, in all 3 cases the question was related to SharePoint sites that contained sensitive information and documents related to Mergers and Acquisitions.

This is a common problem that we in the community often hear about.  Often the answer give is “there is no way to do that” or “you have to move that content to Office365”.

Just to restate the problem:  Farm administrators in SharePoint are in effect “super users” and they have access to everything within the SharePoint farm.  The farm administrator role is an IT role, which involves solution deployment, back end configuration and infrastructure management.  By definition the farm administrator is an IT function.  However, in many commercial organizations with sensitive information the IT staff is not permitted to view or access sensitive business date, especially if that information is subject to regulatory compliance or audit requirements.  In the government, military or intelligence community the IT staff is typically not Top Secret cleared, meaning they do not have Top Secret security clearance and therefore are not permitted to access classified or confidential government information.  But remember, farm administrators can access everything.  Yes you can configure farm administrators to not be able to view or access content, however they have sufficient privileges to give themselves back rights to access content.

I’ve thought about this problem over the last few months and tried to come up with some possible solutions to suggest.  Here is one suggestion I made to some people that asked me this question late last year.

The first thing you need to consider is which individual(s) is the content owner for the sensitive content that you are protecting.  You need to ensure that they have ultimate rights to manage permissions to this content.  This person must also be able to serve as a backup to edit or restore permissions should they get truly out of hand in the library holding this content – so an individual with a technical aptitude or some training for the content owners may be required.  Remember you are intentionally locking out the farm administrator (and possibly the entire IT staff) from viewing or accessing content, and this includes managing or restoring permissions as well.  So, the farm administrators can no longer serve as a backup to restore or manage permissions.

Next you should consider using Microsoft's Information Rights Management (IRM) feature within SharePoint to protect and encrypt content as it leaves SharePoint.

So, there is some configuration that needs to be done at the farm level to turn on IRM - this needs to be done by that farm administrator we mentioned above (so this solution is not fool proof).  Once IRM is turned on, it can be pointed to a Microsoft AD-RMS server within the same network.  Microsoft AD-RMS (or Active Directory Rights Management Server) is the server that will generate keys, actually encrypt content and manage the rights that are assigned to individual documents that are protected.  So, this is a server that needs to be setup and managed like any other server. You should ensure that the SharePoint farm administrator is not the same person that administers Microsoft AD-RMS - in fact, in this case ensure that the SharePoint farm admin doesn't have any access to the Microsoft RMS server.  You can find a good overview on Microsoft AD-RMS here.  Once SharePoint IRM is turned on, then site owners can configure on a library by library basis which libraries have IRM applied and what rights will be enforced (this part is not a farm administrator function).

Essentially, when using the IRM feature within SharePoint, when a user downloads a document from SharePoint it will be encrypted on the way out.  As well, it will have certain rights associated with it (like 'do not print' for example).  This protection is built in such a way that to decrypt the document, after it is downloaded from SharePoint, and access the content within is simply a matter of opening the document in the appropriate application (ex. Microsoft Word, Excel or PowerPoint).  An IRM projected .docx file still looks like a .docx file.  It is the payload (or content) within the .docx file that is encrypted.  The encryption and decryption of that content happens completely seamlessly from the end user trying to access the content.  And of course, only users for which the content has been encrypted will be able to decrypt it.  Keep in mind, SharePoint IRM encrypts the documents only when they are downloaded or opened from SharePoint.  Documents actually sit in the clear while they are within SharePoint - this is done so that the contents of the documents is still index-able and searchable.

So, the idea behind using SharePoint IRM being a suggested solution in cases where SharePoint farm admins are not permitted to access sensitive content is:

• You can certainly turn off their access to see it through out of box SharePoint configuration. 
• As an additional measure you can use the IRM feature within SharePoint to encrypt sensitive documents on download, so that even if the SharePoint farm admin gives themselves back access to view documents in SharePoint, if they download those documents they will be encrypted for other users and they will not be permitted to access the content within.

There is still a hole in this as mentioned above:  the SharePoint farm admin can completely turn off the IRM feature.  To resolve this at this point, either in SharePoint 2010 or SharePoint 2013, would involve looking for (or developing) an auditing and alerting solution that would monitor this type of configuration change in SharePoint Central Admin and issue alerts if the feature was disabled or modified.

If this is a possible solution for you then I recommend you take at an article I wrote a little while ago on Understanding and Configuring Information Rights Management in SharePoint 2013.

-Antonio

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:

• Get-SPUserLicensing
• Enable-SPUserLicensing
• Disable-SPUserLicensing
• Get-SPUserLicense
• Get-SPUserLicenseMapping
• New-SPUserLicenseMapping
• Add-SPUserLicenseMapping
• Remove-SPUserLicenseMapping

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.

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?

Finding "Manage Permissions" in SharePoint 2013?

In SharePoint 2010, most people are aware that there is a menu item available on each item in a list or document in a library called "Managed Permissions".  This allows the owner of a document or item to manage the permissions on that item if needed.  This means that a user with sufficient priviledges can add users or groups with various permissions levels for that document or item, thereby granting others a particular level of access to it.

In some organizations, this is not an appropriate process.  SharePoint administrators often do not want invidual users managing permissions at this fine grained item level.  There are various reasons for this which can range from concern about compliance violations, or sharing information with the wrong people, or to performance issues. 

In other organizations, like with some of our US Intelligence customers, allowing the owner of a document or item to manage permissions for the item is desirable.  In these cases, the policy is that the content owner or author of a document is the person that is best equiped to understand who requires access and who should not have access.  So, accessing the Manage Permissions page through this menu item on each document has been a useful to a number of organizations.  We have seen this type of policy implemented successfully when authoring documents is limited to a small number of very skilled people, who in particular understand the ramafications of sharing sensitive information with the wrong people (for example, where its well known what is meant by classified or sensitive information and that if you leak classified information to the wrong people then you go to jail).

When I fired up SharePoint 2013 a few weeks ago, I was surprised to find that the Manage Permissions menu had moved.  So, to find the Manage Permissions page in SharePoint 2013, you're going to do the following:

• Activate the menu on an item or document by clicking ... in the library or list view for that item
• On the window which appears click ... again
• Select "Shared With" from the menu
• On the Shared With page, you're going to click "Advanced"

And sure enough, you'll now be in the familiar Manage Permissions page with similar options like "Manage Parent", "Stop Inheriting Permissions", "Check Permissions", along with all the controls for adding and removing permissions once you have broken inheritance. 

The page itself has not really changed from SharePoint 2010, but how you access it obviously has.

-Antonio

SharePoint Conference 2012: My Session Picks

The first wave of the TITUS crew arrived at SPC12 early this morning (Saturday).  We're getting settled in, registering for the conference and making sure all our stuff arrived.

We're very excited about this show.  We've got some great new features to show in the TITUS SharePoint Security Suite, so please stop by booth #865 if you're interested in talking about SharePoint security and about how TITUS helps you automate and manage it.  Namely, if you're interested in:

• Securing information in SharePoint at a fine grained level
• Raising awareness about sensitive content, with automatic visual security labels on Office or PDF documents
• Enforcing access control policies in SharePoint so that sensitive content can sit beside non-sensitive content
• Denying access to specific users even if they're part of groups that have access
• Enforcing security automatically and dynamically using metadata and/or claims and without impacting performance
• Managing security policies at the site collection, site or library/list levels
• Auditing permissions and policy administration by administrators

 ...we have some awesome new features to show you!

Using the MySPC site to look over and pick sessions was really helpful, but there is a huge selection and it was really hard to choose from those available.  I've ended up with a session list that looks great, but I've got quite a few overlapping sessions so it'll ultimately be a tough choice to figure out which ones I make it to.  As I've written in a couple of other articles I'm really impressed that about 10% of the 300+ sessions are about security, governance and managing risk within SharePoint.  As you can imagine, most of my session picks fall within that category.  I've also focussed on the speakers that I know to be real experts in their fields - those that I've read extensively and seen present in person.

Here's my larger session list, as it currently stands.  Hopefully this helps some of you focus in on the sessions you want to attend:

Monday

1.       Keynote (8:30- to 10:30)

2.       SharePoint Server 2013: What’s new for IT professionals (11am – 12:15pm)

3.       What’s New with Enterprise Content Management (2 – 3:15pm)

4.       Customer Showcase: ECM Governance principles at Shell - Best practice in managing multi-terabyte document management scenarios (3:45 – 5pm)

Tuesday

5.       Overview of the new SharePoint Online (9 – 10:30am)

6.   Gimmel:  records management in the cloud (10:45 – 11:45am)

7.   Showcase:  Microsoft’s 200TB Records Management System (10:45 – 11:45am)

Tough choice!

8.   SharePoint 2013 Performance and Capacity Management (1:45 – 3pm)

9.   Understanding OAuth, Rest and Odaa (1:45 – 3pm)

Tough choice!

10.   Automating SharePoint Governance and Management (3:15 – 4:30pm)

11.   SharePoint 2013 Identity and Authentication Smackdown (5 – 6:15pm)

Wednesday

12.       User Profile Synchronization Best Practices in SharePoint Server 2013 (9 – 10:15am)

13.       Implementing Federated Services (1:45 – 3pm)

14.       Deep dive on Information Rights Management in SharePoint 2013 (3 – 4:15pm)

15.       How do we do it:  Building and Managing SharePoint Online (3 – 4:15pm)

16.       Custom Security Trimming for Search in SharePoint 2013 (3 – 4:15pm)

Tough choice!

  

17.       Deep dive: Integrating SharePoint metadata with other metadata stores (5 – 6:15pm)

18.       SharePoint data security and compliance (5 – 6:15pm)

19.       Customer Showcase: Exelon-Constellation meets Business Critical Compliance Requirements with SharePoint (5 – 6:15pm)

Tough choice!

Thursday

20.   Best Practises for records Management (9 – 10:15am)

21.   SharePoint Web Templates for on-premise and the Cloud (12 – 1:15pm)

Of course there's also lots of parties and events happening outside of sessions to look forward to as well. Hoping to connect with many people while here. If you'd like to meet up feel free to drop me a line or stop by booth #865 - if I'm not there my colleagues can get a hold of me or setup a time for us to meet.

Enjoy SPC12!
 -Antonio

On-Demand Webinar NOW Available: Take Control of SharePoint Security with Joel Oleson

Thank you to everyone that attended our recent webinar on "Take Control of SharePoint Security" with Joel Oleson and myself.  We had over 800 registrants, a great crowd of almost half that attending on the call and a really informative discussion about SharePoint security!  The on-demand version of the webinar is now available here: 

On-Demand Webinar: Take Control of SharePoint Security

Joel presented some of the real-world scenarios that he's seen in the field where native SharePoint security wasn't sufficient for organizations who are storing sensitive information in SharePoint.  Then I talked about native SharePoint security features that are available in SharePoint Server 2010, how to configure them and how they can help organizations in various scenarios.  I also shared a few thoughts about security in SharePoint Server 2013.  We had 2 polling questions where we received over 200 responses each! A follow up piece will be available soon with those results.  We finished up with some discussion about how the TITUS Security Suite for SharePoint can help secure sensitive information in SharePoint, automatically at a fine grained level, using either metadata about your content or claims about your users.

You can now access the presentation as well:  Slides: Take Control of SharePoint Security.

There were some great questions asked at the end - we tried to get to as many as we could in the time we had.  We have saved all the questions, and for any that we ran out of time to answer, there are answers in the works and you should be receiving an email shortly with a response to your question.

Please do let us know if you have any other questions.

Thanks again.
   -Antonio

Upcoming Webinar with Joel Oleson: Take Control of SharePoint Security

I’m excited to announce that “SharePoint Joel” and I will be co-presenting a webinar on Thursday, October 4^th at 12pm ET (you can register here). As most of you know, Joel Oleson is one of the world’s top SharePoint experts, and is highly regarded for his dedication to the SharePoint community and his #1 SharePoint IT blog, www.sharepointjoel.com.

At the webinar, Joel and I will be speaking about SharePoint security, including best practices to enable secure information sharing, enhance risk awareness, and apply SharePoint policies. Through our discussion of real-life security and data governance scenarios, you’ll discover how to:

• Protect sensitive content without spending your whole day managing ACLs and groups
• Share information securely between departments, with business partners, and with end customers – without having to create separate document libraries
• Instantly deny access to SharePoint content when a user’s status changes, such as employee resignations or terminations
• Make users more accountable for safe security practices when they download sensitive content
• Enforce fine-grained security policies without impacting SharePoint performance

The webinar is called “Take Control of SharePoint Security – Best Practices to Prevent Information Exposure”. It will include an open Q&A session, where you can ask us any questions about your own SharePoint security challenges. I’m sure it will be a great session, with lots of discussion about SharePoint data governance and compliance, and technical topics such as metadata, permissions, and claims-based authorization.

Register today to discover how to implement an effective data security strategy for your Microsoft SharePoint deployment.

Configuring Site Collection Admin in a SharePoint 2010 Claims Enabled Web App

The other day I was working with one of my claims enabled SharePoint 2010 web application and I was logged in as (what I thought) was a site collection admin.  But, I noticed that some of the features that I should have access to on the site settings page for the root site were not available - features like configuring SharePoint auditing and audit trimming. 

I double checked I was logged in as an administrative user account. -CHECK. 

I double checked that I was accessing the correct web application URL -CHECK.

I double checked that I was accessing the root web site settings page, and that I was in fact missing links that a site collection administrator should be able to access.  -CHECK

I logged into SharePoint Central Admin and double checked that my administrative user account was configured as the site collection admin.  My user account was set as the Primary Site Collection administrator. -CHECK.

So, what was the issue?  In an attempt to resolve the issue, I reviewed the SharePoint authentication configuration for my web app. 

For my claims enabled web application I was logging in through ADFS 2.0 (Active Directory Federation Services) as a trusted identity provider and retrieving a SAML token.  When configuring a SAML trusted identity provider you need to chose an "identifier claim" - that is 1 claim which uniquely identifies every user in the domain.  I often choose email address claim because an email address must be globally unique. You must configure ADFS2 to return the email address attribute when a user logs into.  As well, you must configure your SharePoint 2010 trusted identity provider with your chosen identifier claim when registering the provider through PowerShell - this powershell configuration often looks like this:

$map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

# Define other variables... cert, realm, signinurl...

# Adds the STS to SharePoint

$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS20 Provider" -Description "SharePoint secured by ADFS20" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl $signinurl -IdentifierClaim $map.InputClaimType

In the past, I have run into issues logging into SharePoint when configured as such if the email address attribute is no populated in AD (Active Directory).

So, I double checked that my administrator user account had a valid email address and it did.  -CHECK

I checked the Central Admin site collection administrator configuration again, and found that I had configured my Primary Site Collection admin with the AD username 'SPDEMO\administrator' which normally would work fine in a non-claims enabled web app.  So, I decided to try changing it to the identifier claim:  administrator@spdemo.titus.local.

I logged in again and found the same thing was happening.  I would navigate to the site settings page for the root site and would only see links that a site owner would see, and not links that a site collection admin should see.

So, I returned to the Central Admin site collection administrator configuration page reset my Primary Site Collection administrator to 'administrator' and set my Secondary Site Collection Administrator to the identifier claim: administrator@spdemo.titus.local.  As in the following:

Voila!  When I logged back into my claims enabled web application as the same user, I was now in fact a site collection administrator.  I could now navigate to the Site Settings page in my root site and I could see the links that should be available to a site collection admin:

So, it turns out that in a claims enabled web application a site collection administrator needs to have both their AD domain\username and their identifier claim set as the site collection administrator identity.

 -Antonio

Product Review by Joel Oleson: TITUS Metadata Security for SharePoint

Joel Oleson is probably one of the most well known SharePoint experts, bloggers, and community members.  He travels widely promoting and talking about the many aspects of SharePoint.  He recently reviewed one of our products here at TITUS: Metadata Securtiy for SharePoint.  Joel provides a fair assessment of the product, where it fits into the SharePoint space and the value that it brings to customers that are managing access to sensitive information in SharePoint.

Joel talks about how the product fits in with the security and governance needs of many organizations today, especially as they work towards achieving compliance with the appropriate standards for their industry.  His insights and experience into how organizations are looking at their governance requirements and very well written.  We highly encourage you to read his full article in particular to learn about which aspects of governance, compliance and security are important to industries today and how you can address them in your SharePoint environments.

Some of the points that Joel brings out are:

• TITUS Metadata Security for SharePoint provides a lot of great features for managing your environment, based on metadata.  The key thing to understand is that it is dynamic.  It enforces governance, based on rules or attributes of a user.
• TITUS Metadata Security for SharePoint  provides the proper controls at the right levels while dynamically addressing your data governance needs.

He also provides a great description of the product, how it works and how its used by TITUS customers today:

• What you’ll get from TITUS is a rules engine that will not correct user behavior 100%, but it will provide additional insight and make it easier for users to do the right thing.
• I am happy to see a solution like this that starts to bring focus on making SharePoint compliant, and can do it in a straightforward way that is easy to understand.”

You can read Joel's full article article here: Product Review of TITUS Metadata Security by Joel Oleson.


The TITUS Security Suite for SharePoint enhances SharePoint security and ensures that security policies are applied consistently and automatically across all your sensitive content in SharePoint. These solutions ensure the right people see the right information, raise the awareness of sensitive information and promote end user accountability. The TITUS Security Suite for SharePoint is made up of two products:

TITUS Metadata Security for SharePoint
TITUS Metadata Security protects information in SharePoint by ensuring that the right people are accessing the right information. TITUS enhances SharePoint security by automatically applying permissions to sensitive documents and lists based on their metadata. With Metadata Security Claims Edition, organizations can combine metadata and trusted user claims to control access to content. With TITUS Metadata Security for SharePoint, there is no need to manually define access rights for every document, and you can be sure that security access policies are applied consistently and automatically across all your sensitive content in SharePoint.

TITUS Document Policy Manager
TITUS Document Policy Manager protects information in SharePoint by raising awareness and promoting end user accountability. TITUS automatically marks Microsoft Office and PDF documents in SharePoint with visual labels and converts documents to Adobe PDF. With TITUS Document Policy Manager, organizations can apply visual labels and document conversions consistently and automatically to all relevant content in SharePoint, ensuring consistent and compliant security is applied across the entire enterprise.

You can find out more about TITUS Metadata Security for SharePoint on the product web site.

Thanks Joel!

-Antonio

SharePoint Saturday Toronto July 2012 - Developing Custom Claim Providers for Authorization

Today, I'm in Toronto.  Toronto is warm, its sunny, its a Saturday and there are a ton of people here for SharePoint Saturday Toronto!  WOW, apparently the organizers got 700 registrations to attend and event that had 300 spots.  Lots of interest here in all things SharePoint.

This morning I gave a session in the Developer Track on Developing Custom Claim Providers for Authorization.  Thanks to everyone that attended!  For those looking for my slide deck, it is now live with all the code samples and it can be found here: 

Developing Custom Claim Providers to Enable Authentication in SharePoint 2010. 

If you have any questions or feedback please add a comment or send me an email.

To everyone at SPS Toronto, enjoy the rest of the day and enjoy SharePint.
     -Antonio