SharePoint Security – Salient Factors Discussed
When talking about IT and Security, the usual focus is on the technical features of security. The technical solutions simply are a lot more fun than the processes and policies. For example, a windows laptop always comes down to Bit locker instead of discussing how you work to be secure.
SharePoint is no different, but the SharePoint industry has taken it even further. We do not even feel that SharePoint security is that much fun, or even that important maybe, the SharePoint community feels that custom solutions and architectural designs, maybe even corporate branding are a lot more fun than any aspect of Security.
It is interesting for an individual engineer the promotion of the importance of keeping your local admin groups clean and why you should not logon using the farm account, for the most experienced Certified Master same as for the SharePoint IT-Pro beginner.
This is a fact and the risk is that we will start to see downsides from this as SharePoint for real has by now, found its rightful place in most every company’s infrastructure, all over the world.
Security though is not a SharePoint agenda. All in this larger and larger SharePoint community should pay a little extra attention on Security in all that we do. Not only in the SharePoint security technical aspects that we implement because we have to, take for example Kerberos authentication. Kerberos is a great Security feature that will enhance the Security in SharePoint environments, but not many implementations have been made for the Security aspects of it, but for the simple reason that a double-hop scenario required it and thus it was implemented.
Also, many SharePoint environments out there are setup by developers, I beg your pardon developers, but your focus is often to get a working test and development platform up and running, not to make it secure and stable. Also, after a solution has been developed and tested for functionality, the job is done. The result is often something that is less than perfect in terms of Security.
Here is a list of things that we could all easily think of and do, and that would help increase SharePoint Security awareness.
- Keep the number of local server administrators down to a minimum (0).
In most SharePoint environments we can assume that a local server administrator can get access to all of the content in SharePoint. Use domain groups, add an individual’s user account only as needed and remove when he/she is done.
You’ll find a command at the end that will show you a course list of the members of the local administrators group.
- Do not disable the Loopback check on your Web servers.
This is a great Security feature in SharePoint; it will make life a little harder on a possible intruder, so why disable it. Add the URLs you need instead. Also worth mentioning, you should always avoid browsing from the server, but some features like search may depend on accessing the local server so a configuration may be the best answer. You’ll find a PowerShell script at the end how you can easily configure it to allow the URL’s you need instead of disabling it completely.
- Disable the SQL authentication and especially the SA account.
These account are completely unmanaged and unmonitored, it is a popular backdoor for any hacker. They are rarely used and when used often by legacy applications, if they are, find out why and reconfigure or put the legacy app on a separate instance or server.
- Never use Shared accounts.
I still see people defending the ‘setup account’ (shared installation and configuration user) and they state that it is given special permissions that are required later on. Operations people with a lot of people coming and going often use a ‘server monitor’ account that can be borrowed and used to get easy and fast access to the server. It is often a local account and often has a password.
There is never or very rarely a reason to keep a shared account. If you absolutely feel that you must, use a domain account and more importantly, disable it when it is not used. Also, change the password regularly.
- Keep the Windows Firewall On.
It is a sad fact that it is often disabled even in a production environment. It should be used and on in all environments, the development environment would else make an easy target for the hacker.
Configure it even during development, there are many ways to do it, PowerShell may be the simplest, check my blog blksthl.com on how to.
If you don’t do it right away, you or your customer will most likely forget to enable and configure it when you are done.
- Keep the IE ESC On – Internet Explorer Enhanced Security Configuration.
A server is not really meant for us to browse SharePoint sites or the internet, use a client machine or a separate test server if you have to. If you MUST browse from this particular SharePoint server, disable it for admins only and enable it when done.
You’ll find a PowerShell script at the end how you can easily configure it.
- Use HTTPS on Central Administration site.
Often, too often, https is used for web applications but usually not for the central administration site, it is a bit of configuring and thinking to get it working, but it is a recommended way to protect your Environment. Remember, passwords will at times be transferred in cleartext on the central admin site.
We will all try do something extra when it comes to Security in the future, do your best to leave a better more secure environment behind, take a while instructing the customer on the importance of keeping the environment secure.
- QuickBooks2016.07.01QuickBooks 2016 : How to Select the Industry Type and Accounts
- Microsoft Sharepoint2016.06.30Microsoft’s SharePoint 2016: Awesome New Features Added For It’s Users
- QuickBooks2016.06.27How To Search and Edit Customers Records In QuickBooks 2016
- Microsoft Sharepoint2016.06.22Microsoft Announces Release Of iOS App For SharePoint