SharePoint Security Management: Lessons Learned [Recording]

Although SharePoint security management is an increasingly popular topic because of the rise of Office 365 and the cloud, it isn’t any more important than it was before. But our users are asking us more and more how to manage security in their SharePoint and Office 365.

So, I invited Antonio Maio, a SharePoint Security expert, to discuss the issue and to share his lessons learned through past projects.

Watch the Recording



SharePoint Security Management
SharePoint Security Management: Lessons Learned

Taking control of security in SharePoint, both On Premises and in Office 365, also means knowing what your users are doing, and what SharePoint objects they have access to.

One element that came up again and again throughout this webinar, was the importance of not giving everyone the “Full Control” permission. In doing so, you can easily lose control and negatively affect your overall SharePoint Performance. Liam Cleary agrees, as mentioned in his article 10 things you can do to help make SharePoint Secure

Understanding What the “Limited Access” Permission Is
SharePoint Security Management: Lessons Learned

Often confused, or maybe just misunderstood, Limited Access in SharePoint is needed for users to access the parent objects of a document they’re trying to open or edit.

So, if a user needs to edit a document within a library, but doesn't have access to anything above it, they'll receive Limited Access in the Permissions of their SharePoint site.

If you decide to cleanup Limited Access, but it's still required somewhere lower in the hierarchy, SharePoint will also remove the access granted below. It’s important to be careful when cleaning up your permissions to avoid breaking inheritance where it shouldn’t be.

The Difference Between Edit and Contribute Permissions
SharePoint Security Management: Lessons Learned

Another challenge with SharePoint Security Management is understanding which rights are automatically granted to users, and which ones need to be manually granted.

Previously, the “Members” group in a SharePoint Site would automatically receive a “Contribute” permission level. But since SharePoint 2013, they're now granted a new right called “Edit”.

This “Edit” permission level grants users a little more than before, like the power to add and customize pages. It’s important to understand the difference, but more importantly the impact it has if you’re expecting Members to have the same access they had in SharePoint 2010.

Microsoft published a thorough article on the subject for anyone wishing to learn the main differences between permission levels.

There’s so much more to be said on SharePoint Security Management, a lot of which we covered in the video posted above. We can hardly go through everything in a 1-hour discussion, so it’s important to read up on the many other possible breaches.

The Slides Used in the Presentation

Video Transcript

Benjamin: Well good morning. Good afternoon. Hi everyone and welcome to this presentation today on SharePoint Security: Lessons Learned.

Everything around what you should know, what we've done with SharePoint, and what are the things that we've learned, of course, from our past experience.

Now I don't know what it is about today but I've got to say I'm a little nervous. I'm here, joined with my colleague.

First, I'll introduce myself and my colleagues that will help you answer your questions. My name is Benjamin Niaulin. I'm a SharePoint MVP. I work here at Sharegate Migration and Management Tool. Obviously, we do some security stuff but we're definitely not going to be pitching any sort of products here today.

The focus is really going to be on SharePoint Security itself, what you can do, what you should know before you begin, or if you've already started some, watch out because there's some things that we've seen only a year later.

Just so you know, this entire session today is recorded and I have backups of these so we have multiple people recording the video, so you'll be sure to see something no matter what.

Once we begin you'll see that I will not be answering the questions myself nor will Antonio be answering questions directly. I do have some of my colleagues here at Sharegate that are going to be here to answer your questions or help you as we get started, but towards the end, once we've finished the presentation and we make sure that everything is done on time, we'll make sure to answer all of your questions afterward as well.

I'll stick around and, again, this will be recorded to it will be available for you afterwards. I'm really, really happy to be with my friend, Antonio Maio. Hi, Antonio.

Antonio: Hi Ben.

Ben: How are you?

Antonio: I'm good. How are you?

Ben: Okay. If you could just introduce yourself, who you are, where you work, where do you come from, and how, why did I choose you or why do you think you're here in this SharePoint Security session today?

Antonio: Sure thing. Thanks for having me on this discussion with you. I've been looking forward to this.

My name is Antonio Maio, as Ben said. Ben and I have been friends for some time. I'm a fellow Canadian. I'm a Senior Manager and a Senior SharePoint Architect with Protiviti. I'm also a Microsoft SharePoint MVP as Ben is. We both spend quite a bit of time in the community talking about various SharePoint products and my specialization tends to be around SharePoint Security, identity management, identity federation authentication authorization, these types of security topics.

That's why I'm here with Ben to help share some of the lessons that I've learned working with various clients on various aspects of SharePoint Security and provide as much insight as I can to our listeners today.

Ben: He's humble but I definitely wanted Antonio here today because you can see his blog and one of his colleagues at Protiviti as well, Liam Cleary, which is another fellow MVP, are both people that I really deem probably, for me, the best in SharePoint Security.

So, if you have any questions ask Antonio and Protiviti because they definitely have done quite a bit of things with security. It's really why I didn't want to do this just by myself.

Antonio: Yeah. Ben, I'm maybe going to take a second to, like you mentioned, both Liam and I work for Protiviti.

Protiviti, we're a large consulting company with about 3,000 consultants around the world. Our company specializes is business process consulting and internal audit. We also have an award winning SharePoint practice where we help our clients both big and small with all aspects of SharePoint.

Whether it's SharePoint deployments, migrations, user experience design, development, or what have you, security assessments and so on.

We’ve been working for a long time with SharePoint and we have many clients that we've helped. Particularly on the topics we're going to talk about today.

Introduction to SharePoint Security Management

Ben: Awesome. Again, thanks very, very much. Antonio, I know you're very busy. We're going to try to get started so everybody takes advantage. Again, there's no product pitch for Sharegate or anything of the sort here. It's really going to be focused on security and to be honest.

Why are we here today? Why did I, because I always tend to choose one particular topic, say, "Well you know what? Right now this is what I'm seeing and I want to talk about it through a webinar, get some experts."

Last time we talked about the trends and there has been a lot of talk on Office 365. That was really a lot of fun and then these days as we're going to, a lot of people are talking Office 365 and it's becoming a reality.

Even in hybrid scenarios I hear often either worries or scared to lose control. I'm not sure how we're going to manage security with things evolving, so I wanted to make sure we cover some of the issues we've seen.

That we cover as well some of the basics and then some tips that we can get, of course, from our past experiences. Why are we here today? This, I thought, was very, very interesting.

It says recent study by Emedia but it was February 2013 and it's still very current today. Only about one-third of organizations with 25 to 5000 users employing SharePoint have security policies covering the platform. Only one-third of these.

Even worse, just over one-fifth, or 22%, admitted that they don't have one and won't be making one. Now I won't do a poll right now but if I had to ask everyone that is attending the webinar today and everyone registered that have interest as well is do you feel like you have security policies?

How are you making sure that they're in place and that they're being respected? That's what we're talking about. Sometimes it can be something very basic and that's what we're going to see.

Another reason that we're here today and I'm going to let Antonio cover this. Antonio, we did a little cartoon so whenever you see here at the bottom left that's your cue.

Antonio: Okay. Great. My kids love that cartoon by the way. Just on your last slide for a second.

Ben: Yeah.

