Hosting a WordPress Site on Azure Web Apps

Standard

As I am sure you’ve been able to guess, this site WordPress is hosted on Azure using an Azure Web App with a ClearDB hosted MySQL database behind the scenes. It’s fairly straightforward to set this up, but I have found lately that I need to use both Azure Preview Portal and the current Azure Portal for best results. Here are the steps I follow:

  1. Create your MySQL database.

    I use the Azure Preview Portal for this as the integration with ClearDB is much more complete, in fact, you may not even realize it’s a different service provider in the background. I know you are supposed to be able to do this together with creating the “Scalable WordPress” app under “Web + Mobile” , but I find it often doesn’t allow you to select the Mercury (free) or Titan ($3.50/mo) pricing tiers for the database. Fill in all the blanks being sure to set the location to the same location that you want to host your WordPress app in. It’s good to create a new Resource Group here which will also be used with your Web App.

  2. Create your WordPress Web App.

    Switch over to the Azure Portal. Reason being: The preview portal doesn’t let you select the MySQL database created in step #1. In the Azure Portal, select “Web Apps” and then click the new button. You’ll be able to find “WordPress” under the “From Gallery” category.  Give it a Url. Under Database be sure to select “Use and existing MySQL database”. Select the correct “Subscription” (aka “App Service Plan”) under Webscalegroup and the correct subscription under “Subscription” (clear as mud, right?). Lastly there are a bunch of Deployment Settings to complete. These deployment keys can be generated here. As I am sure you have noticed, they cannot be directly copied into the Configure Web App screen in the Azure Portal and even if you could, some of the characters are not valid for Azure. To fix this up, Luis Cantero has published tool to help you out. It can be found at the bottom of his post on this very topic. As his instructions state: “Just paste the entire code from the WP API above and press the button”. Simply grab that result from key generator, publish it in his tool, then copy each of the individual keys to the corresponding line in the Configure Web App screen. Once you’re done, click the next button ( forward arrow), select the database you created in step one, review and accept the term, and click the check button to create your site. It will take a few minutes for the site to create, be patient and then head over to your azurewebsites.net url, run the wizard and you’re all done.

Happy Blogging!

Creating a Site-to-Site Connection between Azure and pfSense 2.0.0.3

Standard

This was a big of a tricky endeavour and obviously a topic that I I don’t typically cover on this blog.  The whole reason for the post actually directly relates back to my Moving to Office 365 post as I haven’t get succeeded in moving enough of my operations to the cloud such that I am not dependent on my main internet connection any more.

I was able to find a few resources on this topic which were helpful with my initial configuration:

How you can connect an Azure cloud to a pfSense network over IPSec – Excellent how-to article to get you started!

After repeatedly not successfully establishing a connection between the two networks and only seeing ERROR: invalid flag 0x08 in my IPsec log I concluded that something had changed after the articles were written.  After lots of digging I found couple changes which were required:

1) The first thing I found in this article which indicated that the encryption algorithm had moved to AES 265 from AES 128.  Change made, still saw the same error.

2) The second obvious thing missing from the above article is after step 12 (Create Gateway).  Along with the Create Gateway function now, you have the choice of creating a Static Routing or Dynamic Routing Gateway.  Doing a bit more research I came across this (same as issue 1) article which recommends that you create a dynamic routing gateway.  Fair enough, it sounds like it would be the easiest for me to maintain.  WRONG! Scrolling further down that article, you find the ‘Key exchange’ property, on a static routing gateway it is IKE v1, on a dynamic routing gateway it is IKE v2.  What is the significance of this you ask? I refer you to this discussion on the pfSense form.  IKEv2 is not supported by racoon which is the foundation of the pfSense IPSec implementation.  A quick removal of my current Azure gateway and creation of a static routing gateway worked beautifully!  Connection established!

 

 

Moving to Office 365

Standard

With the full GA release of Office 365 Wave “15”, I thought it was about time I started to really see what I could do with this platform.  I have been an avid SkyDrive and Outlook.com user for my personal email for sometime now, so why not see what else I can do with the cloud & Office 365 with my little experimental company.  I should also mentioned that my little company is a Microsoft registered partner and I have enrolled in the Cloud Essentials program to make this endeavour a bit more cost effective.

My objectives for this experiment:

  1. Enable Office 365 for my company and federate authentication with my on-premise Active Directory
  2. Federate my on-premise Active Directory with Azure Active Directory
  3. Leverage Windows Intune to decommission my on-premise System Center deployment

My primary reason behind federating with Azure Active Directory for is really for the challenge – just to see if I can do it.  However, secondary to that is that I am normally working remotely and of course, I would not be very happy if my my company internet connection was down and I could not log into my Office 365 account.  I am aware that I could use the Access Control Services that come with Office 365 and DirSync, but realistically my company may want to authenticate more than just Office 365 against my on-premise Active Directory.

Here is a nice video that explains how this federation works.

Here is a little diagram of my current state:

Experiment-CurrentState

And here is one of my end-state goal:

Experiment-EndState

Thank you to Buck Woody for the very nice Azure Visio shapes!

