Managing SharePoint security groups is just as important now as it was with Active Directory and File Shares. Dare I say it’s even more important now with SharePoint Online and all the easy share options for external users.
Though SharePoint is considered to be well secured by default, it’s often our actions or bad group planning that leads to breaches.
In this article, I want to go over some of what I’ve seen with you and a recap on security groups and other objects to know how to use them to improve your SharePoint security.
My own SharePoint security breach and why it happened
Not too long ago, I ran into a little issue with my SharePoint site. After running a security report, I realized I had a breach, and external users had access to my entire Site Collection.
My SharePoint security breach could have happened to anyone and had nothing to do with the software, but rather with how we use it and the mistakes we made.
You see, in Office 365 SharePoint sites, there’s a new concept called “External Sharing”. In other words, you can grant access to someone outside of your organization to the content in your SharePoint. It’s actually very practical and though it can be turned off, I don’t necessarily recommend this course of action.
What happened was that we shared a document to two external users, but didn’t realize that someone had added the “Everyone” membership to the Members Group of the SharePoint site. This granted everyone added in our SharePoint an “Edit” access to all of our Site Collection. So by granting access to a single document to external users, we added them to the site and thus were included in “Everyone” when it was used.
Today, Office 365 SharePoint’s security includes “Everyone except External Users” to help mitigate this issue. However, it goes to show how a simple action can lead to potentially serious SharePoint security threats.
SharePoint security objects to which you can grant access
When working with SharePoint, before you start granting everyone accesses to things all over the place, it’s crucial that you understand how it works. And by that, I mean what can you grant access to. A User? A Group? What’s what in SharePoint security.
A SharePoint User means a little more than you think:
When you’re looking at granting permissions to a site or document library, you’re asked to which SharePoint user you’d like to grant this access to. The fact is, it doesn’t mean what you think it means.
First, it’s important to understand that SharePoint doesn’t come with its own list of users. It leverages, by default, Active Directory. This is the mother of all things in your organizations, it’s where all users are listed and where your account and computer are created so you can access things on the corporate network.
Often, when you’re doing something in SharePoint you’ll be using these users as reference. The People or Groups column, the security model, etc…
But when you are working with SharePoint security and it asks which user you’d like to grant this particular object to, it’ll mean a little more than your typical list of users.
For SharePoint security contexts, a user means both a user as we know it but also includes an Active Directory Group. That’s right, if you click on “Add a User” you’ll be able to pick an AD Group as a user.
Take your understanding to the next level: SharePoint security best practices from the pros
SharePoint Security Groups
The reason for this is that when we’re talking about security groups in SharePoint, it actually means its own implementation of that concept.
SharePoint security groups are SharePoint objects that have “users” (Active Directory Users and Active Directory Groups by default) as members and come with their own settings. These settings can be things like who’s the owner of the group and who can add or remove members from it.
This is extremely important to understand, because it has immense impact on your security model. In other words, you can skip SharePoint security groups and grant access directly to Active Directory Groups if you wish.
New External Users for SharePoint Online
Introduced by Office 365, there’s a new type of user to consider now and with it a whole new set of security concerns.
External Users are people outside of your organization that were granted access to your SharePoint assets by email and their Windows Live ID. They’re technically also “users”, so we should be careful when using things like “Everyone” in permissions as mentioned above.
Losing track of SharePoint security groups and their purpose
Now that you have the basic knowledge of a User and SharePoint Group, let me tell you about a story. It happened to a friend of a friend of mine… actually no… it happened to me and I am not ashamed. Well, somewhat.
Back in the SharePoint 2007 days, I didn’t fully understand the structure of a Site Collection. Today, I know that a Site Collection shares many things with its member sites and one of these things is the list of SharePoint Groups.
We started having groups like “Approvers”, “Managers”, “Collaborators” and other completely meaningless group names. Though it worked really well when we were working within our little SharePoint site with our little lists and libraries, we didn’t realize the impact it had on other sites in the collection.
Suddenly, we lost track of which group was meant for what. Or even worse, we started thinking we were using the right group to manage our SharePoint security when we clearly weren’t.
If you’re going to take ownership and responsibility of your security in SharePoint by creating and managing your groups, then make sure you implement a proper naming convention for them. This should be part of your SharePoint Governance Plan and though I haven’t covered that aspect in my blog post, it goes without saying that you shouldn’t create a heavy PDF with that information. Frankly, no one’s going to read it. Create some guidelines and make it easy to consume through a Wiki, or now, a Microsite.
Active Directory Groups vs SharePoint Security Groups
So what should you use? Ask IT or whomever is in charge of Active Directory to take care of it and use those within your SharePoint? Or take matters into your own hands and put these AD Groups and AD Users inside of SharePoint Security Groups that you manage?
There’s no right answer that fits everyone and every organization.
In the past, before SharePoint 2013 introduced some updates, I’d tell you that not using SharePoint Groups actually
impacted your overall performance quite a bit. However, this isn’t the case anymore, so we can look at the overall ease of use for both.
I’ll start with my favorite, which of course is the most complicated way to manage security in SharePoint. Use Active Directory Groups and Users and add them to SharePoint Groups that you manage.
The reason I prefer this method is that the SharePoint Groups actually belong to SharePoint and thus are stored in the Content Database. This means that with every backup and restore or in a disaster recovery scenario you’ll keep the total integrity of your security model.
However, if you strictly use Active Directory Groups only and something comes up that requires you to take the database to a new forest or domain… you’ll get a bunch of S-1-5-21-3968247570-3627839482-368725868-1110 or similar.
You may actually recognize this from your file shares, it happens when a document or folder references a user that no longer exists. It’s actually called a SID (Security Identifier) and is like a barcode so that every user or group is unique, the name that they have is more of a property to this barcode. If that user or group is deleted, then the Site or any other object that referenced it in their permissions will only see the barcode without being able to give you the name it references.
Ultimate Rule of ALL time: NEVER grant access to ANYTHING directly to an individual user.
Notice that this section of the blog is called AD Groups vs SP Groups, but never do I even consider granting access to an individual user. Just like any software in the world, we try to never do this as much as possible.
Even for a single user like the CEO, we put that person in a group called CEO because at some point this person will be replaced by someone else. Granting permissions through groups is a smart and logical thing, the question is: AD Group or SP Group?
Tips on assigning proper SharePoint security to people with higher privileges
I’ll be honest, this blog post was actually an idea that was sparked by someone’s question. They were looking at Delve for Office 365 and weren’t happy that a user from IT could see everything in the activity page.
If you’re not yet familiar with Delve, it’s essentially a personal search and discover experience to help you find content that you or others are working on, but that you have access to.
It was then mentioned that this user was a “Global Admin”, a Farm Admin equivalent for Office 365. In other words, this person had access to everything and then wasn’t happy that Delve showed everything.
There’s another golden rule when working with any type of permissions management, never grant any user higher privileges than they need.
You may be thinking that this person was in IT so it’s OK to have Global Admin power, but no. As a best practice, even IT should have their regular user account to access their Sites and work. Then have a separate account with elevated privileges when they need to use them.
And that’s the thing about security management, if it’s easy then you’re doing it wrong.
So I am curious, does your account have Admin power or do you have a separate account to do these tasks and help track and audit what’s been done by the admin account?