Antonio: It's a great statistic you have. From the ground we really do see this happen all the time with our clients. We're often called in to deal with environments that have grown pretty organically, SharePoint environments that have grown organically to contain what we would call a lot of content so thousands or tens of thousands of documents, sometimes larger than that.

We find that in a lot of cases there's no detailed or agreed upon security policies in place. This is what we see in working with our clients every day. There's nothing there to tell users or administrators how to deal with various security scenarios they might run into or who people should access to get the content or get approval to access content.

Hopefully the lessons we're going to talk about here will give people an idea of the security policies that they should be considering or should be putting in place.

Moving on to your next slide, maybe to start talking about some of the scenarios that we've seen. A lot of people know this name.

Edward Snowden is responsible probably for one of the most famous information leaks of all time right now. It's pretty well documented as well but a good portion of the information that was leaked by Snowden came from SharePoint.

Ben: Whoa.

Antonio: Yeah. He actually gained access to that information convincing SharePoint administrators to give him access to sensitive content. An example of having, I mean not having, appropriate security policies in place or not having appropriate checks and balances in place when people do ask for access to content.

Hopefully we'll see some tips to help with that a little later in the presentation. If we move on to the next slide.

Ben: I'm trying to. I'm trying. There we go.

Antonio: Oh, there we go. Okay. Another situation that we find with our clients in dealing with Sharepoint, now I've experienced this at companies that I've worked at as well, is often due to administrators not really understanding SharePoint permissions, not taking the time to understand how they work and what they mean, we find that administrators of SharePoint will often give users full control.

They'll give them full control over sites, libraries, or documents. This often happens because they, those administrators at least, know that if I give a person full control that gives them enough permissions to do their job.

What they often don't realize is that giving someone full control also gives that user complete access to all permissions related to that site or that library or that document and gives that user the power to do whatever they wish with that content, which often results in those administrators losing control over that content.

Now those users that they've given full control to, they have probably more permissions than they need to.

Ben: Yeah. I see that - Sorry to interrupt but I've seen this many, many scenarios. We've done a couple of projects recently and a large organization type engineering as specifically focused so the data was still very, very important and just to make sure that they could do the job and just lack, I think, of not just knowledge of SharePoint but lack of time or people in the SharePoint team.

It just resulted in okay I'll just give you full control so you can do whatever it is that you need but then at some point they don't even know who has access. I'll let you continue but I've seen this become pretty chaotic.

Antonio: Absolutely. It's a great point. That's very much how it's seen.

Engineering is a great example where people are busy, often don't have the time allocated to manage this type of thing within SharePoint effectively so it's kind of the least path of resistance to give someone access to do their job and then move on. No one ever goes back to edit those permissions or figure out what should someone really have.

Disappearing SharePoint Document Library

Ben: Yeah. This is one is, I've seen it a couple of times so I wanted to make sure I added there and I've been called it, and this doesn't go just from last year or a couple of months ago.

Even from the SharePoint 2003, 2007 days people would call me and literally say, "I don't know what happened. My document library is no longer there." I would say, "What happened?" It's like, "I have no idea. I didn't do anything. I just showed up today and the document library is just gone."

Of course, my instinct was always, "Okay, well let's just go see the logs and try to figure out." There must be, I would trust them and I would say, "There must be a problem with SharePoint." At some point after a couple of minutes I realize well hold on a second. I would go through the recycle bin and of course there it is. Deleted by that exact same person that shouldn't have deleted it and that is telling you didn't do anything to it.

It says deleted by and it's right there, data and time. Of course, I try not to put it back arrogantly into their face but it's always been very interesting.

It's even more troublesome for me in SharePoint 2013 and we'll talk about this in a few moments but people that shouldn't have power to delete things, and that I assumed did not have the power to delete things, have the power and accidentally deleted things like lists and libraries, like folders, like documents, and of course never realized that they actually did it even though there's a popup.

The next one is really who has access to what? This is my most popular one, I've given access in SharePoint to so many things and we've talked about it a little bit with the full control scenario just a few seconds ago with Antonio.

At some point we've given access to so many things in so many places that I'm not sure how I can manage who has access to what and we'll talk a bit about auditing and how we can figure this out but it isn't easy.

SharePoint tends to do weird things like adding limited access and then I remove it but then it breaks things that I didn't realize it broke and it becomes very, very difficult for me, at least, even as a whatever you want to say, SharePoint expert or people that have been in SharePoint for a long time.

No matter who it is, to know who has access to what. I'm not talking in your SharePoint sites. In the SharePoint site we, SharePoint does offer some level of check permission. It is relatively basic but it does offer something. I'm talking about hey, Jonathan is coming in and I need to know what he has access to right now or he's leaving the company or we need to give his access to somebody else.

These are kind of things that I need to be able to do and most of the time it feels very, very difficult. I want to make sure that we can cover that in just minutes. Oh, this one is awesome. Go ahead, Antonio.

Antonio: Yeah. This is good scenario that we see with clients where they tell us we don't put sensitive data in SharePoint. We store them in another system and we limit access to that system and when we need to share that content we password those documents and links. We put those, and we share them through email.

It's important to understand every organization has sensitive data. The people that we talk to who work with that sensitive data, they often see that keeping it where it is, is more secure than putting it in SharePoint.

I personally find that that's often because people are comfortable with where they have it today. They're comfortable with understanding the process and they believe that they understand who has access to it and who doesn't.

In some cases, their current process might be more secure, but often what I find is that when people who work with that data actually understand the permissioning and security capabilities within SharePoint and once they really consider the sum total of people in their organization that currently have access to that data and when they take into account people within the IT team, for example, who have to do backups or who have to give certain people access, when they take that total set of people into account who have access to this sensitive data they'll often find that they have much more control over the security around that data, around who has access to it, when it does reside in SharePoint. This is an important lesson that we've seen with clients.

Oh, and if you do consider password protecting office documents and emailing them to be secure, I suggest the people Google a little bit for free apps that will crack password protected office documents. There's quite a few you'll find out there that are freely available and they'll open a password protected document in just a few minutes.

Ben: Antonio, I'll be honest with you. In all honesty I'm going to go ahead and say I'm one of them. It wasn't to hack anyone. It's literally you password protect some stuff and then we just completely forgot the password.

We just did not do it properly. We didn't back up these things. We didn't use RMS or anything, which we'll talk later but and literally it's I really need this document right now and it's password protected. I don't have access to it. It's my own.

So, I would go online, find some kind of tool that's probably harmful for my computer by the way but, and then crack the password and it didn't take any time. I think roughly 30 minutes of finding it, downloading it, and opening the Excel file usually that had the information that I need. I absolutely agree with you on that sense.

Again, just to recap everyone. Right now what we're doing is we're really covering the scenarios that we've seen and then as we go on with this webinar we'll talk about some of the things that you can do, some things you literally can't do, and how we can mitigate some of these scenarios, of course.

Administrator Role in SharePoint Security

This is another favorite one and as I was sharing this presentation with some of my colleagues today just to make sure I didn't do too many French mistakes in there, a couple of my colleagues started laughing and just say yeah, I've done that and to be honest I've done that myself.

I was doing a training for a large company. They had brought me all the way to Berlin from Canada. Started doing the training and all of that. They had given me a site and I was doing some examples. This was a couple years back. I was doing some examples.

