Sitecore CD Hardening via Release Deployments

Security hardening on your CD servers is an absolute must.  It should not be an afterthought and you should address it early so that you're not trying to cram it in just before go-live.

In the days before automated deployments, CD hardening would involve manually manipulating the IIS folder level permissions on each CD server in your environments. With automated deployments, we can make this much easier!

Which Sitecore Version are We Deploying?

Take note of which version of Sitecore you are working with.  Prior to Sitecore 8.2, Update 3, you are still limited to manipulating IIS folder level permissions.  You can also handle this with configuration, but that's outside the scope of this post.  With Sitecore 8.2, Update 3 and newer, we have the option of changing the forms authentication mode in order to secure the server.

Disable Forms Authentication

The simple way to disable access to your Sitecore interface is to change the authentication mode from "Forms" to "None" in your web.config:


Easy enough to do on each of your CD servers, right?  But we want to automate that with our deployments.

Azure Devops and Web.config Tranforms

Using a web.config transform, we can target the "authentication" node and change the value to "None." 

What about local development though? 

When developing locally, you can use the "Debug" solution configuration that lets the web.config use the "Forms" setting when developing locally. This is exactly how Sitecore ships out of the box.

Use the "Release" solution configuration to set a transform on that element to change it to a token value.  Note: This assumes you are using the "Release" configuration when building your solution in Azure Devops (was VSTS). 

Why a token value instead of just setting it to "None"? 

We are utilizing (mostly) clean deploys.  When deploying, we wipe the web root and install all of Sitecore and our custom code and configuration from scratch.  Additionally, we deploy the same set of files to every server.  Different values for the tokens are controlled via variables and variable groups in Azure Devops. We expect this token value to be replaced at the time the release is generated and deployed to our different environments.

Putting it Together

So, we have a Web.Release.config file in our solution that looks like this:


In Azure Devops, we have a Variable Group for our CM servers that has the same "#{AuthenticationMode}" token with a value of "Forms":

Additionally, in Azure Devops, we have another Variable Group for our CD servers that has the "#{AuthenticationMode}" token with a value of "None":

When the release is built, use the Replace Tokens task in your release definition to process all your config files and replace the tokens with values from your Azure Deveops Variables Library.

Summary

Security hardening is an important task that shouldn't be overlooked and shouldn't be pushed to the end of your development cycle.  Consider security early and keep yourself and your clients out of the news.

Additional Reading

Sitecore - Deny anonymous users access to a folder

Sitecore - Restrict access to the client

Visual Studio Marketplace - Replace Tokens Task

Help! No one can log in!

Oh snap.  It's Friday afternoon at the end of a long week and you get a desperate email from the client indicating that none of the logins for the Sitecore CM server work any longer.  Guess I'll put down the beer from the office kegerator and go look at things. :/

First up: Confirm the CD servers are still running/displaying the site.  Check.

Next: Is the CM server up?  Check; I can see the Sitecore login screen.

Next: Attempt to log into the CM with my admin account: Hmm, not able to log in.

Next: RDP into the CM server to see what's going on.  Able to RDP fine.

Next: Look at the logs.  Come across something interesting/scary:

Err, that doesn't look good.  Someone logged into Sitecore using an admin account and managed to delete the Sitecore domain.  You know, the one that *all* the logins are associated with. . .   So now, no one can log in.

Fortunately, the users themselves are not deleted when a domain is deleted. (https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/security_and_administration/users_roles_and_domains/create_and_edit_a_security_domain#_Delete_a_domain)

Before we get into how to solve this, let's talk about a couple of security issues here.

One: It looks like users that clearly don't know what they are doing have access to an admin account where they can do very bad things.  I think it should be a extremely rare exception where a content author needs this level of access.  It takes longer to properly configure security so that content authors can do everything they need to do but don't have access to portions of Sitecore that they don't need, but that's how it should be done.  Sometimes you can't avoid this and have to create some admin accounts for users, but as the logs show us, we don't even know where to point the finger since a 'generic' admin account was used.

Two: DO NOT GIVE CREDENTIALS TO GENERIC ADMIN ACCOUNTS!  If a user 'needs' admin access, make the account tied to that user an admin.  This would at least let us see who made the boo-boo.

Okay, let's solve this.

Restoring last night's database backup could be an option.  (Checks with Devops)  "Oh, the database backup process isn't running properly and we have no backups?  Super."  Side note: Well, at least we found that out now and can fix that.

Somehow hacking in to the database to restore whatever was deleted could be an option.  Hmm, I'm not sure I even want to go there.

Recall that there is a "Domains.config" file in the "App_Config\Security" folder and that the error specifically mentioned modifying it, there might be something there. . . .

After comparing the modified file to a stock Sitecore Domains.config file, it was easy to see that the only thing missing was the line that declared the "sitecore" domain:

I added that line back in and poof!: Everyone can log in again.  A much easier solve than I would have thought for something that appeared to be very scary.

Next step: IMMEDIATELY change the generic admin account credentials and let the users know that they can log in again.

Now, back to that beer. . .

TL;DR: Put the "sitecore" domain declaration back into the "Domains.config" file, drink beer.

Setting Sitecore SQL Server Database Permissions

I recently started on a Sitecore 8.2 project and was setting the SQL Server permissions for the SQL user that I had created for Sitecore to use.  The idea here is to provide least-permissions to the user so that it has enough access to work, but not so much access that it is able to do things that it should not be able to. I feel like I spent way too much time looking for the permissions that should be set.  I eventually found what I was looking for in the installation guide for Sitecore! (#rtfm)

In an effort to make sure this information is accessible (read: so that I find it when I forget next time), I've duplicated the content here.

For the "Master", "Web", "Sessions" and "Analytics" databases, select the following permissions:

• db_datareader
• db_datawriter
• public 

For the Core database, select the following permissions:

• db_datareader
• db_datawriter
• public
• aspnet_Membership_BasicAccess
• aspnet_Membership_FullAccess
• aspnet_Membership_ReportingAccess
• aspnet_Profile_BasicAccess
• aspnet_Profile_FullAccess
• aspnet_Profile_ReportingAccess
• aspnet_Roles_BasicAccess
• aspnet_Roles_FullAccess
• aspnet_Roles_ReportingAccess

For all databases:

In addition to assigning the proper roles to your user for the Sitecore databases, you also want to allow the user to execute stored procedures.  For each database, open the "Properties" window, select "Permissions", select your user and select the "Grant" checkbox for the "Execute" permission.

This is all from the 8.2 Update 2 installation guide, which I can't seem to link to due to authentication requirements on http://dev.sitecore.net, but I think the permissions are the same for previous versions of Sitecore as well.