Sunday, 20 May 2018

SharePoint Permissions Part 3 - Setting up Dynamic Security Group Membership

Photo by Henry Be on Unsplash

In part 1 we looked at how permissions inherit and cascade, and using SharePoint groups to avoid inheritance problems.  In part 2 we covered using mail-enabled security groups in O365 to make your permissions more consistent.  Now it's time to look at reducing your maintenance burden by using dynamic security group membership.

This sounds quite complicated, but in reality it simply means letting Azure Active Directory (AAD) handle group membership based on attributes like department or role.

If you set this up then when people join, move, or leave they will automatically be added to or removed from security groups.  If you're using security groups in SharePoint, this will lower your maintenance burden considerably.  It also allows you to set up a permissions strategy that doesn't require everyone who deals with user accounts to know the ins and outs of what permissions any given user requires. Dynamic security group membership is a "set it and forget it" system where AAD will handle putting people in whichever security groups are appropriate based on their user profile attributes.

This doesn't mean it doesn't need management, as you'll need to add the dynamic membership requirements to new groups, and change the requirements for existing groups if/when your organisation's structure changes.  But, after you've set it up for the existing groups, that's all you'll have to do in the future.

Here's how to add dynamic membership to a group.
  1. Open AAD and find your security group:

    (If you've not done this before, open the O365 Admin portal, select Azure Active Directory in the left hand launch panel, and there is a "Find a group" option in the default dashboard view.)

  2. Click on the group to select it.  The menu on the left hand side will display the options for that specific group. Click Properties:

  3. The Membership type of your group will be displayed:

  4. Change the Membership type from "Assigned" to "Dynamic User".  A confirmation dialogue will pop up; click Yes on this:

    WARNING: Doing this will remove existing users from your group.

  5. Click the new Add dynamic query option that has appeared at the bottom of the Properties panel, and create your rule from the dropdowns:

  6. Click Add query at the bottom of the panel to add the query to your group.  AAD will then populate the group membership with all users who match your query.
If you want to add more than one query (e.g. department = Sales AND Location = New York) then instead of adding the query through the dropdowns you'll need to click on the Advanced rule tab.  This provides a code window for you to enter a more complicated query.  

Microsoft have provided a thorough overview of the syntax and valid terms for advanced queries which I encourage you to work through.  It might appear intimidating initially (especially if you're not used to command line or PowerShell scripting) but it's really quite simple once you understand the logic.  Being able to write multi-part queries will significantly increase your options for dynamic membership, especially if you have situations where some, but not all, members of a team need to be in a group.

Once you've added the appropriate membership rule to a group, you've finished.  Your group now has a dynamic membership that will change automatically based on user attributes.

Between SharePoint groups, security groups, and dynamic group membership, you've got all the tools you need to make sure that the right users have the right access to the right SharePoint areas, all done automatically based on their user attributes.  However, knowing how to do this is just the technical side of permissions.  You also need to understand who should have access to what, and why.  This is the function of a permissions strategy, which we'll look at next.

Saturday, 12 May 2018

SharePoint Permissions Part 2 - Using Security Groups

Photo by Alex Block on Unsplash

In Part 1 of this series we looked at user groups in SharePoint sites, and how they allow you to add member permissions without breaking inheritance. Now we're going to take this a step further and look at adding groups of users, rather than individual members.

Firstly, why would you want to give permissions to a group of users, rather than individuals?  There are a number of reasons:

  1. It cuts down on your work by allowing you to add/amend permissions for multiple users at once.
  2. You can provide role-based security, which means giving permissions to users based on their role, by using 1 group for each role.
  3. Your permissions will be more consistent, as everyone in a group will have exactly the same permissions.
  4. A group can be given permission to more than one site, which means adding a new user is as simple as adding them to a group, which then gives them permissions to multiple sites.
  5. Security groups can also be used to give users access to shared mailboxes, and Yammer and O365 groups, have specific permissions for documents labelled through Azure Information Protection, and various other elements of the O365 family.
A simple example is having an Administrators group, which your SharePoint administrators are a member of.  If you add this group to the Owners group in your site template, then every time an admin creates a new site using that template, all of the administrators will be in the Owners group for the new site. (I'll cover creating and deploying a site template in a future article).

How do you practically create one of these groups?  O365 allows admins to create security groups, and these security groups can then be added to SharePoint sites as if they were users.  Security groups are created in the O365 Admin portal and contain whichever users you choose.  They can then be given permissions to a SharePoint site collection (or site, list, library, folder or document).  So if you create a security group called Administrators, you can then select this security group when adding a user to the Owners group in your SharePoint site.

When you create a security group in O365, you have an option of selecting either "security group" or "mail-enabled security group".  There is no difference between these, except that you can send email to a mail-enabled security group and it will be sent to the members, which you can't do with a security group.  I haven't yet come across a SharePoint permissions use case where this has made a functional difference, unless you want to be able to send a mail to the group when you change their permissions.  But I still recommend mail-enabled security groups, because it future-proofs your implementation in case you hit a use case where you do need to mail the group.

Make sure that when you create your mail-enabled security group you turn OFF the "Allow people outside of my organization to send email to this Mail-Enabled security group" setting.  This setting is on by default for mail-enabled security groups, distribution lists, and O365 groups, presumably because Microsoft feel the majority of use cases call for this functionality.  There are pros and cons of this for distribution lists and O365 groups, but why would you want people outside your organisation to a) know your security group names (which could be useful information for someone trying to breach your security), and b) send that security group an email? Unless you've got a good answer to these 2 questions, turn this option off.

At the time of writing the O365 Admin portal doesn't distinguish between different types of group very well.  So when you're looking in the Groups option there is no way to tell if "Administrators" is a security group, a mail-enabled security group, or just a plain old O365 group, unless you set the right filter.  This doesn't seem like a big deal, but when you spend a lot of time working with groups, and your users create lots of O365 groups for collaborating, it gets rather frustrating looking through the Groups list and not knowing what type most of them are.  There's also no way to tell what a security group is used for unless you open it and look at the description, which you and your colleagues probably aren't as fastidious about filling in as you should be (I'm not judging, I forget to do it just as often as the next admin).  