I was explaining security, ironically enough, and I just removed myself as the administrator. I no longer, I wanted to change the owners of a group but, rookie mistake, I removed myself first to add them afterwards. Of course, that didn't fly so well.

Lost access and how embarrassing is it to have to contact people and say, "You know that site you gave me that I'm an administrator of? I don't have administrative access anymore. I removed myself." This is another one that I get all the time. I don't know about you, Antonio, if you've seen it before.

Antonio: So definitely. I do see SharePoint administrators do this. I do see SharePoint experts do this. I have been guilty of this a couple of times myself. It's a really easy thing to do.

Ben: Yeah. Then SharePoint is slow and I thought better let Antonio explain some of the “why SharePoint becomes slow” because there's many factors. We're not going to talk about performance enhancement SQL Server but how your permissions can affect your speed.

Antonio: Very much so. There are certain, and we're going to talk about this in a bit more detail later in the presentation, but there are certain limitations that are important to know about when it does come to assigning permissions in SharePoint. It usually has to do with migrating permissions

Assigning SharePoint User Permissions

Antonio: Okay. This has to do typically with assigning permissions specifically to individual documents and items within SharePoint so that's typically what we call fine-grain permissions and we're going to talk a little bit more about the limitations there.

Assigning fine-grain permissions on large amounts of content, that can affect performance in SharePoint so we'll let you know what those limitations are and what to watch out for and be careful of a little later in the presentation.

Ben: Absolutely. I think it's important, no matter what kind of SharePoint. I mean these days you could be talking about OneDrive for Business, Office 365 SharePoint. I don't care how you call SharePoint. It is still running on SQL Server behind it.

Again, I don't want to get too technical here. You know how I am. It is important to understand that if each individual item in your list, in your document libraries, that literally are stored inside a database server that SharePoint has to go and query and if for each individual item there's different permissions to calculate and see if the person that is currently visiting the page has access to them, you can imagine how intensive this could be on the servers.

Of course, that delays the response. That's what we mean when your SharePoint is slow is that loading a page isn't just loading the page.

There's a lot of things happening behind it and it's very important to understand that the more you break permissions, and we'll talk about that with Antonio.

I just get excited about, I think SharePoint speed is one of the most crucial aspects that people usually skip over and say it's SharePoint, it's Microsoft and I disagree. SharePoint can be extremely fast but you need to approach this beast the right way. We'll talk about that. I don't want to get carried away here.

How do you manage? We've seen all these problems. If I asked you guys in the chat you'll have tons of other scenarios or things that you've seen that are sometimes hilarious when you think about it a couple of months after but on the spot you're probably very pissed. How do you manage all these security and all these different things whether you're in SharePoint, whether you're on Office 365, OneDrive for Business.

Later on, we'll talk about how Office 365 and OneDrive for Business just to make it easier. Just to make sure that people adopt these new things. There's groups for Office 365. There's OneDrive for Business that allows people in the organization to share files easily. How do you manage this? Especially with external users if you choose to enable it. We'll talk about all these things but how do you go about to manage all of these things? Now the presentation officially starts.

How can we get started? How do we learn from these past experiences? How do we make sure that if we're starting SharePoint it goes down the right way? First, SharePoint you got to get to know it. No matter, and maybe Antonio will agree or disagree. I'm pretty sure he'll agree. Before you start thinking about permissions and how secure is secure.

I can tell you, before we even begin that by default SharePoint is secure. It is what we do to it that makes it accessible or security breachable if that's even an English word.

You need to get to know SharePoint. If I'm talking about content type side columns and side collections and reusable workflows and you're not exactly sure what I'm talking about, it is where you need to start. You need to understand this piece that is a large platform and I understand that on Office 365 it looks like it's a lot easier.

I click, click, click and there's things very, very quickly. You still need to get some of that basics. Take SharePoint out on a date. Get to know it. That's why I chose this picture but honestly that's what it is. You need to understand the weird things that happen and what do you think, Antonio?

Antonio: I completely agree, Ben. You touched on a really good word there when you called SharePoint a platform. It is very much a platform that's designed to enable many different scenarios in a lot of different kinds of industries, enterprises, organizations.

You can configure it in many different ways. The terms you touched on are important to understand. How those features work affect how secure it is or what content is secured versus what content isn't secured. Getting to know SharePoint, what it can do and what it can't do, I think are the initial first steps like you said.

Ben: Absolutely. I've seen some people do some pretty crazy things with SharePoint. Remember that I love SharePoint. I really enjoy, it's something that I've dedicated a lot of time to but you know what? Sometimes it is not what you need and it's okay to be choosing something else sometimes. T

he more you stretch SharePoint into things that it's not supposed to be doing or it's not meant to rather, the more you have chances of doing something that cannot be properly secured or properly closed. We'll talk about some of these as well.

You need to understand, and this is part of getting to know SharePoint. You need to understand that not everything can be applied security to, can be assigned security to. The things that you can assign security to are very, very, there's only a few actually. You can assign security, and we're talking inside of SharePoint today.

We're not talking about your SQL Server and server hardening and your firewalls. We're not getting into that but inside of SharePoint.

First the things that you can apply security to and I'm skipping the web application but there is that as well. You can apply security to your sites and that means the root site of your site collection. That means your sites. That means the sites that are below the site. The sites that are below the sites that are below the sites and the more.

I have a rule. If you've gone too deep, if there's more than three levels of subsites something doesn't smell right in that architecture. I'm not saying every single time but just know that the more you create sites and subsites and subsites and subsites within the same structure, the more complex it becomes or hard it becomes to apply security to. This is one object that you can apply security to, sites. Other things are obvious- Yeah. Go ahead.

Antonio: When you're talking security here you mean specifically permissions within SharePoint.

Ben: That's right, permissions within SharePoint. Thank you. Same thing with lists and libraries. You can apply permissions, grant permissions to people, groups on different lists, on different document libraries.

Then inside of it you'll have folders, which you can apply permissions to, documents, and items. In terms of granting permissions to people, that essentially covers where you can... Antonio, am I forgetting one here?

Antonio: No. I think you've covered it all there.

Ben: Yeah. So there's not a lot of things. Right? Yeah. A lot of times people tell me can I apply permissions on my views. In a document library or a list you can apply views, I know it's a cute dog. It's not mine this time but I thought we should change it up a little bit. So, Antonio doesn't know. Sorry, Antonio. Usually I use my own dog in my presentations. I think I've overused it.

Antonio: No worries.

SharePoint Views and Security

Ben: In SharePoint, SharePoint views are a way of looking at your lists and your libraries. That means when you have different columns, different metadata. Sometimes you want to filter on one. Sometimes you want to present it in a different way. That's what we call views.

Many, many times people tell me I've created a list of customers and I've put all my customers inside the same list but I want the sales guys from Canada to only see the customers from Canada, so I created a view, but I can't seem to grant permission and you cannot put security on your SharePoint views. That's just not possible unfortunately.

There's ways to play around. I've seen some pretty funky stuff and probably Antonio as well where you create a view, you put it on a page, you secure the page on which the view is stored.

You don't give anyone access to the library by a hyperlink but that's not properly securing the information because, as we said, the only things that you can apply permissions to are these aspects, the sites, lists and libraries, folders, documents, and items in a list.

