Follow me on Twitter @AntonioMaio2

Monday, December 19, 2016

A Practical Overview of Office 365 Advanced Security Management - Part 1
Introduction & Audit Logs

In June 2016, Microsoft released its first iteration of Office 365 Advanced Security Management, a new capability within the Office 365 platform that allows organizations to go above and beyond the typical security management features that let them secure users, permissions, content and apps. In September the team added the Productivity App Discovery feature, and in October the solution continued to progress with additional capabilities to manage app permissions.

This multi-part blog series will look at how to use the features that make up Advanced Security Management and share some technical details that you will hopefully find helpful.

In part 1 of this series we introduce Advanced Security Management and share technical details about how it works with the Office 365 Unified Audit Log.
Let's jump in...

SharePoint 2010 Security Patches - How Vulnerable Are You?
UPDATED: December 2016

YES, this blog post is about SharePoint 2010! 

YES, SharePoint 2010 is old, over 6 years old actually. 
YES, its no longer officially supported by Microsoft, without very specific Premiere Support that is.
YES, we still see a lot of it out there!
YES, if you're going to continue to stick with SharePoint 2010 for now, you must keep current with security patches!

One of the most common security issues we see with SharePoint 2010 farms is that administrators have not kept up with security patches and updates.  This not only makes it difficult to support and maintain the environment, but it also opens your farm up to security vulnerabilities - security vulnerabilities that have already been fixed! 

This article reviews all SharePoint 2010 security updates that have been released in the last 5+ years since Service Pack 1, and discusses the importance of keeping up to date with those patches.

Sunday, December 4, 2016

SharePoint Saturday Ottawa: How Secure is My Data in Office 365? [Updated Slides]

Thanks to everyone that attended my session in Ottawa this weekend. There were some good questions and I hope everyone found it helpful. Please let me know if you have any questions.  For those folks who think that Office 365 is not secure, please read this previous post and my slides carefully and please reach out with questions!

You can also find another post of mine with some discussion about just how secure your data is in Office 365 here: http://www.trustsharepoint.com/2016/10/how-secure-is-my-data-in-office-365.html.

My most up to date slides, which I presented this past weekend, can be found here:



Enjoy!
-Antonio

Thursday, November 3, 2016

Office 365 Security
New Innovations Announced at Microsoft Ignite 2016

I had the privilege of attending the Microsoft Ignite 2016 conference in Atlanta, GA this past September.  It was of course full of great sessions, demos and announcements.  I was impressed at how many of those sessions focused on the security capabilities of the Office 365 platform. I left with the feeling that, through these sessions, announcements, demos and innovations, that Microsoft is clearly demonstrating their commitment and continued investment in providing a secure environment for our corporate data in Office 365.  They've robust feature set that enables both them as operators of the service, and us as customers and users of the service, to protect our sensitive data in Office 365.

That said, the security of our data, even within the Microsoft cloud, is always a shared responsibility. Microsoft provides the most secure cloud platform available and with that robust feature set, they give customers the ability to control how information is secured, accessed, shared, governed and monitored.  Its still up to us as customers to make efficient use of those controls in ways that protect our businesses and keep our users productive.

As we saw at Ignite, Microsoft has continued to innovate providing us ever more robust security controls for Office 365.  In this blog we're going to look at some of the great new security features that were demo'ed and revealed that Microsoft Ignite.  At the end of this blog, I've also included the slides from today's webinar.

Monday, October 24, 2016

When to Use What in Office 365 +
What Can We Share Externally in SharePoint Online?

On October 4th I gave a presentation at the Microsoft Technology Center in Houston on When to Use What in Office 365. It was part of a free roundtable seminar series offered by Protiviti. We had a great turn out and a lot of really good questions. Thank you to everyone that came and my sincere apologies for the delay in posting this presentation.  I wanted to share my slides with the attendees and anyone that reads my blog, and answer a particularly interesting question that came up during the presentation.

Thursday, October 20, 2016

Synchronizing Custom AD Attributes to Office 365 - Part 3

This blog is the 3rd in a 3 part series on synchronizing and working with custom AD attributes in Office 365. In this post we continue with our final step, showing you how to customize the AD Connect synchronization rules.  This will allow your custom AD attributes (customized by extending your AD schema) can be stored in extension attributes in Office 365, so that you can retrieve and work with them.


So, how do we get our custom on premise AD attributes into Office 365 extension attributes so that we can use the Windows Azure AD Module for PowerShell to actually read them?

Synchronizing Custom AD Attributes to Office 365 - Part 2

This blog is the 2nd in a 3 part series on synchronizing and working with custom AD attributes in Office 365. In this post we continue with showing you how to retrieve attributes in Office 365 using PowerShell.


PowerShell can be used to both verify that your custom attributes have actually been synchronized to Office 365, and it can be used to actually accomplish things with those attributes, like having them sync'ed to your user profile in SharePoint Online (but that's for another article).

Synchronizing Custom AD Attributes to Office 365 - Part 1

Synchronization of identities has come a long way since the early days of DirSync.  We've now seen 2 major releases of the latest generation sync tool, Azure AD Connect, and it has introduced a long list of new features.  End of support for DirSync and Azure AD Sync are scheduled for April 13, 2017 (announcement).

If you're looking for a list of the benefits of upgrading to the latest version of AD Connect, please see my blog on that topic here: Why upgrade DirSync to Azure AD Connect.  One of those great new features is the ability to synchronize directory extension attributes or even custom attributes from an on premise Active Directory environment to Azure AD within Office 365.  This post is about some of the limitations still in place around custom attributes, and some suggestions on how to deal with them once they've been synchronized.

Monday, October 17, 2016

How Secure Is My Data in Office 365?

A few weeks ago, on September 21, I gave a session at the DFW user group meeting called How Secure is My Data in Office 365?  Thank you to all those that attended and my apologies for the delay in posting my presentation.  Life has been busy.

I actually get asked this question quite often from clients that are concerned about migrating their data and workloads to Office 365.  Organizations tend to have an easier time when it comes to moving Exchange to Office 365.  However, the question tends to come more from clients considering moving SharePoint team sites or OneDrive for Business to the cloud.

Its important to consider the question from various angles.  Here is a summary of the points I make during my session to help answer the question...

How secure is my data in Office 365?


Sunday, October 2, 2016

Office 365 Nightly PowerShell Scripts: Encrypting Admin Credentials

When using remote PowerShell to perform tasks in Office 365 we typically need to provide our administrator credentials to create the initial connection.  These are typically a Global Administrator's username & password, or at least an Exchange or SharePoint administrator's username & password.  These are highly privileged accounts and we need to ensure that the username and password associated with these accounts do not get compromised or stolen.  So, when we need to run remote PowerShell scripts on a nightly automated basis, without administrator intervention, how do we secure those highly privileged credentials?  

Monday, September 26, 2016

Microsoft Ignite 2016 - Must See Sessions for Office 365 & SharePoint Security

Welcome to Microsoft Ignite 2016 in Atlanta Georgia!  
This year's conference will once again be full of great content and great speakers about the Microsoft solutions that we all work with.  Myself, I tend to be interested in more technical content about SharePoint Server, SharePoint Online and the Office 365 service.  It looks like the session line up won't disappoint!

As my work tends to focus on security, information protection, information governance and identity management, my conference session schedule tends to focus on technical sessions related to these topics.  Here are my MUST SEE session picks for this week.

Wednesday, September 7, 2016

New Office 365 Data Centers in the UK (and elsewhere) Helping to Meet Data Residency Needs

When it comes to the security of your information, "where" it is stored matters... to many.

"Where" in this case, refers to the country in which the data actually sits.  Concerns about storage location or country is often referred to as Data Sovereignty or Data Residency (https://en.wikipedia.org/wiki/Data_residency).  To some, data sovereignty is a very important privacy concept when they consider the security of their data - people will talk about retaining ownership of data, not allowing foreign governments to have access to data through legal or judicial processes and keeping data secure from prying eyes by service providers, police services or governments agencies (ex. NSA).  Often, these concerns refer to the U.S. Patriot Act as a source of the issue with many believing that the U.S. Patriot Act gives US government agencies wide sweeping abilities to access anyone's data stored on US soil, or managed by any US firm.

More often than not though, what executives and data owners in organizations outside the US are concerned about is a perception problem: the perception of storing data in another country some how being less secure, or the perception that a foreign government agency can access your organization's data.  Sometimes the concern is about an organization storing data in a foreign country getting into the media... and the media story thus creating a perception problem for the organization.  In reality, the U.S. Patriot Act expired on June 1, 2015.  It was replaced by the U.S. Freedom Act on June 2, 2015, which has similar provisions to the U.S. Patriot Act, but imposes new limits on data collection activities by U.S government agencies.  As well, there are already international legal procedures in place, which predate the U.S. Patriot act, which allow one country to request data from another country about an organization when legal wrong doing is suspected... and the country being requested will usually comply.  All that said, there are some countries (Ex. Germany with the German Data Protection Act), or states/provinces within countries (Ex. Nova Scotia and British Columbia in Canada), which do have such laws in place and they typically refer very specifically to the storage and privacy of the personal data for individuals (PII or personally identifiable information).  Some companies also have policies in place which mandate that the organization's data must be stored and housed within the organization's country boundaries.

As a result, whether its a concern of perception or a legitimate law or policy, Microsoft continues to make it easier for organizations to meet their data residency needs.

Today, Microsoft announced that new Office 365 data centers are now available the United Kingdom - you can visit the official announcement here.  Multiple data centers are now available in the UK to help organizations meet in-region data residency, fail over and disaster recovery requirements. This will to help address the legal, regulatory and compliance needs of Microsoft clients in the banking, government, public sector and healthcare industries.

In June 2016, we saw new data centers launch in Canada for Office 365 and Azure (in Toronto and Quebec City).  As well, June brought us new data centers in Germany hosting Microsoft Azure, with Office 365 coming later this month (in Frankfurt and Magdeburg).  Although, as a standard security policy, Microsoft does not disclose the exact location of their data centers, we can see which countries and cities the data centers are located within:

  • You can view the Microsoft Office 365 data centers that are currently available here: Office 365 Data Center Map.
  • You can view the Microsoft Azure data center regions that are currently available here: Azure Regions Map.
These new data centers are a huge investment and continue to reaffirm Microsoft's commitment to provide the most secure cloud services in the industry.

Tuesday, July 5, 2016

Why Upgrade DirSync To Azure AD Connect

I've worked with several clients recently that are still using older versions of the Microsoft Active Directory synchronization tool, affectionately named DirSync, and have not yet upgraded to the latest version which is now called Azure AD Connect.  Integrating your on-premises directory with Azure AD makes your users more productive by providing a common identity for accessing multiple resources.  Managing the synchronization process in a well planned, robust and automated way helps to ensure that users can reliably access both on premise and cloud environments in Office 365.

Short Product History

DirSync was a free tool from Microsoft originally released in 2012/2013 which synchronizes Active Directory objects like user accounts and groups from an on premise Active Directory forest to an instance of Azure Active Directory. That Azure Active Directory instance can reside in Office 365. 

DirSync allowed organizations that wanted to move internally hosted services to Office 365 to still manage their user accounts within an on premise AD forest if they wished. This simplified the migration process to Office 365. It was also a required base technology component if you wanted to deploy services in a hybrid configuration with Office 365 - for example, if you wanted to use a SharePoint farm on premise and SharePoint Online in Office 365, and have those environments work together.

 DirSync received a major update in Oct 2014, which most notably removed the need for the FIM infrastructure, and was renamed to Azure AD Sync (AAD Sync). At that time, both DirSync and Azure AD Sync continued to be supported because AAD Sync did not include all capabilities of DirSync.

In Jun 2015, another major update was publicly released and the product was once again renamed to its current form: Azure AD Connect 1.0.  AD Connect combines all capabilities of both DirSync and AAD Sync into one product.  At this time, DirSync and AD Sync are deprecated and all future fixes/enhancements are being implemented in AD Connect.  In February 2016, AD Connect version 1.1 was released with more major new enhancements.  When installing version 1.1, ensure that you install Azure AD Connect version 1.1.110.0 from February 26, 2016 or later, which can be downloaded here: Azure AD Connect Download.

DirSync & Azure AD Sync Deprecated & Support Ends April 2017 

We already know that all new investment has been placed in Azure AD Connect, and no new updates are being released for DirSync or AAD Sync.  However, on April 13, 2016 Microsoft announced that both DirSync and Azure AD Sync are now deprecated.  As well, Microsoft will officially end support on April 13, 2017 - here is the Official Announcement.

This alone is one major reason to upgrade to Azure AD Connect.

Reasons to Upgrade to Azure AD Connect

If you're looking for more specific reasons to upgrade to Azure AD Connect from the original DirSync, here are those which I feel are most notable:
  • Replacement of FIM - The underlying FIM (ForeFront Identity Manager) infrastructure has been completely removed and replaced with its own dedicated infrastructure, allowing for much more customization and control over the synchronization process.  In the past, we had ways to manipulate the sync process, but they would not have necessarily been supported by Microsoft.  The control and flexibility we now have is fully supported by Microsoft.
  • Automatic Upgrades - The upgrade process to AD Connect from previous versions, including DirSync and AAD Sync, is very simple,  You simply run the installation wizard for AD Connect on the server in which you are already running any previous version (DirSync, AAD Sync or even a old versions of AD Connect) and the wizard seamlessly upgrades to the latest version of AD Connect.
  • More Frequent Synchronization - The default scheduling frequency has been modified from occurring every 3 hours to every 30 minutes.  This is a huge change which allows changes in user accounts in your on premise AD to get to Azure AD and Office 365 much faster.
  • Built-In Scheduler - AD Connect now has its own built in Scheduler for controlling the timing of the synchronization process.  Previous versions used a scheduled task in Windows Task Scheduler, and having its own built in scheduler means that you have greater and supported control over the timing and frequency of the synchronization process.
  • Manual Synchronization via PowerShell - You can manually start a full synchronization process using the PowerShell cmdlet: Start-ADSyncSyncCycle -PolicyType Initial.  If you wish to only synchronize changes, you can modify that slightly and use Start-ADSyncSyncCycle -PolicyType Delta.  This is useful when you have a multi-forest environment which can take a very long time to sync, depending on the number of objects.
  • Robust PowerShell Support - The product now has robust PowerShell support for a whole suite of commands including starting sync, stopping sync and even configuring the scheduler.  You can even check the status of the current sync which is in progress by using the cmdlet: Get-ADSyncConnectorRunStatus.  You can see a full list of commands supported here: Azure AD Connect Documentation and Azure AD Connect Scheduler.
  • Multi-Factor Authentication for the Global Admin Account - You can now use Azure multi-factor authentication (MFA) when first configuring the AD Connect installation and when doing its first synchronization with Azure AD.  This is new in version 1.1.
  • Domain and OU Filtering - You may now select specific domains or organization units (OUs) to synchronize in the AD Connect configuration wizard. Although it was previously possible to do this in Azure AD Connect by manipulating the sync services console, this is now much easier to configure and manage.  This feature allows you to more easily focus the synchronization process on only specific domains or specific OUs in your organization, thereby simplifying the overall and ongoing management of the process.
  • AD Attribute Filtering - We are able to filter users for the synchronization process based on AD attributes. 
  • Change the User's Sign In Method (even after first sync) - In previous versions, if a user's sign in method changed you needed to delete the synchronization configuration and reinstall it.  It is now possible to change a user's sign in method after first configuration and first sync, simply by running Azure AD Connect configuration wizard again.
  • Staging Mode - You can deploy a 2nd AD Connect server in the AD Forest in "Staging Mode".  This allows the server to be on standby, should the main synchronization server become unavailable.  Switching the Standby Mode AD Connect server to full active mode is still a manual process.
  • Azure AD Connect Health for Sync - This new component is installed with AD Connect and allows you to automatically monitor the health of your AD synchronization process.  It will automatically send alerts email notifications related to the health of the environment, when critical events occur.  It will also provide insights into the latency of the sync process, or trends related to user adds, updates and deletes.  More information is available on this component here and here.


Some of these features came with the upgrade to AAD Sync, but many were only recently provided in AD Connect 1.1.  The release history of Azure AD Connect can be found here: Azure AD Connect Release History.

We have seen major updates to DirSync over the last several years which provide a lot of value to our environments by making it much easier to manage the synchronization process for on premise user identities to Azure AD and Office 365.  Due to these great new capabilities and the fact that support officially ends April 13 2017 for both DirSync and Azure AD Sync, the upgrade to Azure AD Connect is highly recommended and necessary.

   -Antonio

Thursday, June 30, 2016

SPTechCon Boston: Real World SharePoint Information Governance Case Studies

Thanks to everyone that attended my session today at SPTechCon in Boston on Real World SharePoint Information Governance Case Studies!  We had a great crowd with lots of really good questions. I hope everyone got something useful or helpful out of the presentation.

You can find my slides from the session here:


Please reach out if you have any questions.
Enjoy.
-Antonio


Tuesday, June 28, 2016

Data Loss Prevention in SharePoint 2016 & Office 365
How to Protect your Sensitive Information

Thanks to everyone that attended my session on SharePoint 2016 and Office 365 Data Loss Prevention yesterday.  It was great to meet everyone and share my thoughts and experience related to Microsoft's DLP technology within these two products.

The Microsoft Data Loss Prevention (DLP) capability that's now integrated into Office 365 and SharePoint 2016 is a great advancement in information security within these products.  It allows you to easily find sensitive data within your SharePoint or OneDrive for Business environment and automatically enforce policies on that content.  Those policies can identify sensitive information for end users, providing them with policy tips on how to handle it.  They can also block sensitive information from being accessed, and issue automated incident reports when policies are violated.

There are some prerequisites and dependencies that are important to understand when configuring DLP policies.  There are also some key differences between the DLP solutions within an on premise deployment of SharePoint 2016 and Office 365.

Prerequisites

In SharePoint 2016, the prerequisites for setting up DLP are the following:

  1. Create your search service application, define a crawl schedule and perform a full crawl.
  2. Configuring out going mail is highly recommended, so that policy notifications can be sent via email.
  3. Turning on Usage Reports is highly recommended, so that incident reports and overrides can be logged appropriately.
  4. Create an eDiscovery Center or Compliance Policy Center site collection, or both.  
    • You must create a different Compliance Policy Center per web application - you cannot have one that applies to all site collections across all web applications.  
    • However, you can create one eDiscovery Center site collection which can run DLP queries across all site collections in all web applications.
  5. Assign permissions to your compliance team, risk team and/or information security team so that they may access and manage DLP policies.  Its recommended that permissions are granted by making these users members of the Site Collection "members" group.

In Office 365, these prerequisites are taken care of for you.  You can simply access the Security and Compliance Admin Console within your tenant's Office 365 Admin Center, and start creating policies.

Dependence on Search

As we talked about in the presentation, the core data source behind both the SharePoint 2016 and Office 365 DLP is the SharePoint search index.  If content is not in the search index, the DLP engine won't find it.  This makes it all the more critical to have a healthy search and crawl configuration.

If you have explicitly excluded certain sites or content from SharePoint search, DLP policies cannot be applied to those areas.

When new content is added to SharePoint 2016, a crawl must occur and the search index updated with that content.  In addition, there are 4 timer jobs that must run to enforce DLP policies.  All this must occur before DLP polices can be enforced on sensitive information.

Options for Creating DLP Policies

In Office 365 a DLP policy is created by:

  • Specifying the locations where it may be applied: 
    • SharePoint Online (all sites or specific sites)
    • OneDrive for Business (all sites or specific sites)
  • Configuring one or more DLP Rules - rules are made up of:
    • Conditions
      • Select any number of 80 sensitive data types.  You may not create custom sensitive data types.
      • With each sensitive data type select the min and max # of instances
      • Who content is shared with (people inside or outside the organization)
      • Metadata properties
    • Actions
      • Send an email notification (default message or custom message)
      • Show a policy tip (default tip or custom tip)
      • Allow override (with or without business justification)
      • Block content (to all users except site owners, document owners or last modified)
    • Incident Reports
      • If a report is logged
      • Severity level
      • Send an email with the report
    • Configure some general settings for the rule like a name and description.
  • Configure some general settings like a name and description for the policy, as well as if it is configured.

In SharePoint 2016, a DLP policy is similarly created, but there are some differences:

  • Specify a name.
  • Select from one of 10 policy templates.  Each policy template relates to a combination of 10 sensitive data types.  
  • Select the number of instances of the sensitive data type which trigger the policy.
  • Specify an email address to which an incident report will be emailed
  • Select whether or not to display a policy tip (you cannot customize the text of the policy tip)
  • Select whether to block access to the content to all users except site owners, the document owner or the user that last modified the document.
  • Then you must assign the policy to a site collection where you wish it to be enforced.  You must specify each site collection one at a time.  You cannot easily apply it to all site collections.  As well, you cannot specify the application of a policy down to the subsite level.

In SharePoint 2016, it can take up to 24 hours for a DLP policy to be enforced on new documents.  Once again, you must wait for the search crawl to run, and then the 4 timer jobs related to this feature to run.  Even if you try to execute the timer jobs manually, I have found through testing that it can take up to 14 hours in a small SharePoint 2016 farm.

Areas for Improvement

As eluded to above, in Office 365 you can search for up to 80 sensitive data types.  In SharePoint 2016 on premise, you can only search for 10 - those 10 only relate to US and UK sensitive data types.

In SharePoint 2016, you cannot:
  • Specify more than one policy template per policy.  There is no concept of multiple rules making up a policy as there is in Office 365.
  • Customize which sensitive data types are searched for within the policy template, as you can in Office 365.
  • Customize either the email notification sent or the policy tip shown to the user, as you can in Office 365.
  • Specify any sort of HIPAA related sensitive data types, or sensitive data types from countries other than the US and UK.  Office 365 has access to a greater range of sensitive data types including those from many countries and those related to the HIPAA regulatory compliance standard.


Finally, either in Office 365 or SharePoint 2016, the following limitations currently exist:

  • DLP policies are not enforced on list items.  They are only enforced on documents.
  • DLP policies are not enforced when documents are uploaded to SharePoint.  They are only enforced on content already residing in SharePoint, which has been found by the Search crawler.

Presentation

My slides from yesterday's presentation can be found here:



Some Great Questions

There were some great questions raised that I would like to come back to readers with answers to in the coming weeks:

  • In SharePoint 2016, if you deploy additional language packs would you get additional sensitive data types related to countries or geographies with those languages?  My suspicion is no, but I think this is worth confirming.
  • If you have a hybrid configuration of SharePoint 2016 on premise with Office 365, your search index is combined and stored within Office 365.  In this case, how are DLP policies configured and managed?  What is the user experience like?
  • If you have metadata associated with documents and that metadata contains sensitive data, will the DLP policy be enforced on that document?  In this case, I suspect that if the metadata field is a managed property that is used by Search that it will find and enforce policies on this metadata, however once again this is worth testing to prove out.
Enjoy.
   -Antonio




Sunday, June 26, 2016

How to Disable Directory Synchronization in Office 365

I was working with a test Tenant in Office 365 recently where I had previously configured Directory Synchronization from an on premise Active Directory domain (which actually lived in an Azure VM).  I had recently turned off the Azure VM that hosted the AD domain, and I was now getting Directory Sync errors in Office 365 - which made sense since the domain had not synchronized in a few days.  At the same time, I was getting more and more familiar with the new Office 365 Admin Console which is quite nice actually, but I'm still trying to figure out where everything is found.

I decided to deactivate Directory Sync in my tenant to get rid of the errors.  I know I had seen it before because I've activated and deactivated it many times as I've tested the feature for clients.  But I couldn't find where you do that in the new Admin Console.  Let's take a look.

New Office 365 Admin Console

Here I've logged into my tenant and you can see my Directory Sync errors in the top left of the dashboard.  A sync hadn't happened in 68 hours, which made sense because I had turned the Azure VM off.


If I click on the GEAR icon in the left menu, which represents Settings, I get several options:


I select DirSync Errors in the menu... and I get nothing:


I select Services and Add-Ins and again I get several options:


Select Directory Synchronization in order to (hopefully) manage our directory synchronization options, and then we click another link to get to DirSync Management:


And we get to a nice screen which gives us several status indicators about our Directory Synchronization status (including that it has not synced in 68 hours), but no option to deactivate it:


I clicked the Troubleshooting link thinking that perhaps the option to deactivate the sync process could be found there:

 
 
 
I ran the scans, but again no luck.  I could not find the option to deactivate the sync process, despite how much I searched through the new Admin Console.  At this point, I returned to the old Admin Console to check if the option was still there.

Old Office 365 Admin Console

Once in the old Admin Console, in the left menu click on Users, then Active Users and then next to the Active Directory Synchronization title click Manage and there was my Deactivate option, along with similar status indicators to what I saw in the new Admin Console:

 

 

We click on Deactivate and we get a confirmation screen:


We click Deactivate Now and, finally, we've deactivated Directory Synchronization.  As usual, we're back at our Active User screen which tells us that Directory Synchronization could take up to 72 hours to take effect.  From my experience, it actually happens much quicker than this.


PowerShell

Alternatively, we could simply use PowerShell to get the current status of the synchronization process and disable it.  Here is the process you can follow:
  1. Launch the Windows Azure Active Directory Module for Windows PowerShell (right click the icon and select Run as Administrator).
  2. Type Connect-MsolService to connect to your tenant.  When prompted, login with your administrator credentials.
  3. Type (Get-MsolCompanyInformation).DirectorySynchronizationEnabled to get the current state of the directory synchronization process.  Don't forget the brackets.  If the sync process is enabled it will return True.
  4. To disable the sync process type Set-MsolDirSyncEnabled -EnableDirSync $false.
  5. When prompted to confirm select Y.

You may then type the same command as step 3 to confirm that it was been disabled.  You should get False returned at this point.

(Get-MsolCompanyInformation).DirectorySynchronizationEnabled

Enjoy.
   -Antonio




Wednesday, June 15, 2016

UPDATES: Office 365 Groups - Name Conflicts with Site Collections and Planner

I ran into an interesting situation today when working with Office 365 Groups related to how they are named that I wanted to share.  I had heard that there could be a name conflict that occurs between an Office 365 Group and a SharePoint Online site collection, so I wanted to test this out and understand the user's experience.  Big thank you to Brittany Kwait who contributed to testing these scenarios!

UPDATE 1: In working with the new Microsoft Planner, which was recently released as a new Office 365 experience, you'll also find that it creates an Office 365 Group as part of a new plan.  See below for some additional context into how Office 365 Groups are created and named as part of a Plan. 

UPDATE 2:  Microsoft recently announced here that new administration capabilities are coming to Office 365 Groups, including the ability to configure a Naming Policy in Azure Active Directory for Office 365 Groups.  According to Microsoft, this policy will allow administrators to configure a policy for appending text to the beginning or end of a group’s name and email address no matter where the group is created.  As well, administrators will be able to configure a list of specific blocked words that can’t be used in group names and rely on the native list of thousands of blocked words to keep their directories clean.  This feature is still roadmap and there isn't a committed timeframe yet for release, but I'm hopeful that it will help to address some off the naming experience inconsistencies.

Test 1: Create a New Group

Within the Office 365 portal I accessed by mail using the Outlook Web App and I created a new Group named "testgroup".  I did not click on Files right away in the Office 365 Group interface. 


I left my shiny new Group and navigated to the SharePoint Online admin console.  Here I created a new site collection and named it "testgroup" and gave it the URL https://maiolabs.sharepoint.com/sites/testgroup.  Everything worked fine!  My site collection was created without issue or error, using the name I gave it, which is the same as the Office 365 Group name I had chosen.  Where was the conflict?

I navigated back to my Group, and this time I clicked on Files.  At this point, I immediately got the screen which tells me "We're setting up...".

After a few minutes I got access to the space that was being created within the Group to store my files.  Of course, when an Office 365 Group is created, a OneDrive for Business site collection is created in which group members will store their files.  Now I began to understand what was going on.  The site collection associated with the Group does not get created until you click on the Files tab in the Group interface.  Its important to also note that the OneDrive for Business site collection that gets created in this case is a hidden site collection.

Once my Group space for storing files was created, I got the OneDrive for Business interface as I expected and checked the URL of the site.  It was:

https://maiolabs.sharepoint.com/sites/testgroup53/Shared%20Documents/Forms/AllItems.aspx

Notice the URL doesn't say "testgroup"?  It says "testgroup53".  I found that interesting but nothing conclusive yet.

Test 2: Create another New Group

This time I went back to my Outlook Web App and created another group named "testgroup2".  The Group was created fine as expected and I immediately clicked the Files tab to create the hidden site collection that would be associated with my Group. That also completed fine, and I checked my URL for that site collection and it was:

https://maiolabs.sharepoint.com/sites/testgroup2/Shared%20Documents/Forms/AllItems.aspx

Notice this time, the URL contains the actual Group name without any additional numbers tacked onto the end.  Interesting... Now I returned to the SharePoint Online admin console and created another site collection, this time named "testgroup2" and I ensured my URL was  https://maiolabs.sharepoint.com/sites/testgroup2.  Now I got the error I expected...


The site collection already exists.  Please enter a different address.

Conclusion

As I continued through the process, it was fine for the site collection name to be the same as that of an Office 365 Group.  However, the site collection cannot have the same URL as the OneDrive for Business site collection that is associated with a Group.  This makes sense - whenever an Office 365 Group is created and its OneDrive for Business site collection initialized, a OneDrive for Business site collection is created within SharePoint Online and of course you cannot have the same URL pointing to 2 different site collections.

Its interesting to note that if a site collection already exists with a particular URL and I then click Files in a Group to initiate my Group's OneDrive for Business site collection, Office 365 Groups will alter the URL so that it is unique and doesn't conflict with any site collections. However, this doesn't happen the other way around - if I create a site collection with the same name and URL of an existing Office 365 Group, I get an error and no automatic modifications to the site collection's URLs are made.  This also makes sense - we often want our SharePoint site collection to have a specific URL.

Improvements

What could be improved is the fact that the OneDrive for Business site collection associated with a Group is hidden.  To a SharePoint Online admin who is simply trying to create a new site collection, they may get this error and look at the list of site collections to see which other site collection has the same URL and not see any in their list which conflicts.  Yes the SharePoint admin can simply alter the URL, but they may want the URL to be something specific.  This may also cause them to spend significant time investigating the issue and open a support ticket with Microsoft.  This situation could be made even worse by the fact that, once Groups are enabled in your organization and by default everyone in the organization can create one or multiple Groups, you'll end up with many hidden site collections with no control over how they are named.  So the possibility of a conflict between an existing Group URL and a new site collection could be high.  This is especially true if you get a significant adoption of Office 365 Groups and also use SharePoint Online site collections.

I am encouraged by the fact that, as announced on May 4, later this year Microsoft will be launching the ability to associate a real SharePoint team site with an Office 365 Group.  With that, I'm hopeful that SharePoint Online admins will get real visibility into which sites are associated with which Office 365 Groups, and avoid this naming/URL conflict.

UPDATE: Office 365 Planner - A Connection to Groups

[Thanks again to Brittany Kwait for this update!]

Microsoft recently released a new service within Office 365 called Planner.  Planner allows teams to quickly organize, plan and track work projects and tasks using a highly visual experience: a task board that you might be familiar with from Agile/Scrum methodologies or solutions like Trello.  In using Planner, when you create a new "Plan"  Planner will automatically create a new Office 365 Group that will be associated with the Plan.  The Group will be named the same as the Plan.



If you then try to create an Office Group with the same name, in this case you'll get an error:


Here we get another interesting inconsistency - if you remember, when we tried to create a Group that was the same name as a site collection, the URL was simply automatically adjusted to be unique as part of the Group creation process.  No error appeared.  When we try to create a Group now that's the same name as a Plan, we get an error.  The same will probably happen if we try to create a Group that's the same name as another Group.  These aren't major issues - I just find it nice to know about and expect the inconsistency.

Once again, my point here is that I hope in the future, the new features we are told are coming for Office 365 Groups (Naming Policy, Team Sites associated with Groups) will help us control naming, and have Groups, Plans and site collections all work well together for administrators and end users. 

Enjoy your Groups! ...and Plans!
   -Antonio

Tuesday, June 14, 2016

Vulnerability: SharePoint 2010
MS16-054 CRITICAL - Addressed in May 2016 CU

In May 2016, Microsoft released a CRITICAL security bulletin related to vulnerabilities in Microsoft SharePoint Server 2010.  The vulnerabilities are identified as Remote Code Execution issues.  Full details can be found here: https://technet.microsoft.com/en-us/library/security/ms16-054.

Versions of Microsoft Office are also affected: 2007, 2010, 2013, 2013RT, 2016 and Mac Versions 2011 & 2016.  Microsoft SharePoint Foundation 2010 is not affected by this issue. 

The following services within the identified SharePoint version(s) are specifically affected:

1. Microsoft SharePoint Server 2010
    • Word Automation Services on Microsoft SharePoint Server 2010 Service Pack 2

    2. Microsoft Office Web Apps Server 2010 Service Pack 2
    • Microsoft Office Web Apps 2010 Service Pack 2

    Background

      According to the official Microsoft Bulletin the following is a summary of the vulnerability:

      This security update resolves vulnerabilities in Microsoft Office. The vulnerabilities could allow remote code execution if a user opens a specially crafted Microsoft Office file. An attacker who successfully exploited the vulnerabilities could run arbitrary code in the context of the current user. Customers whose accounts are configured to have fewer user rights on the system could be less impacted than those who operate with administrative user rights.  The security update addresses the vulnerabilities by correcting how Office handles objects in memory, and by correcting how the Windows font library handles embedded fonts.

      Security Resources


      • CU UPDATE: a SharePoint Server 2010 Cumulative Update addressing these vulnerabilities and other issues is available for SharePoint Server 2010 through the May 2016 Cumulative Update

      • WORKAROUND: There are no workarounds identified specifically related to Microsoft SharePoint Server 2010.  There are several workarounds related to one of the vulnerabilities identified in the security bulletin which involve preventing users from opening untrusted RTF files by implementing registry customizations.

      • REPORTED EXPLOITS: According to Microsoft, at this time there are no reported exploits that have occurred using these vulnerabilities.

      Vulnerability Details

      Multiple remote code execution vulnerabilities exist in Microsoft Office software when the Office software fails to properly handle objects in memory. There are several vulnerabilities listed in this bulletin, most of which apply only to Microsoft Office.  However, 2 are specifically related to Microsoft SharePoint 2010 and details regarding these are available at the National Vulnerability Database:

      Additional notes from Microsoft:

      An attacker who successfully exploited the vulnerabilities could run arbitrary code in the context of the current user. If the current user is logged on with administrative user rights, an attacker could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

      Exploitation of the vulnerabilities requires that a user open a specially crafted file with an affected version of Microsoft Office software. In an email attack scenario an attacker could exploit the vulnerabilities by sending the specially crafted file to the user and convincing the user to open the file. In a web-based attack scenario an attacker could host a website (or leverage a compromised website that accepts or hosts user-provided content) that contains a specially crafted file that is designed to exploit the vulnerabilities. An attacker would have no way to force users to visit the website. Instead, an attacker would have to convince users to click a link, typically by way of an enticement in an email or Instant Messenger message, and then convince them to open the specially crafted file. The security update addresses the vulnerabilities by correcting how Office handles objects in memory.

      Monday, June 13, 2016

      Vulnerability: SharePoint 2007, 2010 and 2013
      MS16-042 CRITICAL - Addressed in Apr 2016 CU

      I'm a little behind in blogging about recently released Microsoft Security Bulletins for SharePoint, but I'll attempt to catch up a bit here...

      In April 2016, Microsoft released a CRITICAL security bulletin related to vulnerabilities in Microsoft SharePoint Server 2007, 2010 and 2013.  In all identified versions, the vulnerabilities found are identified as Remote Code Execution issues.  Full details can be found here: https://technet.microsoft.com/library/security/MS16-042.

      Versions of Microsoft Office are also affected: 2007, 2010, 2013, 2013RT, 2016 and Mac Versions 2011 & 2016.  Microsoft SharePoint Foundation 2010 and Foundation 2013 are not affected by this issue. 


      The following services within the identified SharePoint version(s) are specifically affected:

      1. Microsoft SharePoint Server 2007 (MOSS)
      • Excel Services on Microsoft SharePoint Server 2007 Service Pack 3 (32-bit editions)
      • Excel Services on Microsoft SharePoint Server 2007 Service Pack 3 (64-bit editions)

      2. Microsoft SharePoint Server 2010
        • Excel Services on Microsoft SharePoint Server 2010 Service Pack 2                 
        • Word Automation Services on Microsoft SharePoint Server 2010 Service Pack 2
        UPDATE: For SharePoint Server 2010 specifically, this update was superseded by the May 2016 cumulative update which fixes an additional security vulnerability. My post on that update can be found here: http://www.trustsharepoint.com/2016/06/vulnerability-sharepoint-2010-ms16-054.html.

        3. Microsoft SharePoint Server 2013
        • Word Automation Services on Microsoft SharePoint Server 2013 Service Pack 1

        4. Microsoft Office Web Apps Server 2010 Service Pack 2
        • Microsoft Office Web Apps 2010 Service Pack 2

        5. Microsoft Office Web Apps Server 2010 Service Pack 2
        • Microsoft Office Web Apps Server 2013 Service Pack 1

        Background

          According to the official Microsoft Bulletin the following is a summary of the vulnerability:

          This security update resolves vulnerabilities in Microsoft Office. The most severe of the vulnerabilities could allow remote code execution if a user opens a specially crafted Microsoft Office file. An attacker who successfully exploited the vulnerabilities could run arbitrary code in the context of the current user. Customers whose accounts are configured to have fewer user rights on the system could be less impacted than those who operate with administrative user rights.  The security update addresses the vulnerabilities by correcting how Office handles objects in memory.

          Security Resources



          • WORKAROUND: There are no workarounds identified specifically related to Microsoft SharePoint Server at this time.  There are several workarounds related to one of the vulnerabilities identified in the security bulletin which involve preventing users from opening untrusted RTF files by implementing registry customizations.

          • REPORTED EXPLOITS: According to Microsoft, at this time there are no reported exploits that have occurred using these vulnerabilities.

          Vulnerability Details

          Multiple remote code execution vulnerabilities exist in Microsoft Office software when the Office software fails to properly handle objects in memory. There are several vulnerabilities listed in this bulletin, most of which apply only to Microsoft Office.  However, 2 are specifically related to the identified versions of Microsoft SharePoint and details regarding these are available at the National Vulnerability Database:

          Additional notes from Microsoft:

          An attacker who successfully exploited the vulnerabilities could run arbitrary code in the context of the current user. If the current user is logged on with administrative user rights, an attacker could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

          Exploitation of the vulnerabilities requires that a user open a specially crafted file with an affected version of Microsoft Office software. Note that where the severity is indicated as Critical in the Affected Software and Vulnerability Severity Ratings table, the Preview Pane is an attack vector for CVE-2016-0127. In an email attack scenario an attacker could exploit the vulnerabilities by sending the specially crafted file to the user and convincing the user to open the file. In a web-based attack scenario an attacker could host a website (or leverage a compromised website that accepts or hosts user-provided content) that contains a specially crafted file that is designed to exploit the vulnerabilities. An attacker would have no way to force users to visit the website. Instead, an attacker would have to convince users to click a link, typically by way of an enticement in an email or Instant Messenger message, and then convince them to open the specially crafted file. The security update addresses the vulnerabilities by correcting how Office handles objects in memory.

          Wednesday, June 8, 2016

          SOLD OUT: Microsoft BUILD Tour Canada June 10 - Register to Watch It LIVE

          In just a couple of days, Microsoft BUILD Tour Canada will be returning for 2016. 

          Unfortunately the onsite in person event is now SOLD OUT!  You can still watch it LIVE and experience all the great Microsoft speakers on some new Microsoft technologies that have just been announced. 

          Make sure you register for the live stream here: LIVE STREAM Microsoft BUILD Tour Canada


          This is an awesome, free event that I highly recommend!  Its become really popular year after year!  You'll get:
          • Deep Dives on the top announcements from Microsoft's annual BUILD conference
          • It’s all about new technology: Sessions, Demos and Coding exercises
          • Helps customers prepare their skillsets, app and software businesses for the future using the latest Microsoft technologies
          • Delivered by Engineers from Microsoft HQ
          • Unlike the general Build Conference, this event is completely free event!

          You'll find a number of great sessions including:
          • What's new in Windows 10 and the Universal Windows Platform
          • How to Use a single codebase and adaptive UX to target PC, mobile, Xbox and HoloLens, while connecting to the broader internet of things
          • How to Use Xamarin and Microsoft's cloud services to build rich cross platform experiences with the skills you already have
          • How to Extend your existing Win32/.NET and websites to leverage the latest Universal Windows Platform capabilities




          Thursday, May 19, 2016

          Overcoming Threats and Vulnerabilities in Your SharePoint Environments

          Thank you to everyone that came out to the Atlanta SharePoint User Group meeting on May 16th!  We had a great turnout and it was really nice to talk with everyone.

          You can find my presentation here:



          During the presentation I did a demonstration of the DLP capabilities within Office 365 SharePoint Online, and I discussed the DLP capabilities within SharePoint 2016 server.

          We saw SharePoint Online DLP policies applied to documents containing sensitive data (credit card numbers in this case) to provide policy tips for some documents, and to block access to other documents.  We provided policy tips to documents containing between 1 and 4 credit card numbers, and we blocked access to documents containing more than 5 credit card numbers.  This worked very well - as discussed it took between 15 and 30 minutes for SharePoint Online policies to be applied to new documents that were uploaded to a small library in my tests. For SharePoint Server 2016, this same test took approximately 14 hours to discover the sensitive content and apply the same DLP policies.  If you're wondering, I did have a default continuous crawl configuration in place for the RTM version of SharePoint 2016 server during these tests.

          A related question that came up was whether SharePoint Online DLP policies apply to list items which contain sensitive data as well.  Well, after running a couple of tests in the last few days unfortunately the DLP policies are not applied to list items containing credit card numbers.  I will continue to run tests and report back here any findings I hvae.

          Although I didn't demo the new DLP policies within SharePoint Server 2016, you can find my presentation on DLP within SharePoint 2016 Server on my blog here:



          ...and you can find my webcast with a demonstration of DLP within SharePoint 2016 server here:



          Enjoy.
             -Antonio

          Thursday, May 12, 2016

          Don't Count Content Out of Your Security Audit:
          ECM Must Be In!

          ECM or Enterprise Content Management are the systems in our enterprise which store and manage corporate content. We often think of these systems as applications like SharePoint, Documentum or FileNet, but they can also represent network file shares, NAS drives and custom internal web sites or applications. ECM systems can now exist on premise within data centers that we manage; through a cloud provider like Microsoft Office 365 or Amazon Web Services (AWS); or through a hybrid combination of both. They have grown within most organizations to store sensitive data and to represent critical infrastructure that employees rely on to accomplish day to day work.

          We rely on cyber security audits to evaluate the safety of our corporate environments. Cyber security audits give us an indication of our security posture and identify areas of improvement for cyber defense. As part of an audit, we typically look at things like network security, firewall configuration, communication protocols, intrusion detection -- systems which protect us from external threats, email phishing, malware and URLs leading to malicious websites. A security audit certainly must include these functions; however, ECM systems are often overlooked due to the specific domain knowledge required to properly evaluate all of the systems which make up the corporate ECM. Considering the criticality and often large quantity of data stored in our ECM, it’s important to consider why that is and how we can leverage what we know to facilitate inclusion of ECM systems in a cyber security audit.

          An ECM is typically made up of multiple enterprise applications working together to efficiently store and provide access to content.  They surface a robust set of capabilities to bring additional business value to the organization. These systems are often overlooked in audits due to the specific domain knowledge required to properly evaluate all of the systems which make up the corporate ECM.

          Microsoft SharePoint is a great example – it is a web application with a large set of built in document management features, sitting on top of SQL Server for content storage, surfaced through IIS for web access, with responsive pages for mobile access, deployed to a farm of servers with firewalls, proxies or a combination of both. It can be connected to other systems for authentication, retrieving business data and integration with reporting or business intelligence tools. It integrates with Active Directory for identity management, people search and user profiles which surfaces presence data and user attributes. Custom solutions can also be deployed to SharePoint to fulfill a specific business needs through the robust APIs it makes available. It provides a forms and workflow engine, allowing organizations to gain efficiency through business process automation. It can be configured with an enterprise class search farm to efficiently index content and provide lightning fast search. Search can include content within SharePoint and outside of SharePoint, like file shares. These features may be used to provide an intranet for collaboration, an extranet to interact with partners, a public facing web site or any combination of these. Finally, enterprises typically don’t have just one such SharePoint environment – you often see development, staging and production environments, along with a separate environment for disaster recovery.

          This is really just a small sample of capabilities provided by SharePoint, but represents what general ECM systems look like and what we hope to get out of them. With this in mind and considering all of the systems involved in providing such a robust set of services, a security audit can seem daunting.

          An ECM security audit does require some domain specific knowledge of many of these systems, however we find that the security review process often comes down too many of the same questions or areas of investigation that are used in reviewing other systems, such as:
          • Can we identify all repositories that store enterprise content?
          •  Do we know what types of data are sensitive and do we know where it resides? Do we need to scan repositories for data that is sensitive data from a compliance or risk perspective? Essentially, this is data that puts the organization at risk should a data breach occur, either inadvertently or maliciously. This can be data such as PII, PCI, PHI, MNPI (material non-public information), CPNI (customer proprietary network information), etc.
          • Are data owners for all repositories defined, in particular those storing sensitive data? Are data owner responsibilities clearly defined and are data owners aware of those responsibilities? Do those responsibilities include approving and denying requests for access?
          • Does the organization have record retention policies and schedules? Does the organization have a classification policy? Are information handling and acceptable use policies clearly defined for each type of sensitive data, and are end users educated about these policies on a regular basis? Is it clear to end users when they are working with sensitive data and how to handle it? Are these policies enforced or automated?
          •  Is the process for requesting access to data clearly defined and are end users aware of the process they must use? Are all access requests logged? Are access reviews performed on a regular basis, in particular for privileged or administrative users?
          •  Does the organization have an information governance plan and a governance committee? Does the governance plan cover specific practices related to the ECM system?
          • Do you have the right team in place to manage the ECM? Does the team have enough people and do they have the right skill sets or certifications? Your ECM administrative team needs the appropriate skills to manage it from strategic and tactical perspectives, from a security perspective and from the point of view of the business users.
          •  Is an activity monitoring and reporting system in place? Do those systems interact appropriately with the various components making up the ECM environment?
          • Are the servers making up the corporate ECM environment security hardened?
          These questions typically make up the core aspects of an ECM security audit. The only questions that require specific domain knowledge are the last question, and perhaps the second to last. All others can apply to all ECM environments regardless of the systems involved or integrated. These questions apply to many different corporate systems -- they provide us with insight into which data is sensitive to the business, where it resides, who is responsible, how access is controlled, how policies are enforced, and finally how the system is secured and monitored.

          Due to the criticality of the data stored within ECMs and the fact that typically a majority of employees in the enterprise access and rely on the ECM to accomplish daily work, including the corporate ECM in a cyber security audit is not only recommended but a requirement. As well, we can often leverage what we already know to ask the right questions to help us determine the security posture of our environment and where improvements may be necessary.

             -Antonio

          Tuesday, May 10, 2016

          Data Loss Prevention in SharePoint Server 2016

          Thank you to everyone that attended my webinar on April 28th on Data Loss Prevention in SharePoint 2016.  We had a great turn out.  As I said in the web cast, Microsoft is bringing great features from SharePoint Online like the Compliance Center to the on premise world with SharePoint Server 2016.  This is an excellent advancement for our on premise SharePoint deployments.  My webinar was a review or tour of the Data Loss Prevention features we now have for our on premise deployments with SharePoint 2016.

          Introduction

          Today we're constantly hearing about or experiencing threats to our business, and in particular to our business data.  To protect the business and its reputation, or to comply with business standards or industry regulations, organizations need to protect their sensitive corporate data and put in place measures to prevent its disclosure.  Sometimes that disclosure is inadvertent, or accidental. Sometimes its intentional or malicious.  In either case, a data loss prevention solution (or DLP) is one one of the necessary solutions to this problem.  SharePoint 2016 now includes a robust Data Loss Prevention capability that can help us protect that data.

          More specifically, when we talk about data loss prevention we're talking about automated systems which scan our data for keywords, regular expressions and patterns looking for specific types of data, and then either reporting or enforcing policies on that data.  This includes many different types of data, including:
          • Personally Identifiable Information (PII): passport numbers, social security numbers, tax identification numbers or even drivers licenses
          • Payment Credit Information (PCI or PCI DSS): credit card numbers
          • Financial Data: debit card numbers, bank account numbers, SWIFT codes or routing numbers
          • Health Insurance Data: medical record numbers, policy numbers, patient information
          If we look back, data loss prevention has been a long time feature of Office 365.  However, until recently it was only available in Exchange Online with policy tips and policy enforcement.  In mid-2015, Microsoft announced that the Office 365 Compliance Center would include DLP for SharePoint Online and OneDrive for business, and that solution was released to the various Office 365 tenants through the last part of 2015 and into early 2016.  Now, with the imminent release of SharePoint 2016 Server we also have this capability for our SharePoint on premise deployments.

          Prerequisites

          You need the following prerequisites in place before configuring the SharePoint 2016 DLP within the new Compliance Center:

          • Create a Search Service Application (mandatory)
            • Start the search service, Define a crawl schedule, Perform a full crawl
            • Must have a healthy search index and crawl for DLP policies to be effectively applied
          • Configure out-going email (recommended)
          • Turn on Usage Reports (recommended)
          • Create the eDiscovery or Compliance Center site collections (mandatory)
            • eDiscovery - for DLP queries to identify where sensitive data exists
            • Compliance Policy Center - for DLP policies to monitor and enforce policies
            • One or the other is mandatory - you can create both, but both are not mandatory
          • Assign the organization's Compliance Team with permissions to access the eDiscovery and/or Compliance Center site collection(s) through the Site Collection Members group

            Issue Follow-up: DLP Policy Enforcement Time & List Items

            Some of you will remember that there was an issue with the enforcement of the DLP policies in the library that I was demoing during the presentation.  I was showing a library with a document that contained 5 credit card numbers and the blocking policy was enforced on that document.  However, there were 5 other documents that had 1 credit card number each in which the 'policy tip' policy (or monitoring and warning policy) was not getting enforced on those - even after waiting 12 hours.

            Well, after waiting 14 hours the 'policy tip' policy final got applied to those 5 additional documents.  Considering those documents contained a credit card number, and my understanding is that the policy templates which check for credit cards are considered high priority internally, I would have expected those to be enforced sooner.  

            Please note: I was launching full crawls and the timer jobs which are supposed to enforce DLP policies manually over and over, to no avail.  

            What I have read, that it can take up to 24 hours for DLP policies to be enforced, is obviously true.  If I had a 1000s of users, with millions of documents, and users updating documents adding/removing sensitive information all the time, I could understand the 24 hour wait time.  But I added 5 documents into 1 library, in a farm of 20 documents total, with only 1 user using the farm - in this case I would have expected faster performance.  Enforcing DLP policies is often time sensitive and waiting 24 hours can mean in some situations that sensitive information is already exposed.

            As well, one of the tests I was running in my farm was if the DLP policies get enforced on list items.  Even after waiting over 24 hours, we can see that the DLP policies are not applied to the list items in this list containing sensitive information (credit card numbers) even after waiting 5+ days and ensuring that full crawls are successfully run and all associated timer jobs are also successfully run:


            Presentation and Recording

            The presentation slide deck can be found here:



            The recording to last Thursday's webinar can be found here:


            Final Thoughts

            Data loss prevention is just 1 critical part of securing our sensitive data.  This includes identifying sensitive data, monitoring its usage and enforcing polices which control its usual and disclosure.

            • The fact that SharePoint 2016's DLP uses the search index is both a blessing and can cause issues - traditional SharePoint DLP systems have had challenges accessing and scanning content from outside of SharePoint and using the search index allows the DLP capability to operate as quickly and efficiently as possible.
            • If something is not in the search index, it will not be found by your DLP policies.  So, the freshness of your search index and the health of your search crawls will affect how effectively your DLP policies are applied.


            The DLP capability within SharePoint 2016 is a great start!  However, I would like to see it evolve particularly in the following areas:

            • Apply DLP policies to list items, in addition to documents.  I have seen several incidents in the field where clients store sensitive information in list item metadata columns.
            • More policy templates
              • Exchange Online has 80 templates and SharePoint online has 51; SharePoint 2016 on premise has only 10.
              • Especially include health related policy templates, looking for HIPAA and medical related sensitive information.
            • Customizable sensitive data types - you can do this in many other DLP systems now.
            • Today policies are location based (which site collection it resides in) and condition based (what sensitive data types are included and the number of instances.  I would like to see event based policies included as well - like enforcing policies upon upload, upon adding an item, upon deleting an item, upon editing an item, etc.
            • More actions available for policies, like encrypt content with IRM upon download.
            • One compliance center for all site collections, including OneDrive for Business (MySites), across all web applications.  We can do this today with the eDiscovery Center in SharePoint 2016 and in SharePoint Online with OneDrive for Business in Office 365 - why can we not do this in the SharePoint 2016 Compliance Center.
            • More control over when policies are run - the ability to say "Evaluate all policies now" as opposed to running timer jobs and guessing which is the right timer job to run and getting no results when you run them all.
            • Document matching capability - allow us to specify a library of documents which are compared to documents in the system as part of a DLP policy, along with a required percentage of match for each document for a policy to fire.  This would help us prevent disclosure off executive communications, intellectual property, documents that follow a common format, etc.

            Finally, I encourage everyone to starting learning about and testing the SharePoint 2016 eDiscovery DLP queries and the Compliance Center's DLP policies.  You do need to test DLP policies in a TEST or STAGING farm (or TEST site collection if you don't have a separate farm) before deploying them to a PRODUCTION environment because they often need tweaking and you don't want to do that while Production users are trying to access data they need.  And one more time... ensure you have a healthy search index and crawl: if something isn't in the search index it will not be found by the DLP policies you put in place.

            Enjoy.
               -Antonio