I’ll be honest – I think this plan is going to work based on what I have read, but I really don’t know fore sure.  I will continue to update this post with my full experience as I plug away at this experiment.

——————————

Update 1 (March 6, 2013 8:55 AM MT):

Currently provisioning an new Windows Server 2012 VM using Hyper-V.  I will be adding  the Active Directory role to this server and joining it to my existing domain.  This server will be used to federate with Azure Active Directory for authentication.

Office 365 account is setup and running with my domain. Just waiting to finish with Active Directory before adding user accounts.

——————————

Update 2 (March 6, 2013 10:50 AM MT):

Server 2012 deployed with Active Directory and Active Directory Federated Services running.  Server is joined to my existing domain and has been promoted to a domain controller.  ADFS has been configured and after getting myself a trial SSL certificate, I have been able to add it to my Azure Active Directory service.  This part was surprisingly easy, just ran through the wizards that came with Server 2012 and it appears to be working.  Don’t forget that ADFS has to have port 443 open on your firewall.

Next steps: Prove that my Azure AD is working / provide authentication services and figure out how to connect it to Office 365.

——————————

Update 3 (March 6, 2013 1:45 PM MT):

There seems to be a very distinct difference between the ‘Active Directory’ service you can use via https://manage.windowsazure.com and the Active Directory that is found at https://activedirectory.windowsazure.com.  As far as I can tell, they are both based on the same under-lying service – ACS – but they both seem to offer very different interfaces.

Best I can figure right now, federation was not the correct route.  I should have gone down the DirectorySync (DirSync) route from the bigging.  Now to demote my newly promoted DC and turn it into a DirSync box.  More info here.

And a good article on demoting a Server 2012 Domain Controller.

——————————

Update 4 (March 6, 2013 3:20 PM MT):

——————————

Directory Sync is up and running… and syncing all my user accounts and service accounts.  Given that this is really an experimental Active Directory, there are a lot of service accounts.  DirSync really wasn’t too bad to get going.  Just took time reading through the guides and waiting for components to install.

Next tasks: Try to filter the user accounts that are sync’d via DirSync and take another crack at SSO.

One good thing to remember: DirSync cannot be on a Domain Control or server running ADFS.

——————————

Update 5 (March 6, 2013 9:10 PM MT):

After lots of research and testing, I have determined that because I signed up for Windows Intune, I am stuck on an Office 365 Wave 14 tenant for the time being.  Service request is open with Microsoft to see if I can do anything about this.  Haven’t found a way to force an upgrade yet either.

Still working on SSO.

——————————

Update 6 (March 6, 2013 10:10 PM MT):

A very helpful post from Sean Deuby seems to be debunking my theory about using Azure Active Directory as an authentication mechanism for my Office 365 tenant:

“If you’re running Office 365 with the federated identity + directory synchronization option, you’re already running a hybrid Active Directory where your user’s on-premises AD identity is authenticated to Office 365 via federation and their accounts are provisioned or de-provisioned in your own little cloud AD via the dirsync process.”

I may need to take a closer look at using an Azure VM if I want to achieve this type of authentication distribution as highlighted in this StackOverflow post.

——————————

Update 7 (March 11, 2013 7:30 PM MT):

Well, this sure is proving to be an adventure. After 5 days, numerous emails and phone conversations, the closest I am on getting my tenant either upgraded to Wave 15 from Wave 14 or just simply getting it deleted so I can associate a new tenant with my partner account is being told to contact the partner support group.  I did attempt that today. Tried giving them a call at 6:00 PM PT – the referral I got said that their hours were until 6:30 PM PT time – no luck.

Will update again soon.

——————————

Update 8 (March 12, 2013 10:10 AM MT):

Success! If you are registering as a Microsoft Partner and did not have a Wave 15 tenant – deal with partner support.  I had to end up giving up my original onmicrosoft.com domain, but I also had nothing in my tenant so it didn’t really matter to me.  If you don’t want to give up your onmicrosoft.com domain or you have content that you don’t want to lose, you have to wait for the upgrade email.

On to doing what I started!

——————————

Update 9 (May 17, 2013 12:30 PM MT):

Well, I have managed to get a Wave 15 tenant all set up (got busy of course and this little initiative has taken a bit of a backseat).  I have spend some time researching cloud authentication strategies and I *think* password sync with Azure Active Directory is possible, but only with Windows Server 2012 Essentials.  Here is my current evidence for this.  Hopefully I have more time in the coming weeks to to dig more into this.

On the flip side, I do have DirSync running and only synchronizing a subset of my user accounts (have lots of service accounts that certainly don’t need to be in Azure AD).  That was fairly easy to set up.  Haven’t gone for SSO yet due to the high risk of auth failures if my on-prem connection is down.  Going to take another look at the VPN options from Azure VMs as well.

——————————

Key Learnings:

  • If you’re going to integrate Office 365 with your on-premise environment, start here.
  • If using Azure Connect to an on-premise DC, be sure to populate the Azure VM’s IPv6 DNS address with your on-prem machines Azure Connect IPv6 address.

Resources: