By Michael Brockman
For those who may be unfamiliar with Office 365, it is Microsoft’s cloud-based collaboration and communication platform. It is offered as a software-as-a-service (SaaS) solution which means Microsoft manages all the server infrastructure, saving organizations the cost and effort of running and maintaining their own data centers and server applications. This is a very attractive prospect for organizations. So much so that Microsoft estimates 80% of Fortune 500 companies are now on the Microsoft Cloud.
However, whether a large or small organization, purchasing a subscription is only the beginning. Planning how the organization will work in the cloud is critical to successful adoption. Nowhere is this more important than with SharePoint Online (an Office 365 service). SharePoint does not come with any out-of-the-box organization of sites, lists, libraries or permissions. Developing a coherent sites and permissions model for these components is an essential task for planning to migrate division, department, and office sites to Office 365.
Microsoft SharePoint has two core capabilities: collaboration and publishing. Both are implemented as sites but with different features enabled. It’s easy to focus on the features each possess and lose sight of the fact that sites are where the key features come together. Even the choice of how sites relate to one another to form a coherent information architecture has an important bearing on an organization’s online presence.
Thinking about site architecture has evolved in parallel with changes in the SharePoint platform itself: from highly structured, hierarchical sites to a flatter arrangement of sites and loosely coupled site collections. Information used to reside in carefully planned hierarchies of sites and the boundaries of site collections presented significant technical challenges. The model of a dedicated site collection for records management has given way to in-place management. Content that used to be bound up with its presentation can now be aggregated from catalogs and distributed across multiple site collections in different presentations thanks to the cross-site publishing model. Recently, Microsoft introduced Hub sites that can be used to draw related sites together in a loosely coupled way that avoids having to bind a site to a fixed hierarchy. There was even discussion among SharePoint MVP’s at this year’s Microsoft Ignite, an annual conference for developers and IT professionals, as to whether it still makes sense to create subsites in a lot of scenarios.
One area where it still makes sense to have a well-organized structure of sites in SharePoint are office or organizational sites. Office or organizational sites are usually represented in a hierarchical fashion and may be used for several purposes such as communications, project management, document repositories that pertain to an office and, in general, any institutional knowledge. Team or collaboration sites, on the other hand, tend to be ad-hoc and revolve around projects or events that have a specific duration. Office sites often serve as repositories of official information that could endure for as long as the organization itself.
In these sites, knowing who has access to what information is very important. Most organizations that have significant investments in SharePoint have experienced the pain and chaos of unique permissions being set at almost every level and object. SharePoint’s permission model is very powerful and allows for very fine-grained control, however this translates into a maintenance burden that quickly becomes unsupportable, causing users to have little clarity as to who can access what.
Delve in Office 365 uses the Microsoft Graph to surface relevant content to users. Documents that may have been buried deep in a complex site, library, and folder structure for years can show up to the wrong users if the right permissions have not been applied. It’s for this reason that a lot of company executives have asked their system administrators to disable Delve to keep everyone from seeing sensitive documents. However, the root of the problem is the wrong permissions were applied and nobody noticed—security through obscurity. Fixing the permissions is the right approach since turning off Delve, or any technology that makes it easier for users to find content, only masks the fact that users have access to content they shouldn’t.
One way to help ensure the correct permissions get applied to content in SharePoint is to develop a consistent sites and permissions model. The model should make it evident to users which permissions will get applied when they add content to SharePoint. An effective way to do this is to set permissions by location instead of setting permissions on an object by object basis, regardless of where they reside. Users understand location much better than a set of attributes assigned to objects. If a certain site belongs to an office, team, or group, it’s much easier to understand content in the site is accessible to the members, and only the members, of that site. Accordingly, a location-based permissions model will follow a few principles: 1) only set permissions at the site level; 2) do not break inheritance (create unique permissions) on list and libraries; 3) never use item-level permissions. These are principles that, as a rule, will have their exceptions but the more you can adhere to them the clearer it will be who has access to what.
In addition, wherever possible, permissions should never be granted to individuals. In SharePoint, you can grant access to individual users or groups. Sites are created with three groups: owners (full control), members (contribute) and visitors (read-only). SharePoint uses an inheritance permission model which means, by default, permissions applied at the site level will be inherited by all lists, libraries, list items and files in the site, as well as all subsites and their contents.
To create unique permissions, permissions inherited from the parent must be broken (at any level or scope), otherwise they will cascade to all the child objects. When creating a hierarchy of sites where different users have different access in each department or office site, inheritance will also need to be broken to have unique permissions for each office. This is where the site boundary is important because users can clearly understand that if they move to a different site the audience and who has access should change. But if individual documents or lists and libraries all have different permissions, one may not suspect a document uploaded to one of these can be seen by all.
While you can add individual users to SharePoint security groups, it is best to add Active Directory (AD) security groups where possible. Since most organizations express the hierarchy of their organizational units in AD as well as SharePoint, it makes sense to bring the hierarchy of AD groups into SharePoint on a 1:1 basis to control security. Additionally, the organizational groups in AD are often created as dynamic groups based on the Office attribute so that membership in the group does not need to be managed.
Dynamic AD groups can be added to SharePoint security groups at the site level which has a couple of key benefits. If the user’s office attribute changes in AD, they will automatically get access to the new site and be removed from the old. Also, when the user leaves the company their access to content in SharePoint sites will be revoked as soon as the account is deactivated or removed. No membership in the AD groups or the SharePoint sites needs to be maintained, only the Office attribute must be updated. In SharePoint, normally, a dynamic group like this would be added to the Members group so that users get Contribute rights to all the content of the site. However, users are free to define their own groups and even permission levels and apply the same technique based on AD groups.
When migrating office sites to Office 365, it is important to develop a consistent sites and permissions models and get the business to buy into it. If it’s not clear to them or doesn’t work for their purposes, then the owners of the sites are likely to start punching holes in the security model by breaking inheritance everywhere. Any site owner or user with full control can do this which is why it is also important to monitor SharePoint sites on a periodically and make corrections. However, if you stick to a consistent model and monitor for exceptions, your content will be more secure and users will have confidence they know who has access to what.
Michael Brockman serves as MIL’s Microsoft Cloud Practice Lead. He is an architect and developer specializing in Microsoft Azure, Office 365, and SharePoint with a focus on a wide range of cloud technologies such as PaaS application services, containerized microservices, new client-side SharePoint Framework, serverless technologies, and modern, cloud-based identities.