To combat this problem you should use naming conventions for your security groups.  Something like "SG-[role name]" will work fine, assuming you're doing role-based security.  You can also/instead incorporate a team name, a function name, or whatever works for you.  But do this up front, and get your admins to stick to it as much as possible.  It'll make your work a lot easier over the years, especially if you have a lot of joiners/leavers/movers, or you regularly have to create new sites.  There's also - currently - no way to tell where a security group is used unless you're willing to use PowerShell, so good naming conventions and descriptions will help you keep track of your security groups.

Now that you're using security groups to add users to SharePoint groups, the next step is to look at reducing your maintenance overhead by introducing dynamic group membership.  We'll look at this in the next article.

Monday, 7 May 2018

SharePoint Permissions Part 1 - Understanding Inheritance and Cascading

Photo by Jon Moore on Unsplash

SharePoint permissions are a common source of confusion and frustration.  This isn't because adding permissions for a new user is particularly difficult for an admin (although I'll cover one way to do that below), and nor is it because sharing a document with someone is particularly difficult for a user (although I'll cover that in a future article).  It's because it's very common to find yourself in a situation where you've given the correct permissions to a user, but they still can't see what you expect them to see.

Fear not though, because once you understand how permissions work you'll be able to fix your problems and prevent them happening in the future.  (Note: we'll be going through permissions for team sites - sites with lists and libraries - not Communications sites or the recently introduced Hub sites.  That's for a different time.)

To understand how SharePoint permissions work, you need to understand the hierarchy of objects, as well as inheritance and cascading.  

The hierarchy of objects in SharePoint is the equivalent of a family tree.  You have a node at the top (the parents), with nodes underneath (the children), nodes underneath them (the grandchildren), and so on. In SharePoint the hierarchy is:

The permissions for each of these nodes are inherited from the node above (the parent).  The Document node inherits permissions from the Folder node, which inherits from the Library node, and so on up to the Site Collection node. (If you're not using Folders then the Document node will inherit from the Library node.)

The converse of inheritance is cascading, that is, the permissions cascade down from the node above to the node below.  When you give a user permission to view a site, that permission cascades down to the library, then cascades down to the folder, then down to the individual documents.

Ok, so far so good: You create a site collection, give permission to people to view it, and they'll be able to view every site, list, library, folder and document underneath that site collection.

But that is the simplest possible option, and assumes a) that you don't need to give specific permissions to any particular object, b) that you won't give anyone else permissions to a specific object in the future and c) that no user will share a folder or document with anyone.  If any of those things happen then you'll find that the permissions aren't doing what you expected.