That means that no matter how you want to create a view and how you want to try and grant access to it, there's no way of saying that that person, if somebody sends them a link to a customer or a client that is in France he'll still be able to access it because he has access to that object. That you cannot do anything about.

Antonio: That's correct.

Ben: It's the same thing. This is all I get, this one I think, I don't know about you, Antonio, every single customer so far or close to has asked me well I want to give permission based on metadata.

If I'm not mistaken actually, Antonio, we talked about this before because you used to work at a security company that sold a product that did something like that. Titus?

Antonio: That's right.

Ben: Yeah. If there's a product that exists it's obviously a need and I guess I'll actually let you talk about this a little bit more.

Antonio: Sure. This is a really good point. In SharePoint when we think about permissions, you cannot assign permissions to columns or to fields inside columns. You cannot assign permissions to content types either. You can't truly secure those items.

What that means is you can't have multiple users looking at the same item or same document and some users are not able to see other parts of the metadata. Columns, for example, metadata columns in SharePoint are not a securable object.

Ben: That's right.

Antonio: We do get asked that all the time. That's a little different than what you were talking about, Ben.

There are ways to present people with a read-only view of columns. Sometimes using multiple lists. Other times you can trigger a read-only attribute on columns through the object monitor or through power shell. That's getting a little bit complex but traditionally when you think about permissions these are not securable objects.

The other thing I'll mention too that people try to use sometimes is audience targeting. Audience targeting is not a security feature.

Ben: I am so glad -

Antonio: It's a really useful feature but if you do share the url to a particular document or a list or library with somebody and you've tried to secure it through audience targeting they will still be able to get at that item.

We call that security by obscurity where you're just hiding content from somebody. You're not truly securing it. There are still ways to get at it.

The topic that you were mentioning before around securing things based on metadata, there are ways with third party tools to secure documents or items based on the metadata but you do need to look at third party tools and you have to consider how that affects your SharePoint environment, how you're going to manage those policies, and the performance that you might run into.

Ben: Absolutely. Out of the box however and honestly, I'm really glad you brought up audience targeting. I completely forgot to put in this presentation.

It is something I've seen too often. I'll go just apply audience targeting. They won't be able to see. There's a very big difference in SharePoint where if you can't see something it doesn't mean necessarily that you don't have access to it. If somebody sends you a link to the item you could still see it and there's some ways where audience targeting does not always work so it's very important that, key word, they use audience targeting.

They didn't use any terms related to permissions, rights, or anything of the sort. Going back to your point on putting your columns as read-only.

Of course, there's always ways to present information differently but at the end of the day the object itself will have all of the metadata and there's always ways for people if they really want to to see all the columns associated to the object.

The rule, and there's no exception, I know a lot of times experts or speakers will come at the end and be like remember when I said no exceptions, there is one. There is no exceptions when you're talking SharePoint. You can go buy tools that will do some funky stuff but you cannot put permissions on the columns.

Antonio: That's right.

SharePoint Permissions Inheritance

Ben: Yeah. I'll let Antonio cover this but how does permissions all work? It's actually very easy, because I've come and probably like many others, Antonio, we come from IT or we've come from fileshares and we're used to working with permissions acting very differently. I didn't always have to break inheritance so if you could just explain how the permissions system works and how breaking inheritance works and all that.

Antonio: Yeah. I'll keep it pretty high level because you can pretty deep with permissions and permission inheritance.

SharePoint very much has an inherited permission model. What that means is that when you create a new site collection you start off with one permission on the site collection that gives users access to that site collection. Actually you start off with three.

When you create a site collection SharePoint will create an owners group, a members group, and a visitors group and assign those certain types of permissions. We can talk about those separately.

If you envision a site collection, so your home site if you will, you'll have a permission or you'll have a set of permissions at that level. Then everything below it so any subsites, lists, libraries, folders, items, or documents that you create they automatically inherit that permission from that site collection level.

If someone has access to the site collection, in this case they automatically get permissions to everything below it. What you can then do is at any one of these levels you can break that inheritance.

What that means is that I actually navigate to that level. I need to have the appropriate permission. I have to have, it's called manage permissions. I have to have the manage permissions permission at that level in order to break inheritance and assign permissions to somebody else or give permissions to somebody else.

This is useful when you have a site collection with many subsites and one of those subsites has some specialized content or some particularly sensitive content. Maybe it's content that's targeted at a particular group and you need to give it some specific permissions.

You break inheritance at that subsite and you give that subsite certain permissions. You give users or groups access to that subsite. What happens there is that the people that I give access to at that subsite they automatically inherit permissions for everything below that level as well. Ben, if you can move to the next slide for a second.

Ben: Yeah.

Antonio: Here's an example where at that child sites level we've given permission to two different people.

Ben: By the way, Antonio, sorry to interrupt but if you didn't recognize that cartoon is of Liam, your colleague at Protiviti.

Antonio: That's great. I'll make sure that he sees that if you haven't. If you give a couple of users access to that child site they will then have permissions to everything below it.

What will also happen in that case, so what we've done here so far we've broken inheritance on that child sites, that subsite. We've given permission to certain users at that level and they've inherited permissions to everything below.

What then also happens is SharePoint will automatically give what's called a limited access permission to the levels above it. That happens automatically. SharePoint does that and SharePoint does that so that those users have enough permissions to navigate to the child sites.

The limited access permission allows them to see the site collection, to see the site below it, and to navigate to the child sites and do whatever they need to do within child sites or whatever they have permission to do.

Ben: Yeah.

Antonio: Limited access happens automatically. We're going to talk about it a little bit more later on but it does cause some headaches in that it's not a permission level that you can edit per se. It's not one that you can delete or clean up after.

Although SharePoint creates these automatically it does not clean them up automatically.

Ben: I wanted to just summarize. I know you talked about it but it's important to know that when we grant, so if we look at this image right here and at the top we have Benjamin and Antonio and they have access.

You can see that in fade that we have access at the site collection level. So, as he said, we have automatically access to everything below it. That's what in faded you can see that it's just inheriting from the object above it but when the breaking, what I wanted to add is that when we break inheritance and, Antonio, you have said that and I'm sorry but it copies the permission. It's really a copied version.

A lot of people break inheritance and don't realize that it's been broken and copied. They think they can break inheritance and they can start putting the people that they want not realizing that all the people that had access before still have been copied and are available.

It's important that to remove them manually and then put your new ones that will then be given limited access as Antonio mentioned.

Antonio: That's a great point because you don't always want the people who have access at the site collection and subset level to also get access to other child sites or lists or libraries. I guess the other thing that I'll mention is you can go to any one of these levels and break inheritance.

Once we've broken inheritance on the child sites here I can go to a specific list or library or specific folder or a specific document and break inheritance there and assign specific permissions there as well.

Ben: Absolutely. That brings us to the famous limited access. I know I said I would cover it. I'll give Antonio some more time I think but essentially the limited access I think he explained it very well.

It's to be able to navigate to the object so as we saw in the image before if you're going to give people access to a subsite or if you're going to cut permissions on the folder people need to be able to get to it.

You can see that as a tunnel and you have to open all the doors to get to the last door. You need to be able to open all of the doors before even if you don't have access to the rooms within.

It's important to understand that's what the limited access actually is and that while you need to have access only to this site the limited access has been added so that you can go through the site collection and the site above it and go to what you need to go.

It doesn't mean that you'll be able to see everything inside of those objects that are above it. It just means that you need to pass through. That's usually how I explain limited access.

However, there are some things you should know about the limited access. Again, Antonio will correct me if I'm wrong but when limited access is granted automatically by SharePoint a lot of the times I've seen people panic and want to remove this limited access.

In previous versions what it would do if you removed the limited access, it would leave the user in the access below it. You can see Liam here that has been given access to the child sites. That's the handsome fellow with the glasses below Antonio here. He has access here and so he was granted limited access as you can see at the site below collection level.

In previous version if I would remove the limited access above Liam would just no longer have access to the child site but we wouldn't understand why because if we looked at the permissions he was still there.

In 2013 what they've done is if somebody removes the limited access from above, an object above, but it's still needed for permission below it, SharePoint will want to also remove the permission to the object that you have granted it. That really creates quite a bit of headache so limited access is needed.

It creates a lot of chaos because when you look at your permissions and your permission list you see a lot of limited access everywhere so it's hard to see what's going on in your site but you have to be careful if you do choose to clean it up, for good reasons, because you could affect the security of your SharePoint sign-on. Antonio, correct me if I'm wrong here.

Antonio: No. It's absolutely correct. What we find is, you might have touched this but if you break inheritance on a site and you give somebody access to it, limited access permission get created above.

If you then remove that users access to the site, the limited access permissions remain behind. SharePoint doesn't clean them up. There are manual ways to clean them up afterwards. It's a little tricky. You need to go up to the level where you want to remove them and give that user read access and then delete the permissions. It can cause some havoc.

Ben: Yeah. The bottom line is be careful if you choose to clean up limited access.

Antonio: Yeah. Typically we don't but sometimes you need to for performance reasons as we talked about and we're going to touch on those limitations still.

Ben: Absolutely. Once you do choose to grant permissions to people you'll have to choose, we talked about how it works in the inheriting model. Everything inherits from the object above. When you break permissions it gets copied. Then you have to give them, what they call here in SharePoint, a permission level. For me it's really access rights.

What kind of access do you give to that object that you've decided. There are many, in fact we can even see the limited access here but it's grayed out. You can maybe not tell here. There's many different permissions levels. What I would say is understand the actual permission you're giving.

We'll talk about edit versus contribute in the next slide but there is a very big difference. There's also a difference between read, restricted read, and view only. Antonio, you have something?

Antonio: Yeah. Maybe I'll add these permission levels, these are built in to SharePoint. These are the ones that come by default. You can edit these except for two of them. The full control and limited access cannot be edited so they have a certain set of permission within them.

Ben: Yeah.

Antonio: With that said you can modify them by going to the web application level and having a web application policy that actually restricts a particular permission and by permission I mean very fine grain permissions from that web application and that will actually remove them from full control and limited access.

Normally you can't change those permission levels there. They're set.

Ben: Absolutely. Just as a note, and maybe different people have different policies but what I try to say usually is if you're going to change it, it will be for everyone as Antonio mentioned at the web application level. Otherwise try not to edit the out of the box permission levels too much.

If you really need to, if you go inside one of them, if I go inside contribute or I go inside edit that will allow me to copy this permission level and start editing another, a copy of it. I usually, this is, I've kept that philosophy from back in my exchange and my active directory and my fileshare days, is try not to modify what comes out of the box, to usually copy it and start working on that copy and give it to the groups and stuff.

I'll continue but if there's anything to add. Here I wanted to continue on the edit versus contribute. We've always known about the contribute permission level.

Permissions in SharePoint 2013

Ben: I think it's the most popular one. You're either full control with the owners group, you have contribute with the members group, or you have read with the visitors group. That's changed in SharePoint 2013.

Now when you're a member you get this new permission level, edit. Edit is not contribute. Edit is a little bit more than contribute.

That's why that example I was talking about earlier where the person calls me and says I don't understand what happened to my document library. It's gone. Contribute does not allow people to manage permissions or to delete some of these things whereas edit really gives additional. If we look at the permission level here, update and delete list items and documents whereas contribute is not the, sorry where am I?

Edit and delete list whereas the contribute is not the edit and delete list items.

Now when you're a member you have the edit permission that gives you a lot more. I find, it doesn't seem like much but be careful and be wary with that one because you’re by default giving more power that you might be expecting with the edit permission level. Antonio, anything to add on this one?

Antonio: Yeah. The point there is important. Edit gives you more capabilities. It allows you to add lists. It allows you to edit lists. Much more so than contribute allowed you to before. Contribute really allows you to work with specifically items, adding items, editing items, deleting items, maybe deleting versions as well.

Ben: Yeah.

Antonio: Edit takes you to a new level where you also get to manage lists. With either of them you still don't get to manage permissions though. You're still restricted from that.

Ben: That's right. That would be the design if I'm not mistaken.

Antonio: Yeah.

Ben: Okay. In general be careful. Right? Antonio, I'll let you lead on that one but be careful with assigning permissions everywhere.

Antonio: That's correct. When you're assigning permissions we've got some specific best practices we're just about to get in to around assigning permissions. You do need to manage it carefully.

It's one of the general issues we see with people not governing their SharePoint environments correctly. It makes it difficult to determine who has access to what content when permissions have been assigned very haphazardly everywhere.

You do need to have your process for assigning permissions or validating that people get the permissions to the content they need appropriately so down the road you're still able to manage SharePoint effectively, report on who has access to what content, and really understand where your sensitive content lies, who can access it to protect against information leaks, for example.

Ben: I think it's one of my biggest challenge on site. There are so many permissions going on everywhere. There's so many SharePoint sites. Whether you're on SharePoint on premise is Office 365 I find is a little bit even harder sometimes because there are so many different things happening.

There's video site collections as my OneDrive for Business is, there's my groups Office 365, there's my team sites. People are starting to create things so be careful when you're assigning permissions everywhere and you're letting, it goes back to the full control thing.

Make sure that you're not giving things everywhere or if you do make sure that you can manage and monitor what is happening. We'll talk about that in just a few here. Quickly, Antonio, we're not going to go over all of these aspects. If you could just manage the limitations of a SharePoint in terms of security.

Antonio: As Ben mentioned the recording is going to be available later and this deck as well I believe but referring back the diagram here that shows you where you've broken inheritance and where limited access gets created, a couple of important points here.

When you look under the covers with SharePoint, when you create a permission, when you actually break inheritance and assign unique permission, SharePoint creates what's call a security scope. The limitations around SharePoint are really around how many security scopes you can have.

The limitations here have improved greatly in this latest version. Actually in SharePoint 2012 and with Service Pack 1, one of the cumulative updates, Microsoft actually addressed some issues where the number of security scopes you could effectively have on a list or library at that level increased to around 50,000. That's kind of a threshold.

You can go above that but 50,000 is where you start to see performance issues. The way those performance issues often manifest themselves is by end users clicking on the link to a list or library and it taking longer than it normally would for that list or library to actually return content. That's one of the limitations that we talk about.

The second one, and we actually run into this much more often, is the size of the security scope. What that means is when I break inheritance and I assign a user or group to have access to a library let's say, the number of users or groups that I give access, those relate to the size of the security scope. There is a limitation there where for a particular security scope or a particular place where I've broken inheritance I have a limit of 5,000 users or groups that I can assign access to.

When I approach that number or I go past that number that's where you run into some serious performance problems with SharePoint. Those are two important limitations to understand.

There are lots of other reasons why you shouldn't get to 50,000 security scopes or permissions, unique permissions on items within a list or library. There's lots of reasons for that when it comes to governance and how do you manage those permissions but there's some great documentation published by Microsoft and there's a link to it here around the boundaries and limits for SharePoint specifically.

I encourage people to always refer to that when they're planning out a SharePoint environment of any meaningful size.

Ben: Absolutely. To continue, the lesson number one, don't give full control to everyone. I think we've covered that pretty well. I just wanted it to pop out. We'll continue here.

How is access actually given to people? It's relatively, we've been talking about breaking inheritance and giving access to people but it always comes down to giving access to groups or active directory groups. You notice something here? I did not mention individual users. You can but I'm not going to be happy if you do that.

Obviously there's always exceptions but I don't want to talk about the exceptions. I want to give you the reasons why.

SharePoint Security Management: Groups

Ben: When you give permissions, when you break it and you want to give a permission to someone you can either create a SharePoint group and grant permissions to that SharePoint group or, and we'll talk about that, you can give permissions to an active directory group.

The thing with active directory group, you have to understand that with SharePoint they consider that as a user as well that you put in a SharePoint group if you like. I'm going to go quickly because I know time goes by super quickly. Antonio told me I had too many slides but essentially you have SharePoint groups and you have active directory groups and you have individual users.

When you give permissions you have to choose who you give this access to and where you're going to put these people. If you know you can rely on active directory groups, Microsoft actually recommends using active directory groups for performance.

There has been some changes but let me explain something. If you create a SharePoint group, call it managers, and you put some individual users in there or a group and you grant access to your site to this managers group it's a SharePoint group.

If, for whatever reason, you decide to add a new manager to this SharePoint group the next time the search engine of SharePoint, now mind you there's an exception so I want to make it out first, but the next time the search engine will pass he will see that there's a membership change in this SharePoint group so he'll want to do a full crawl to recalculate the access control list, the ACLs, on all of the items because now there's a new security I.D., a SID, to look for, to calculate all of it for.

A lot of SharePoint, the search, it shows you what you have access to and what you don't have access to it doesn't show you.

Whenever you change the group membership it will start this. However, in SharePoint 2013 if you're using continuous crawl you don't have to worry about this. They made an update so you don't have to worry about that.

It is very important to understand that Microsoft has recommended to use active directory groups. That means you put people in active directory groups and you either grant them permissions directly if you can trust them 100% or you put them in SharePoint groups and then grant the permission through the SharePoint group.

The thing here is by giving, I like to use SharePoint groups and the reason why I like to use SharePoint groups and put active directory groups in there, I know it's more time consuming.

The thing is, SharePoint groups belong to SharePoint so if ever I do a database backup or if I have a disaster recovery, if I need to go somewhere else with my database, my site collection, all of the groups are the objects within SharePoint that were granted accesses.

If I leave with that site collection I don't have to worry about the permissions that were granted much. I won't see SIDs and N-1-5 like we did on the fileshares because they don't exist anymore because the SharePoint groups are going to come with me. I have a link at the bottom I encourage you to see.

These are security guidance on SharePoint groups versus active directory groups with a lot of performance benchmarks that show you the difference and the impact on your SharePoint performance when you choose active directory groups versus SharePoint groups. Antonio, quickly, do you have something to add?

Antonio: Yeah. The other thing I'll add. One of the reasons why, performance aside, search crawling aside, those are all really good points.

Another reason why AD groups are often recommended is the fact that, either AD groups or AD users are recommended, I know we prefer groups, but is that you're managing people's access to SharePoint in one place. You're managing with active directory.

For example, when someone leaves the company or someone changes departments within the company, you only have to go edit their account in one place and those groups and users have to conform to the company's password policies and identity policies. That's all managed in one place.

You don't have to remember when someone leaves their organization to disable their account in AD and then go disable their account or remove them from a group in SharePoint as well.

Ben: Absolutely.

Antonio: Active management a little simpler and centralized.

Ben: Lesson number two here today is, of course, try to always use active directory groups when possible. Ideally put them in SharePoint groups but first and foremost, and of course make sure that the active directory is healthy. That means that you're maintaining this properly of course.

Antonio: There's one organization I worked with that had 64,000 users and 60,000 AD groups. That is generally not a healthy tree.

Ben: That is a lot.

Antonio: They managed well just like users do so good point.

Ben: Absolutely. SharePoint groups and I guess understanding the settings. When you create a SharePoint group you'll have to decide who the owner is. This can be a user or preferably another SharePoint group and this is very important to know who the owner of a group is because generally we'll have to decide after who can view the membership of the group. Is it the members or is it everyone?

More importantly, and this is very, very important, who can edit the membership of the group? Some people tend to think it's the administrator of the site that's going to take care of all of this. It doesn't mean that. It depends on your group settings and who can edit the membership over here.

Of course there's some other settings in terms of membership requests.

Do you want people to be able to ask to join or to leave the group? Do you want to auto accept anyone? Do you want to send a request to which email for this group? Really take it to another level in terms.

I guess my tip here, make sure you understand all of these settings and understand that it's not the administrator necessarily that manages all of the group memberships. It is the group owner. Make sure when you create sites that you actually look through this and choose according to your policy what's going to happen.

Lesson number three, never grant permissions directly to a user. That goes from fileshare all the way through SharePoint. This is still a reality.

You don't want to give permissions or grant them directly to a person because then you can't, as Antonio said, if that person changes department, if anything changes for this person's roles and you need to just simply give the same permissions that Jonathan had to Stephanie, who's now joining Jonathan in the same role, you won't be able to figure out what that person has access to.

Generally stay away from granting permission directly to a user. That brings me to the same question I'm going to ask Antonio. Antonio, can you tell me what Benjamin has access to in all of our SharePoint?

Antonio: Ben, that's a great question. It's not easy is the answer I'll give you right now.

Ben: That's it? Well, what can I do with this?

Antonio: Silence was kind of intentional there.

Ben: All right.

Antonio: There is some auditing capabilities in SharePoint. It's available at the site collection level and only site collection administrators but that auditing capability does output some reports that gives you some idea of what you just have access to but it's mixed with a lot of other data.

Ben: Yeah.

Antonio: A lot of data that can be very difficult to decipher so it's not easy at all. You need to be able to really digest those Excel reports that come out, take out the information that's not pertinent, and try to distill it down to something that makes sense, which is not easy to do at all. That's just -

Ben: I'm not super impressed but it is a lot.

Antonio: Sorry, Ben?

Ben: I said I'm not super impressed with the audit reports to be honest as well.

Antonio: No. Exactly. What we typically recommend here is to look to third party solutions that do provide much more targeted reports that are much easier to read around who has access to content.

Ben: Yeah. If that's important to you, you probably want to check out, there's a few out there. Definitely check that out. Obviously not super awesome.

