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?

Monday, November 12, 2012

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

Saturday, November 10, 2012

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

Wednesday, October 17, 2012

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

Tuesday, October 2, 2012

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 4th 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.

Tuesday, September 4, 2012

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


Tuesday, August 28, 2012

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

Saturday, July 7, 2012

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: 


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

Saturday, May 26, 2012

Securing Information in SharePoint Search

When it comes to securing access to content in SharePoint, a question that often comes up is "Can you secure access in Search as well?". 

The search capability within SharePoint, whether its native search or FAST search, is a really critical component for end users because it helps them find the information they're looking for in what is always (for all organizations) an ever growing SharePoint repository.  It helps end users more quickly access the information they need to get their work done.  So, the topic of securing access to senstive information when searching in SharePoint is important.

The answer to this question is YES.  One method of doing this is through SharePoint permissions.  As we know, permissions applied at any level (site, library/list, folder or item) can be used to secure access to sensitive content. SharePoint permissions or ACLs are respected by both native search and FAST search so that if a user does not have permissions to access an item, when they search for that content it will not be presented as part of their search results either.  However, there are some important details that need to be considered when generally configuring the native search capability.

A few weeks ago, I came a across a great post by Veronique Palmer, SharePoint MVP from South Africa and founder of Lets Collaborate, that goes into some detail about how to configure SharePoint search in order to secure access to content. 

Veronique states:
As a Site Owner or Site Collection Administrator, you can decide if the content on an entire set of sites can be available in search results or not; or the content of a specific list or library; or the data that exists in columns and web parts – all without setting permissions.
She discusses various options available in SharePoint for configuring the native search capabilities, including:
  • Search and Offline Availability Settings for sites
  • Search options for web parts
  • Searchable Columns for libraries/lists
Veronique goes on to make another important point:
You need to have governance in place as to what is considered sensitive or confidential content – that must be clearly define.  You need to decide what the security levels all your content needs to be and tag all your content accordingly. This is also a legislative requirement in many industries. All this needs to be clearly communicated to your user base.
Her post is definetly worth a read and the full article can be found here: Restrict What Content Can Be Searched in SharePoint (for Business Users).

-Antonio

Sunday, May 13, 2012

The Laws of Identity - Kim Cameron & His Identity Blog


A collegue recently pointed me to Kim Cameron, the former Chief Architect of Identity and Access at Microsoft, as a source of information about federated digital identity and claims.  Despite my readings into claims based identities and authorization over the last 2 years, I'll admit that I had not heard of him.  The more I read the more I found that his contributions were fundamental to the development of digital identities and related technologies.  As a fellow Canadian and Blues Brothers fan, I decided to write a short article discussing some of his contributions and point you to his excellent blog (which he still maintains).

Kim Cameron started at Microsoft in 1999, and he left in May 2011.  It turns out that during his time there he led all things to do with identity. He is credited with contributing greatly to the development and popularization of Claims as an intrisic part of digital identities.

One of his most significant contributions has been The 7 Laws of Identity.  Published in January 2006, I find it amazing how relevent they are today in 2012 - even more so today in fact.  These 7 laws helped to codify in real-world terms what we in the industry should build in order to enable robust use digital identities for authentication, authorization and federation.  I'm reprinting them here with the sole purpose of helping to spread the word, in the hopes that this helps educate people in the industry about how identities should be managed in the digital world.

You can find Kim's full description of the 7 Laws here: Kim Cameron's 7 Laws of Identity. The following are the 7 Laws in point form, reprinted as Kim wrote them, with a little annecdote from me. 

1. User Control and Consent - Digital identity systems must only reveal information identifying a user with the user’s consent.

[My Comment] Absolutely - if a system is going to reveal details about me to another system (or to other users or other developers) I want to ensure that its only with my consent.  For me to use an identity system I need to trust it, and in order to trust it the system must put me in control of my identity.  In order for me to feel that the system is maintaining the privacy of my personal information, I need to be in control of what information is shared, and with whom.  Facebook and Facebook Apps are a great example - when a user accepts use of a Facebook App, they are prompted with a message warning them that if they proceed they are permitting that app to have access to their user profile information.  Although I personally find that this message does not go far enough in warning the user, it is a step in the right direction.  Facebook has gone further in recent years towards enabling privacy of user data by allowing users to turn off access to certain portions of the user profile in their privacy settings.

Although many in the identity management industry might say that my Facebook profile is not my digital identity but rather a version of my digital identity, for many people out there (especially many young people) it is in fact their main digital identity.

2. Limited Disclosure for Limited Use - The solution which discloses the least identifying information and best limits its use is the most stable, long-term solution.

[My Comment] This law can also be described as "need to know" - in other words, only release information to systems which have a well defined need to know; as well, only release the specific attributes about me which a system has a need to know.  For example, to purchase something online a vendor needs to know my credit card number, but they do not need to know my social insurance number (social security number in the US), but both may be part of my digital identity.  The full text of this law also includes the notion that systems should only retain personal information on a need to know basis. 
3. The Law of Fewest Parties - Digital identity systems must limit disclosure of identifying information to parties having a necessary and justifiable place in a given identity relationship.

[My Comment] I personally find this law similar to #1 and #2, but there is an important nuance - for me, this law is more about if a system is authenticating and that system is to receive information about my identity (so attributes about me) then that system should be required to present a policy as to why the information is needed and how it will be used... then the identity management system managing my attributes can make decisions about how much personal information is disclosed to this system that's requesting information about me.  This to me is really important, in terms of helping keep my personal information private - the importance of this is becoming more and more apparent to the average person as identity theft grows.  Its also something that Microsoft technologies do not do well yet.

4. Directed Identity - A universal identity metasystem must support both “omnidirectional” identifiers for use by public entities and “unidirectional” identifiers for private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

[My Comment] The way I read this one is that we can each have multiple versions of our Digital Identity - some that we make public (like my Twitter account) and some that we keep private (like my corporate domain account).  A public representation of my digital identity is said to be Omnidirectional because I can and wish to transmit it to multiple public systems.  A private representation of my digital identity however is said to be Unidirectional because I want to transmit it in only one direction - for my corporate domain account at work, I only want my work place's servers to have access to it.  Today, this is dealt with by my having multiple accounts that I maintain.  However, if we are ever to have a unified way of managing our digital identities, where I have 1 digitial identity and multiple representations of it to use for different purposes, then this concept becomes very important.

5. Pluralism of Operators and Technologies - A universal identity metasystem must channel and enable the interworking of multiple identity technologies run by multiple identity providers.

[My Comment] We will always need multiple ways to present an identity.  The example used in Kim's 7 laws talks about having a government identity for when I file my taxes, and having a different identity for when I log into my employer's corporate network, and that makes sense.  This law, I believe, speaks to having multiple operators which manage our identities being able to interoperate in an open and standards-based way in order to allow us as individuals to control who and what has access to which parts of our digital identities.  This is presented as a more viable alternative to having 1 single operator that manages our identies and provides access to them for all purposes.

6. Human Integration - A unifying identity metasystem must define the human user as a component integrated through protected and unambiguous human-machine communications.

[My Comment] Its very worth reading the full text about this law, in Kim's document about these laws. This law comes down to us in the industry doing a better job of bringing the end user into our identity management systems in a more integral way... which I believe would be a very good thing to help fight phishing attacks and other attempts to steal our identities.
7. Consistent Experience Across Contexts - A unifying identity metasystem must provide a simple consistent experience while enabling separation of contexts through multiple operators and technologies.

[My Comment] In this law, Kim talks about various examples of identities that individuals may have, some public (for web browsing, for community interactions, for corporate collaboration) and some private (for personal web-based relationships, for purchasing, for government related activities).  He talks about the need to turn our digital identities into "things" that computers users can see and interact with - each of these digital identities revealing different aspects or attributes about us.  Different online services we interact with will (referred to as Relaying Parties) require us to reveal different information about ourselves - some require simply an email address, while others require a credit card number.  End users will need to understand the different options available to them and thereby select the best options for the given service or the given context.  Again, I believe this law is more important now that ever, as we conduct more and more of our activities online and they require important and detailed information about us.
Overall, these 7 laws provide a framework for us in the identity, access and security space to use when building our online services which intrinsicaly require digital identities.

In order to read Kim's writings directly, please see his web site here:  Identity Blog.

Various Microsoft technologies have made some great strides in recent years towards adopting or enabling some of these concepts.  In particular, Microsoft SharePoint 2010, with its support for Claims-Based-Authentication and Claims-Based-Authorization has gone a long way at starting people down the road of adopting claims and integrating digital identies into their business process in a more detailed and fundamental way.  As well, Microsoft Active Directory Federation Services 2.0 is a key enabler of claims in the Microsoft stack.
There is a great interview with Gartner and Kim from 2007 found here where he discusses Claims and the 7 Laws of Identity, and its again amazing how such much of this is more relevant today when you think about how you want your digital identity managed and accessible: http://www.gartner.com/research/fellows/asset_187313_1176.jsp.