The reason for this is quite simple, and is at the heart of understanding SharePoint permissions: Giving unique permissions to an object breaks the inheritance.  

This means that if you, for example, give permissions to a user to see a specific library, the inheritance is broken.  So when you change the permissions in the site or the site collection, those changes won't cascade down to the library that has unique permissions.  Let's work through an example.

You create a site collection with yourself as Primary Site Collection Administrator.  Your site collection has one site, and 3 libraries called TestLib1, TestLib2, and TestLib3.  Each library has a folder called TestFolder1, TestFolder2, and TestFolder3 respectively, and each folder has a document called TestDoc1, TestDoc2 and TestDoc3 respectively.  Diagrammatically:

You give Alice and Bob edit permissions at the site level.  This cascades down to the nodes below, shown here as green nodes:

Alice and Bob have edit permissions to all of the green nodes.  If they - or you - add additional libraries, folders or documents then all 3 of you will be able to see the new objects, because the permissions will cascade down to those objects from the site.  

Now you decide to allow Charlotte to have access, but only to TestLib3.  This permission cascades down to the folder and document.  Charlotte's permissions are shown here as orange nodes:

Now Alice, Bob and Charlotte can all see TestLib3 and the folder and document underneath it, but only Alice and Bob can see TestLib1 and TestLib2.  

Now you give permission to Dave to the whole site - in other words, you want him to have the same access as Alice and Bob.  So you give him permission to see the site, and.....he can only see TestLib1 and TestLib2, and the folders and documents contained within them, shown in red below:


Because by giving TestLib3 unique permissions - for Charlotte - you broke the inheritance, so permission changes at the site level will not cascade down to TestLib3.

Now imagine that Dave shared TestFolder1 with someone else in the organisation.  You give Ellie permission to the site, and her permissions are shown in purple:

Because Dave shared a folder (a very common action for users to perform), the inheritance for that folder is broken, and permission to it (and the document it contains) no longer cascades down.

To make matters more confusing, the inheritance that is working means that if Dave adds TestFolder1a to TestLib1, Ellie will be able to see it, because TestFolder1a will inherit permissions from its parent, TestLib1:

The situation now is that:

  • Alice and Bob can see the site, all 3 TestLibs and the folders and documents contained in them.
  • Charlotte can only see TestLib3 and the folder and document within it.
  • Dave can only see TestLib1 and TestLib2, and the folders and documents within them.
  • Ellie can see TestLib2, along with the folder and document in it, as well as TestLib1 and TestFolder1a, but not TestFolder1 and the document in it. 

Oh, and if you remove Alice's permissions by mistake, then give her those exact same permissions back....she'll have the same permissions as Ellie, because of all the breaks in inheritance.

It should be easy to see how complicated this can get.  At this stage you're already in a mess, and if you have an organisation with hundreds of users and a few sites, it's almost impossible not to get in this mess.  

However, there is a simple solution to stop this mess happening: Groups

If you give access to a group, then you can add and remove users from that group without breaking inheritance because the group always has permissions.  

To take a simple example, you might create a group that has Admin rights to the site and a group that has Edit rights to the site.  These permissions will cascade, and all lists, libraries, folders and documents will inherit those rights.  

In the example shown in the diagrams, you would be in the Admin group and Alice and Bob would be in the Edit group.  If you give Charlotte edit rights to just TestLib3, and then add Dave to the Edit group, he will now have access to all 3 libraries because he is a member of a group that already has access to them.  After Dave shares TestFolder 1, you add Ellie to the Edit group, and again she has access to all 3 libraries and all of the folders and documents in them because she is a member of a group that already has access to them.  

But if you then gave Frank edit permissions to the site as an individual, rather than adding him to the Edit group, he wouldn't be able to see TestLib3 (because you broke the inheritance when you gave Charlotte edit rights to it), nor would he be able to see TestFolder1 or the document in it (because Dave broke the inheritance when he shared TestFolder1).

So groups allow you to maintain your intended permissions no matter which user you add to them or in what order the users are added.  To add a group, go to Site Settings > Site Permissions and click Create Group in the ribbon.  However, you'll find that there are already a number of default groups there, as per this list from Microsoft, and you may find the the ones you want are already there.  You can delete any you don't need, or create any that you do.

It's common to just use the Owners, Members and Visitors groups, with Full Control, Edit and Read rights respectively.  This is something that Microsoft suggests, but it's by no means required.  Set up whatever groups you need!  If you want to know more about each of the default groups and what permissions they provide, there is a full list here, under the Default Permission Levels dropdown.

Next time we'll talk about using security groups to make your security both more robust and more manageable.

Saturday, 28 April 2018

Something-As-A-Service in the Cloud

Source: Pexels

I'm going to be writing quite a bit about Azure, Office 365 and SharePoint over the next few months.  The initialisms IAAS, PAAS and SAAS will come up from time to time, so it would be helpful to explain these terms in advance:

  • IAAS - Infrastructure As A Service
  • PAAS - Platform As A Service
  • SAAS - Software As A Service

Before we talk about the Infrastructure, Platform, and Software parts, let's talk about the as-a-service part.  What does this mean?

To understand as-a-service, you need to know what cloud computing is.  This has been a buzzword for a good few years now, and it's the backbone of as-a-service.  Wikipedia provides a good definition

"Cloud computing is an information technology paradigm that enables ubiquitous access to shared pools of configurable system resources and higher-level services that can be rapidly provisioned with minimal management effort, often over the Internet. Cloud computing relies on sharing of resources to achieve coherence and economies of scale, similar to a public utility."

In less technical terms, cloud computing providers have huge racks of servers loaded with useful tools like databases, storage, load-balancers, web servers, and software.  They then lease space on these servers to remote users, along with access to the (usually pre-configured) tools.  This is referred to as AAS, or As A Service.  It's important to understand that cloud computing is a service provision model, not a generic term to refer to remote computers, which it's often misunderstood to mean.  Cloud computing is what's used to deliver AAS.

AAS is in contrast to "on-premise" where the servers, databases, storage, etc are all physically located within a company.  It's much cheaper to lease space on a server with access to the tools you need than it is to buy, configure and mantain all the servers and tools yourself, especially if you only need access for a short or ill-defined period of time.  Think of AAS as the digital equivalent of hiring a van - they buy the van, service it, clean it and repair it, and different people hire the van as and when they need it, then return it.  The van leasing company has the costs but makes a profit once the hiring fees have covered those costs, and you get the van you need for a relatively small outlay without any of the hassle and cost of having to actually buy a van.     

So, cloud computing providers lease space and tools as a service, but different users want different services.  Therefore there are different service models of AAS, of which the 3 standard ones are IAAS, PAAS and SAAS.  These service models are defined by the National Institute of Standards and Technology (an agency of the American Department of Commerce) in their NIST Definition of Cloud Computing (link to PDF).  This is a surprisingly readable 7-page document which is a model of economy and information, and if you're at all interested in cloud computing or AAS then I encourage you to spend a few minutes reading it.

In short, the service models explain which parts of the tech stack the vendor is responsible for, with the obvious correlation that the customer is responsible for the other parts.  Here's a diagram showing how IAAS, PAAS and SAAS divide up the responsibilities between the vendor and the customer, with On-Premise included for comparison:

Reproduced from Kevin Remde's Technet blog
With On-Premise, you manage all of the hardware and all of the software in the tech stack.

With IAAS, the vendor manages the hardware, but you choose the operating system and everything above it.  This is typically used for things like web hosting and data centres.

With PAAS, the vendor manages everything except the application and the data.  This is commonly used by software companies as a base for developing an application.

With SAAS the vendor manages everything.  A good example of this would be GMail, where every part of the tech stack is managed by Google. 

With both IAAS and PAAS the customer can choose how many resources to use as and when they need them (this is why cloud computing is often called "computing on demand").  The billing is usually dynamic and depends on the resources that have been consumed during the billing period.  It's typical to buy IAAS/PAAS capabilities and spin up additional virtual servers as required (a virtual server is a software representation of a real server), then apply a template that provides standard O/S, Middleware and Runtime.  With IAAS the customer maintains the template and with PAAS the vendor provides one or more templates to choose from.  The customer pays for every server they use.  With SAAS you're getting access to a piece of software and usually the price is determined by the number of user licences you buy.

As an example of how this works, consider the following scenario:

  • Vendor A buys, configures and maintains networking, storage, servers and virtualisation to sell as IAAS.
  • Web hosting company B buys IAAS from vendor A, then configures several templates for O/S, Middleware and Runtime that will appeal to different customers.  They then sell this as PAAS.
  • Software development company C buys PAAS from company B, picks a template and a number of servers, then develops a piece of software on it.  
  • Finally, company C sells their software as a SAAS offering to customers around the world, running on company B's PAAS, which runs on company A's IAAS.

It's not uncommon for a vendor to offer at least 2 of the 3 service models, although normally this would be IAAS/PAAS or PAAS/SAAS.  It wouldn't make a lot of sense to offer IAAS and SAAS without PAAS, because if the vendor has the capability to offer both infrastructure and software services then they've got the capability to offer a platform service.  

That covers cloud computing and as-a-service to the level that I'll be using it over the new few months.  There might be cause to look into deployment models (also covered in the NIST Definition of Cloud Computing), in which case there'll be a separate article, but that can wait until it's needed...

Thursday, 26 April 2018

More Strings to the Bow

Over the last year I've been working on a SharePoint implementation in my day job as a contractor.  I have a few years' experience doing content management and site collection administration on a SharePoint on-premise instance from a previous role, but this is brand new, SharePoint online, evergreen SAAS where O365 and Azure are important elements.  There are a million things to learn, and a million more after that, and then you might, might know enough to say that you know what you're doing.  

All of which is very exciting and I have indeed learnt millions of things.  However, this has left me with a problem: this blog.  AgileDocumentation was always intended to be a blog that was generally about technical writing and specifically about documenting in agile environments.  Whilst I'm the Scrum Master/agile coach for the SharePoint project team, and I'm writing lots of documentation - how-tos, instructions, design docs, comms, etc - it's not an agile documentation role.  So I haven't blogged much over the last year or so because my mind was on non-agile documentation things.

But I still think of myself as a writer.  At my core, what I am, what I do, what I enjoy, is writing.  So maybe I can't write about writing as much as I used to, but I can still write about technical subjects.  And that's what I'm going to do.  

Agile Documentation will still be in its heart a blog about technical writing, and I hope to return to that subject as much as possible.  It's just that you might find it's pivoted towards the technical side of SharePoint, with some O365 and Azure thrown in, for a while at least.  Think of it as an extended series on getting an enterprise-level content management system set up.  That's documentation-related enough for me.  For now.