If you want to find out who has access to what that's definitely, I mean there's no solution. I want to give you a solution other than third party stuff. There's not much there. It's okay within a site collection somewhat but as soon as you want to go across that boundary, good luck basically. Okay. Yeah. That's disappointing.

Can you, Antonio, can you at least tell me all the external users that have been granted rights to my SharePoint?

External SharePoint Users and Security Threats

Antonio: This is the same, this is kind of the same issue here. External users are often managed separately from your internal SharePoint users. We often recommend, if you're going to create an external SharePoint site, let's say and exterent or maybe a public facing site, that the users you're granting access to those areas to that you do not create active directory account for them. Manage them separately in other, another SQL database or in some other identity store. That's really important to keep those separate.

You have the same difficulty of reporting on who has access to what content so again we tend to recommend a third party solution there.

Ben: Yeah. Just so you know, Office 365 has external users built in. Why I mention this is that you can decide to turn it on. If you decide to turn it on then people can be granted access through their Live IDs so people will receive and email.

That means that the people in your organization that have OneDrive for Business, in most cases that's where it starts, they're in the document library.

They'll share a folder with somebody outside of your organization because external users has been turned on. This sends an email to these users that they can click and then it asks them to log in with their Live ID or another Office 365 account. Then they'll be granted access to your own SharePoint. The problem is, and you should be aware of it, that you cannot know right now all of the external users that have been added that have access to somehow your SharePoint.

That is why I wanted to mention it here today because I am living with this trouble with a customer of mine right now and unfortunately right now we're just turning it off unless they choose to go with a third party tool, of course.

Antonio: Yeah. That's a great point. My comment around this was around an on-prem deployment of SharePoint. With Office 365 they've done what's called federating with Live ID out of the box. They've made it really simple to allow Live IDs to log in to an external area of SharePoint, which is great, but the auditing side of it is one major issue that still needs to be resolved.

SharePoint Security Management and Governance Planning

Ben: Absolutely. That comes down to you'll need governance and I'm not going to do a governance talk here. There's a ton of blog posts of my own. There's another presentation. There's a video I've done on it.

Essentially, make sure that you have some kind of policy. If you create team size does it come with a quota? Does it come with retention policies? Then what is the permission policy and who can manage permissions on that site?

Make sure you identify that properly when you do your governance plan. I just wanted to talk about it. Keep the governance plan simple. Forget those 27 page PDF files.

Again, I encourage you to check out the other presentations on governance for that. It's a very big topic. It'll take another hour or so but I like to see governance as a guideline, a help, so if you cannot deliver that without this big PDF then it's not going to be useful and just find another way. I usually use wiki pages.

I'll use just content that lives and breathes all the time that I can adjust and why I use wiki pages is so people can actually go through it. It can be a one note if you want but I need people to be able to jump to the information from their SharePoint, from the description of their list and library, so that I can help guide them through this process. I'll skip over that. Yeah?

Antonio: Both of those are great solution because they can live right within SharePoint so while people are in SharePoint and working with it, I've talked about this, people can get right to the governance plan to see what guidelines are. Maybe the one thing I'll quickly add to governance is make sure it also covers where people go or who they ask for when they need to request access to content so when they need to request permissions to content and what kind of approval does that need to go through.

Ben: Absolutely.

Antonio: That part's really making sure people only get access to content that they should have access to.

Ben: Yeah. Check out for governance information. The problem is it's often associated with a big heavy negative word. It doesn't have to be.

Keep your governance simple. It's guidelines. Put some rules, some links, this is how you do it, this is who you ask. It doesn't have to be this complicated thing all the time.

However, things have changed in SharePoint 2013 and now we have this share button and it's definitely making it, even if you have a governance plan, it's making it very difficult to enforce it because the share is so easy. It even goes against contribute.

The contribute is actually given access to add people permission when they're not supposed to so the share button has been giving me quite a bit of headaches.

The best thing that you can do to avoid problems with the share button now, which grants people access by simply typing their names or their email and quickly clicking on edit, and of course you can see who has access which is nice, but the best thing you can probably do is provide training.

We've done video training and maybe make sure it's not a pamphlet. I say this all the time. Try self-service videos. I usually use Temptasia or some tools to record a video and you could use the Office 365 video portal if you want and whatever you want, just create channels. Put their videos in there. This is how you should start using SharePoint.

Be careful with the share button because there are some things that it's not worth investing 10,000 hours of development to make sure it works right for your organization. The best thing to do sometimes is just to train these users to understand the impacts. I know it's not easy.

Don't try to do videos that are three hours long. Three-minute videos on training on how to use SharePoint. This has been very successful for me in the past. That's what also governance does. If you integrate your governance to your SharePoint using hyperlinks, using the wiki instead of a PDF that nobody will read, that could already help you. Just be mindful of the share button because it does provide some difficulty.

Lesson number four, help them understand why item level permission is bad. Antonio talked about it. It's what the big issue with item level permission, Antonio?

Antonio: There's a couple there. One that makes it really hard to keep track of who has access to what content. That's speaks to governance.

Ben: Yeah.

Antonio: It speaks to the audit who has access. The other big issue is around performance when this does get too far or too broad. When you have too many item level permissions. All that said, there are some very valid cases where item level permissions are needed. We tend to recommend that you should try to avoid them because of those issues that they could cause.

Ben: Absolutely. I know we're a little bit over time. I think we're just at about five minutes. I'll make sure I get there too quickly. This is a few points I want to make sure we go over it. In SharePoint there's a rule. You don't see what you don't have access to. If you don't have access to something SharePoint is smart enough to not show it to you. This could be in the navigation. This could be in the document library. If you don't have access to it, what's fun is you won't see it.

However, on the other side you will see everything that you have access to using the search engine. Sometimes if your permissions are not properly planned, properly executed, you may find that you will open up your world of secure items to even more people because back then fileshares, people wouldn't know where their fileshares are or how to get to them.

Now you just use the search engine and you'll see everything everywhere that you have access to. Make sure you be wary of that.

You can do some tests if you like but also be wary of the account that is used by SharePoint. This is not for Office 365 obviously. This is strictly for on premises.

Be wary of the account you use because you have to choose which user, it's a service account, will have access and which one they will use to crawl and index your SharePoint. If you give only one account that has full control everywhere and will index everything it might not be the best thing.

It's not uncommon to see different accounts being created with different permissions and they will be used to index different parts of your SharePoint environment.

The engineering department with their highly secure data and plans that no one in the world should see, this will not be indexed by the same SharePoint account that has access to everything else because if that account gets stolen then people can have access to your entire SharePoint. That is definitely not a good idea. Be very careful with that just to be safe.

Antonio: The other thing I might add there, Ben, is that the permission modeling in SharePoint, we've talked about how it's hierarchal. It's also very permissive. What I mean there is, if you have a particular list or library or site that has multiple groups accessing it, as long as you as a user are part of any one of those groups you'll get access to the content within.

Ben: Yeah.

Antonio: There's no way within SharePoint to deny a user access even if they're part of a group.

Ben: That is correct.

Antonio: There is a deny capability at the web application level that's a little bit different. Again, you're configuring the web application as a whole there but once you get down to the site collection level you do need to be careful that if you're actually trying to remove a user from having access you have to make that they're removed from all groups that have access to a particular area in SharePoint.

