<img height="1" width="1" src="https://www.facebook.com/tr?id=1529264867168163&amp;ev=PageView &amp;noscript=1">
blog_listing_hero_img.jpg

Security Improvements in SharePoint Online and OneDrive for Business (External Sharing and More)

 

Over the past few months, some significant improvements have been made around the external sharing functionality in Office 365. Some other very important features were introduced as well. The marketing teams at Microsoft, however, were more focused on getting the message for the new and improved OneDrive for Business (ODB) client out, so no big announcements or press focused on these sharing improvements. With that in mind, I decided to do a quick recap to put together an updated list of important improvements that everyone should at least know about.

 

Controlling External sharing on per-user level with ODB

First of all, we finally have the option to control external sharing on per-user level with OneDrive for Business. Up until recently, this was an “all or nothing” approach – while one was able to control this on the parent -My site collection (https://tenant-my.sharepoint.com/), the settings configured on this level applied to each user’s personal site collection. With the latest changes, we can now control this per ODB site collection via PowerShell:

PS C:\> Set-SPOSite https://tenant-my.sharepoint.com/personal/user_domain_com -SharingCapability Disabled

As the individual ODB site collections are still not exposed in the SharePoint Online Admin center, this can only be configured via PowerShell. Note that the inheritance from the parent SC or the tenant-wide settings still applies. The External sharing settings for individual site collections cannot be less restrictive than the settings configured on the tenant level or the -My site collection, but these settings can be more restrictive. For example, if you have disabled External sharing in one of those places, the per-user settings will not have precedence and if you try to enable any kind of External sharing you will get an error like the one below:

PS C:\> Get-SPOTenant | fl SharingCapability

SharingCapability : Disabled

PS C:\> Set-SPOSite https://tenant-my.sharepoint.com/personal/user_domain_com -SharingCapability ExternalUserAndGuestSharing

WARNING: The SharingCapability set for this SPOSite will not take effect until the 'ExternalUserAndGuestSharing' SharingCapability is also enabled on the SPOTenant.

Set-SPOSite : You can't set the sharing capability to the level you specified, because it is a less restrictive setting than either its parent site collection or your organization.

At line:1 char:1

+ Set-SPOSite https://tenant-my.sharepoint.com/personal/user_domain_com -Sharing ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : NotSpecified: (:) [Set-SPOSite], ServerException

+ FullyQualifiedErrorId : Microsoft.SharePoint.Client.ServerException,Microsoft.Online.SharePoint.PowerShell.SetSite

In effect, if you are trying to configure the “disable sharing for everyone apart from a few specific users” scenario, you need to use a different approach – leave external sharing enabled on the tenant level and disable it on the user level for everyone except those few users. This can easily be automated via PowerShell and CSOM; for example, you can use the script provided in Step 2 of this TechNet article to enumerate all the available ODB sites and then use the Set-SPOSite cmdlet accordingly.

The opposite scenario, “enable sharing for everyone apart from a few specific users,” is much easier to accomplish now. Previously, we had to resort to workarounds such as removing the Site Collection Administrators role for the user and granting him some customized permission level (and breaking his personal site as a result of that :)). Now, it’s as easy as running a simple PowerShell cmdlet. In any case, the increased control that we have over the external sharing feature for ODB is welcome!

Next, we have the “Turn off sharing for non-owners on all sites in this site collection” feature. Enabling this feature basically restricts sharing invitations to only Site Owners and Site Collection Administrators.

Controlling sharing for non-owners


enowblog.png 

To actually configure it, you can use either the GUI or PowerShell. Navigate to the SharePoint Online Admin Center and the Site collections node on the left, then select the site collection in question and press the Sharing button on the ribbon. The Sharing dialog will pop up, with a new section in the middle giving you a short description of the feature and its current status. To enable the feature (and disable sharing for non-owners), click the “Turn off sharing for non-owners on all sites in this site collection.” hyperlink (see the screenshot on the right).All other users will be only be able to share with users added to the site already (either internal or external) and are not allowed to invite new users. This is a one-way street– if you turn this feature on, there is no going back.

Alternatively you can configure the feature via PowerShell. This is done using the –DisableSharingForNonOwners parameter for the Set-SPOSiteWindows PowerShell cmdlet. 

For example:

PS C:\> Set-SpoSite –Identity <URL> –DisableSharingForNonOwners