Kim's 7 Laws are very relevant today with the use of digital identities growing more and more, for both consumer use and business purposes.  Technology is getting there, in terms of providing appropriate support for privacy and security related to our digital identities, albeit rather slowly. We've seen some great progress in recent years with the popularization of SAML and OAUTH, and their use by leading software and online service providers.  I'm hopeful that we'll continue to see a continued adoption of Kim's 7 laws in the coming years, as we see ever increasing use of digital identities in our online world.

-Antonio






Thursday, April 19, 2012

Welcome - Launching TrustSharePoint.com

Hello and welcome to my new blog at www.TrustSharePoint.com.  This is my first post on this blog and I thought I would share a little bit about myself and talk about some of my technology interests as they relate to SharePoint.  As well, I'll point to some of my recent blog postings at TITUS where I work.  Going forward I'll contribute both to this blog, and to the TITUS SharePoint blog.

I am a first time Microsoft MVP for SharePoint Server.  I just recently received this award which was a big surprise and a great honour!  I'm a Senior Product Manager at TITUS responsible for the TITUS Security Suite for SharePoint and for the common information protection platform across all the TITUS solutions.

My technology interests include information security, assertions/claims and the trusted identity space, cryptography, federated identity, SAML, OAUTH and the like.  I'm also interested in information protection policy, a number of technologies available around that, and how they might be used to provide better security within SharePoint and the Windows desktop.  My personal interests include oil painting, my family, and some outdoor projects around my home.

Over the last 2 years, I have been blogging about information security in SharePoint 2010, the use of claims for authentication and authorization, permissions management in SharePoint, using Active Directory Federation Services version 2.0, and federated identity topics.  I've given several conference sessions at SharePoint conferences in North America and Europe, including the Microsoft SharePoint Conference in October 2011 in Anaheim, CA.  Here are just a few of my favorites from my previous blog postings:

What are Claims – Using Claims in SharePoint

Sometimes claims are referred to as metadata about a user – I’ve been guilty of this one myself.  To over-simplify the topic, we sometimes hear them spoken about as Active Directory attributes or LDAP attributes. People often talk about the concept of claims in a very simple manner, saying that claims represent user attributes or attributes about a user.  To understand the concept, you have to view claims as an assertion that I make about myself.  In other words, a claim is an attribute that I claim to have or be.  For example, I can tell you that I am Canadian.  I can tell you I’m a Canadian of Italian heritage.  You may or may not believe me.  This is something that I’m claiming about my identity.  If you were to look at my passport, perhaps you’d be more inclined to believe this claim, because my passport is an official document that many agencies trust.  If you were to ask someone that you trust about me, and that person happens to know me well, then you would likely be inclined to trust what they say about me. In the digital world, a claim must be trusted by the dependant application or relying party application.  

To read more, check out the full blog here.

An Architecture for Claims Based Authorization in SharePoint

I’ve spoken to many people recently about enabling Microsoft SharePoint 2010 to work with Claims to enhance both Authentication and Authorization in SharePoint. I’m finding that many people are still trying figure out where all the pieces fit in a SharePoint architecture that makes use of claims – there are new concepts to understand and often new infrastructure to be configured. Overall the concepts tend to be easier to understand than people realize once they dig into them a little. This article is designed to explain the concepts and applications required in one example of a SharePoint 2010 architecture which enables Claims Based Authentication and Authorization. Lets start with a diagram of what a SharePoint server architecture that uses Claims can potentially look like. 

To read more, check out my full blog here.

 

Configuring SharePoint 2010 with ADFSv2 to Retrieve Claims

When configuring SharePoint 2010 for claims based authentication or authorization you typically need to connect to an identity provider to retrieve user attributes as claims. To really see all the benefits of claims in the enterprise, we need to ensure that our SharePoint Server trusts the claims its receiving, and that often means configuring it to connect to a “trusted identity provider”. One such server application that can act as a trusted identity provider is Microsoft Active Directory Federation Services version 2.0 (ADFSv2). ADFSv2 is often also referred to as a ’secure token server’ because it plays the role of retrieving user attributes from Active Directory (or some other LDAP directory or data store), wrapping them up in a SAML token, digitally signing that token and returning it to the calling application – in this case SharePoint 2010. Configuring ADFSv2 in such scenarios can be tricky and unforgiving, and this article focuses on 1 particular part of that configuration – the Realm.

To read more, check out my full blog here.


Part 1: Claim Rules - Claims Based Security in SharePoint 2010 with ADFSv2

In general, claim rules can be used to centrally evaluate, transform or augment claims before they are returned to a relying party application like SharePoint. Microsoft Active Directory Federation Services version 2.0 (ADFSv2) can act as a trusted identity provider to SharePoint and other relying party apps.  It provides a great interface with templates for creating and editing claim rules as part of its management console.  As well, it provides a ‘claim rule language’ that can be used to configure detailed policies with very specific conditions. This allows us to configure specific claims to be retrieved under very specific conditions, and thereby enforce very specific security policies for authentication and authorization.
This series of articles talks in detail about how to use this mechanism to enforce dynamic access control policies within SharePoint 2010 and, it illustrates how these policies relate to particular industries and regulations in SharePoint.

To read more, check out my full blog here.

Part 2: Claim Rule Language - Claims Based Security in SharePoint with ADFSv2

In a recent post I introduced the concept of claim rules within Microsoft Active Directory Federation Services 2.0 (ADFSv2) and the templates it provides.  Claim rules can be used to easily evaluate, transform or augment claims before they are returned to a relying party application like SharePoint.  In this post, the second in the series, we dive into ADFSv2’s Claim Rule Language and how it can be used to issue claims under more specific conditions, retrieve attributes from external data sources and implement some unique scenarios. This post is only going to deal with ‘issuing outgoing claims’.  These are claims that ADFSv2 will return to a relying party application.  It is important to note that ADFSv2 has a set of incoming claims (and those can be configured) that our claim rules will refer to as part of their conditions, and it has a set of outgoing claims that will be returned to SharePoint in this case.

To read more, check out my full blog here.



Part 3: Checking Multiple Groups - Claims Based Security in SharePoint with ADFSv2

Implementing claims based authorization in SharePoint 2010 provides great alternatives to using security groups in order to control access to sensitive content in SharePoint.  Traditionally, security groups have been used to restrict access to content or to enforce a role based security mechanism.  However, organizations are quickly finding that security groups, whether they are SharePoint groups or Active Directory groups, do not scale well in large enterprise environments.  Many enterprises already have large numbers of groups deployed, so how can those organizations still make use of those groups to enforce advanced security policies without complicating group management further?  As well, how can they check membership to multiple groups in order to allow access to sensitive content? This article focuses on using claim rules in Active Directory Federation Services version 2 (ADFSv2) as an efficient mechanism to enforce security policies in SharePoint based on group membership.

To read more, check out my full blog here.

Building a Custom Claim Provider to Manage Security Clearances

Microsoft SharePoint 2010, with its built-in support for retrieving trusted attributes about a user upon login (or what is commonly referred to as claims), can be used to authenticate users and authorize access to content. As I’ve written about previously, this allows businesses to implement new and interesting information protection policies. SharePoint also allows us to build and deploy custom claim providers that can retrieve attributes from a wide variety of sources and transform them in order to enforce specific policies within SharePoint. This article will walk through a simple example of building a custom claim provider and review some of the technical considerations that need to be taken into account.

To read more, check out my full blog here.

Using AD Groups in a Claims Based Web Application

I ran across an interesting little side effect of altering my claims enabled web application in SharePoint 2010 the other day I thought would be useful for others to know about. The situation has to do with accessing AD Groups from within the SharePoint people picker in a claims enabled environment.

To read more, check out my full blog here.

RSA 2012 Wrap Up and Observations – Identity is Critical for Authorization

Reflecting on the incredible conference that was RSA 2012 last week, you can easily see how Identity has become critical to implementing real-world authorization scenarios in many businesses and government/military departments. There were many hot topics at RSA this year including: Cloud, Mobile and of course APTs (advanced persistent threats). With 22,000 attendees it was easy to get overwhelmed with the myriad of sessions and solution providers. However, Identity or using aspects of a user’s identity specifically for authorizing access to information or resources was everywhere. I gave session at RSA this year entitled Using Claims for Authorization in SharePoint, MS Outlook, Windows 8 and the Cloud. Thanks to everyone that attended. Keep reading to access my presentation deck from that session.


To read more, check out my full blog here.

Thanks for reading.  Let me know if you find any of the topics particularly interesting, if you have any comments, or if you'd like to see some specific topics covered in new articles.
-Antonio