Smarter ideas worth writing about.

So You Have Decided to Stand-up SharePoint 2013 in Azure, Now What?

You have decided to install and configure SharePoint 2013 but don’t have the resources to do this on-premises.  You could go the SharePoint Online route but your company isn’t quite ready for that commitment.  You then land on Microsoft Azure to host the VM’s for SharePoint and procure an Azure Subscription.  Now what?

Before getting too carried away, you will want to establish a plan.  Start by asking a few basic questions: 

  • What is the intended use of this SharePoint farm?  
  • What features are needed?  
  • How will users be authenticated to the SharePoint site? 

Let’s review the ‘What is the intended use of this SharePoint farm?’ and ‘How will users be authenticated?’ questions in more detail.

The intended use somewhat dictates the answer to the authentication question.  You need to think about sizing, redundancy and authentication when talking about use. If you plan on hosting a public website for users, then you will be using anonymous access for the general public. How will the content owners access the site? What if you need a collaboration site between your company and your contractors? Now, you will need to look at some type of user accounts.  You could use ActiveDirectory accounts but would they be the same accounts as you have on-premises or would the accounts just be for the SharePoint environment?  If it is a publicwebsite you will most likely want a secondary AD for the SharePoint environment.

But what about the collaboration site and how do we do this?  There are two ways you can go about this:

Method 1:
Use your on-premises AD environment for authentication, stand up a site-to-site VPN or use express route for connecting the on premises datacenter to Azure, then configure your networking in Azure.  Now you will want to set up at least two domain controllers in Azure, joining your first one to the on-premises domain and wait for it to sync.  Once finished join the second one.  Create your AD accounts for SharePoint farm (using least privilege model), build out your SharePoint and SQL servers and then join them to the domain.  Go through the install process for SQL and SharePoint, then deploy and configure your services.

Method 2:
Stand up a pair of domain controllers in Azure to handle the SharePoint server authentication (SharePoint service accounts); these accounts will not be synced to the on-premises domain controllers.  Next you will want to create your AD accounts for SharePoint farm (using least privilege model), build out your SharePoint and SQL servers and then join them to the domain.  Go through the install process for SQL and SharePoint then deploy and configure your services.  Now you will need to setup a mechanism for the users to authenticate to SharePoint.  Yes, you could use the domain controllers to handle user authentication, but what if you do not want users to have multiple accounts?  You could use Active Directory Federated Services (ADFS).  Now you are asking, ‘Do we use the on premises AD, or do weuse Azure Active Directory Premium?’  The process is basically the same and it just depends where you want to host the ADFS servers.  

Side Note: If you are using Office 365 or any of its standalone features, then using Azure Active Directory is a no brainer, since you have the accounts in the cloudalready.

This post is intended to provide you with considerations that need to go into the authentication processes that are needed for SharePoint.  Remember, it’s best to include all stakeholders upfront (security, legal, networking, project sponsor, etc.).


SharePoint Server Farm, Microsoft Azure, by Joe Davies

Using Azure AD as an Identity Provider with ADFS for SharePoint 2013, by Steve Peschka


About The Author

Principal Consultant
Terry is a Principal Consultant in Cardinal’s Columbus Office.  He has worked 13 years within the Microsoft Technology stack as an Infrastructure Architect that specializes in SharePoint, Azure (IaaS), and Office 365.