Once the feature is configured, it’s strongly recommended that you avoid breaking inheritance of permissions in any of the sub-sites under a given root site. This ensures that the allow non-owners sharing setting is consistently applied across all (sub-)sites. Breaking inheritance is always frowned upon in the SharePoint world, but now you have another reason to avoid it. And again, a reminder that this is a one-way street, no going back is possible!


 

enowblog-1.png 

 The list of recent changes doesn’t stop here. Another set of improvements was focused on “ease of use”. This basically included a refresh of the sharing dialog and the introduction of company-wide links (that is a link that can be accessed by anyone inside the organization).

Time expiration for sharing links

Company-wide links eliminate the need to have users added in advance, while at the same time providing you peace of mind that the file cannot be shared outside of your organization. You can send this link to anyone internally who can then forward it to others as needed; however, external access is not possible.

Along with these, on the security front we got the ability to set a mandatory expiration limit on guest links. While the end users are presented with the opportunity to configure link expiration upon sharing the document (or editing the link later on), this is not mandatory and the user can choose to configure a link with no expiration. We can however configure a limit on the validity of such links via the Set-SPOTenant cmdlet and the RequireAnonymousLinksExpireInDays parameter.

For example:

PS C:\> Set-SPOTenant -RequireAnonymousLinksExpireInDays 45

This limit will apply to both existing and newly created guest links. The acceptable values are between 1 and 730 days. To remove the limit, one can use:

PS C:\> Set-SPOTenant -RequireAnonymousLinksExpireInDays $null

Configuring a limit will also make it mandatory for the users to specify an expiration for given link upon creation.

 

Immediately revoking access for a user

Another great addition is the ability to “kill” any active sessions a given user might have. Why is this important? Because disabling a user account doesn’t immediately revoke access for said user. This is a well-known issue even in the on-prem world, caused by the different types of content or token caching performed on frontend and backend servers. In the cloud, the delay between disabling a user account and actually stopping the user from accessing your data can be even longer due to dependency on dirsync and the lack of control we have on the underlying infrastructure.

In other words, if you want to immediately revoke access for a specific user, you need to follow a certain procedure. Tony Redmond has put a nice overview of the process for Exchange Online here. What about SharePoint though? Until recently, there was basically nothing we can do but wait for the sessions to expire. With the latest version of the SharePoint Online module for PowerShell (16.0.4727.0 or above), we can now use the Revoke-SPOUserSession cmdlet to immediately invalidate any sessions. To use the cmdlet, you need to login as admin via the SPO PowerShell module and simply provide the user name:

PS C:\> Revoke-SPOUserSession -User baduser@domain.com -Confirm:$false

We successfully signed out baduser@domain.com from all devices.

Simple as that. And great new addition to the service!

 

Recap of other useful features

Here’s also a short recap of other useful features introduced in the last year or so, in no particular order:

  • The option to limit ODB sync to domain-joined devices only
  • The possibility to audit external sharing invitations (controlled via the BccExternalSharingInvitations and BccExternalSharingInvitationsList parameters of Set-SPOTenant)
  • A feature to allow us to manage external sharing on a pre-domain basis is coming soon (the relevant parameters SharingAllowedDomainList, SharingBlockedDomainList and SharingDomainRestrictionMode are already available for Set-SPOTenant)
  • Several settings that help us prevent unintended sharing of documents within the company (the ShowEveryoneClaim, ShowAllUsersClaim, ShowEveryoneExceptExternalUsersClaim and the ProvisionSharedWithEveryoneFolder parameters for of Set-SPOTenant)
  • Closing the security gap which allowed sharing invitations to be forwarded to another address (now prevented by using the RequireAcceptingAccountMatchInvitedAccount parameter of Set-SPOTenant)
  • The option to restrict access to only ADAL-enabled clients via the LegacyAuthProtocolsEnabled parameter (i.e. restrict to clients that support MFA)
  • The detailed auditing we now have as part of the Compliance (Protection) center in Office 365


I’m sure I’ve missed a thing or two in the list above, but the changes are impressive. There’s still room for improvement, especially when it comes to reporting on all the shared files within the tenant or all the files a given external user has access to, etc. The situation is even worse if we consider ODB, and few Microsoft partners have already released products that can help on that part. But at the end, slowly but surely, Microsoft is going into the right direction. Personally I expect a lot more improvements in the coming months!