Ben: Absolutely. We didn't talk about this too much. When you create a SharePoint group know that it is available across your entire site collection so name them properly as well. If you create a group called approve, another person in another SharePoint site might think it is their group and add their own people into it.

Always be wary of what is going on and that goes back to understand how SharePoint works for sure. Of course, SharePoint and security goes way beyond what we saw today. One hour, as you can tell, is not even enough. We're already 10 minutes over.

For fun, guys, Google the words "all site content". Go in your browser. I'll wait. No, I won't wait but just for fun go to view all site content. Type exactly that and you'll see access to SharePoint sites that you are not technically supposed to have access. Some schools, even seen something from the government, something in, lots of.

Be wary if the anonymous access and the exposure risk. Antonio has great information on the exposure risk available that can happen with SharePoint but all these pages that if you do not lock them down, there's a feature lockdown that will allow you to really remove access to all of these admin pages.

The view all site content that many others are much more dangerous for those people that are able to work with the client object model and so on. Antonio, you want to add something to that?

Antonio: Sure. You're right. By default, with all the site templates except for the publishing portal site, you're able to get at some pages that you really shouldn't be able to when you give anonymous access to pages.

I've done this myself several times where you Google that term and you actually come up with links to SharePoint sites where this is wide open. There's a feature in SharePoint that you need to turn on called the view form pages lockdown feature.

Ben: That's it.

Antonio: All one word and you can configure that pretty easily through some STS Admin or some Powershell to lock those pages down. I highly recommend people look that up. Again, it's view form pages lockdown.

Ben: Of course, the typical things. Have you thought of the archive center? What happens when people get, when documents or files get applied to retention policies and they go to the SharePoint archive center? Do you keep the old security? Is there a new security applied?

A lot of my customers have forgot, completely ignored or forgotten to plan this ahead so when the time comes to take those files and put them in the archive center they have no way of managing the actual security on these files and they're not exactly sure what they were supposed to do. Make sure you plan ahead of this. It's a pretty simple one.

Last slide. Know about information rights, management, or the Microsoft RMS, Rights Management Service. This is the one that comes with Office 365 so you go to any document library after you've added this feature.

You can create a policy. You can add rights to the document access. You can restrict people to print. You can restrict certain things. It works with emails as well but it adds another layer of security to the documents, stop restricting after a certain day, do not allow users to upload documents that do not support, there's tons of things that can be done. That goes another way.

There's tons of other products but the Microsoft is a great one. Works on premises as well. If you want to work with that it is available with Office 365. It's a very recent add-on. On premises you have to make sure that you have an RMS server installed so it requires an extra server. You can, at the document level, provide some policies. Antonio?

Antonio: Yeah. You also need to make sure on prem, like Ben said, you need to have the Microsoft RMS or Rights Management Services server installed or connected to SharePoint.

You also need to make sure you have the right client access licenses for people to be able to access those documents. With either IRM or RMS what Microsoft SharePoint does is actually encrypts the content of a document upon download and it actually stores the rights you assign to that document within the document itself.

If you do not want people to be able to print a document you can configure that. That would get stored with the document when it's downloaded and then the actual Office application so Word, Excel, PowerPoint, other Office apps on your desktop or the Office web apps versions will enforce those rights.

Even if you take that document out of SharePoint, you email it to your home account or just somebody else, they're not going to be able to open it because it's encrypted and Word won't allow you to print it because it's enforcing that right. This is a great solution for really sensitive content depending on -

SharePoint RMS and Office 365

Ben: It really is awesome and for those of you that are on Office 365, that's another great value that you have by being on Office 365. You don't have to set up anything. You just have to say I do want the RMS. You have to first activate it and then every single document library has the list of options that you're seeing in front of my screen.

Know about it, research it, but there's no reason why you should not want to use it. It depends, of course, on your license of Office 365 but definitely something that you want to add. Of course, guys, SharePoint security we could talk about SQL Server. We could talk about everything else. Take days if you like and by all means I'll make sure that if you want to be contacted by Antonio, he has lots of information.

I'll let Antonio leave with some tips if you have some tips, Antonio, on claims, what to use, or some technical things you want to leave with. I want to ask a question to the viewers if that you can contact them, of course, afterwards and I encourage everyone to follow. Antonio, go ahead.

Antonio: Oh, sure. I just wanted to, we've covered a lot of different topics. I know we're over time. I wanted to quickly mention a couple of the more advanced topics. Claims in particular.

I encourage everyone that's concerned about security in SharePoint to investigate and spend some time understanding claims based identity in SharePoint. The reason being, claims based authentication is now the default authentication model for SharePoint so whenever you create a new web application in SharePoint, by default it's going to be claims enabled. You'll be doing claims based authentication to log into it. Classic mode authentication has been deprecated.

Microsoft's actually removed the UI to configure it although it can still be configured through Powershell. Claims based identity and authentication is a new mechanism for authentication. It is the default. It's very much the direction Microsoft is going in so it's important to understand it.

That said, you can still configure SharePoint. Just simply log in through active directory. That will happen over the claims protocol so you can still keep the deployments from getting very complex but using claims based authentication it can enable some really interesting security scenarios depending on if you need them. It can enable things like multi-factor authentication into SharePoint in a very robust way.

It was also enable authorization based on claims. As we talked about assigning permissions to users in groups you can also assign permissions to claims. For example, by a claim what we mean is when a user logs in you can create attributes about those people.

Attributes like their name or their email address and those attributes are digitally signed so SharePoint will validate the signature and you can trust them but that can be extended to some more custom attributes.

Things like somebody's security clearance. Once you do that you can enable scenarios where people can get access to content based on what their security clearance is and not simply based on their username or what group they belong to. Sometimes that's interesting and useful to your organization depending on what you're trying to implement. I wanted to leave you with a couple of tips there.

Ben: Yeah. Great point for claims because a lot of people just see it as giving permission to a user or giving permissions to a group and with claims if you really go after that you can really take it to a whole other level and give permissions to those claims that you've created.

Again, I'm not an expert on this and that's why I brought Antonio. Be sure to contact him if you have any questions. He is the expert on security whether it's on his blog or on Twitter or by email make sure it's available afterwards.

Thank you, Antonio, for coming. I really appreciate your time on this. I know you're busy so thank you everyone and I'll just leave, I'll let Antonio close in just a few seconds. I just want to make sure that first you enjoyed this session. Leave us some feedback.

We'll make sure to make it better for the next time and for those of you that are looking for security too, of course, if you want to look at Sharegate we do provide a discount that you can use this code. It's only going to be available until December 12th so that's it. Antonio, anything you want to add?

Antonio: I think that's it. I just wanted to thank you for having me on this presentation, Ben. Please do reach out.

If anyone does wish to get in touch and has any other questions afterwards I do like to follow people back and respond to people, answering questions where I can. Please do feel free to reach out to Ben or myself. Thank you again, Ben, for having me on this.

Ben: No problem. Thank you everyone. I'll stick around. I'll let Antonio go. He has another meeting. Thank you again, Antonio. I'll stick around for questions with my colleagues and I hope this has been fun. I'll hope to see you at the next one. Thank you everyone.

Antonio: Thanks everybody.

You might also like