We’ve seen a proliferation in cloud adoption as many organizations are hastily moving their workloads and resources to the cloud as users become more mobile and remote. IT admins are facing challenges with the migration of their data and apps, and also managing their hybrid environments. Consequently, IT teams are having to upskill in order to complete their daily administrative tasks.
In this article, we’ll explore the options for managing hybrid environments and automating tasks that involve both on-premises and cloud resources. It’s important for IT and Security Operations teams to have access to a centralized management tool accessing and managing both environments to cope with the shift to remote working.
Read more: Office 365 Global Admin Best Practices by Joshua Bines
Due to it’s modern capabilities we’ll be using Azure Automation, a cloud-based management service, for automating your processes securely and efficiently. This Azure function allows administrators to manage cloud services such as Office 365, Azure, SharePoint Online, Azure Web Apps and more. However, if you run Azure Automation Runbook against your on-premises environment, you’ll get Access Denied. Currently, the only workaround is if you expose your internal network out to the internet via APIs. In this article, we’ll also be focusing on overcoming this obstruction when managing on-premises servers using Azure Automation.
To securely run Azure Automation Runbook (PowerShell or Python2 script) against the on-premises environment, we’ll have to configure the Hybrid Runbook Worker server. This is a secure delivery mechanism of the cloud-hosted script to the local on-premises environment.
The Hybrid Worker server will be going out via port 443 on the firewall to connect to Azure Automation to run Runbooks against on-premises servers such as Active Directory, Exchange, SQL Server, etc.
To achieve our goal, these are steps we’ll be taking:
- Configuring Log Analytics workspace
- Link Azure Automation account with Log Analytics workspace
- Configuring Azure Hybrid Worker Server and Hybrid Worker Group
Configuring an Azure Log Analytics workspace
As a prerequisite, we need to set up Azure Log Analytics Workspace for the Hybrid Runbook Worker to function. A Log Analytics workspace is a unique environment for Azure Monitor Log Data, each Workspace consists of a repository, data source, and a solution that stores data there.
To set up your Log Analytics Workspace, follow the steps below:
- Login to the Azure tenant
2. In All Services search for Log Analytics workspace and click Add to create one
3. Complete all required fields and click Create
4. Make sure to note the Resource Group where you added the Log Analytics workspace
5. I named the Log Analytics workspace “Practical365Workspace“
After the Log Analytics workspace is created, let’s add the Azure Automation account.
Setting up your Azure Automation account
You can create an Azure Automation account from multiple in the Azure Tenant. In this case, we’ll create the account right from the Log Analytics workspace.
- To get started, click on the newly created workspace
2. Then, navigate to Workspace Summary and click Add
3. From the Marketplace screen, select Azure Automation
4. In the Automation screen, click Create
5. Complete all the necessary fields and click Create
Make sure you select the same Resource Group where your Log Analytics workspace is created and that the location is selected based on the mapping table. For example, If Log Analytics workspace is in East US, then Azure Automation should be in East US 2 according to the mapping table provided by Microsoft.
Link Azure Automation account with Log Analytics workspace
To link your Azure Automation account with the Log Analytics workspace, we will need to enable Inventory and Change Tracking within Azure Automation.
- Click Automation Account (in our case “Practical365Automation”)
- Configuration Management -> Inventory, from Log Analytics workspace, select the workspace which we created earlier Practical365Workspace.
- Click Enable
To check if your Azure Automation is linked to a Log Analytics workspace correctly follow steps below:
- Click on Azure Automation, in our case Practical365Automation
- Under Related Resources, click the Linked workspace
You should see your Log Analytics workspace linked. In our case, as pictured above, we can see that Practical365Workspace is linked.
Configuring Azure Hybrid Worker Server and Hybrid Worker Group
The Hybrid Runbook Worker runs the script passed from the Azure Automation Account, this plays a centric role in the delivery mechanism for your management tasks. Every Hybrid Runbook Worker server must be a part of the Hybrid Runbook Worker Group, this can contain one or more servers for redundancy.
Learn more: Office 365 Tenant Migration: How to Migrate Exchange Mailbox Permissions
In the lab environment, I have a Windows Server 2016 virtual machine (Name: Server01), which is part of the on-premises domain. I will use Server01 to install Hybrid Worker.
In next few steps, we’ll cover:
- How to configure Hybrid Worker server
- Create a Hybrid worker group
- Add server to the group
Make sure your spelling matches identically to the name of the workspace you created earlier for the following steps.
On Server01 open PowerShell window (as an Administrator) andrun the cmdlet below, ensure your server has outbound access to the internet:
Install-Script-Name New-OnPremiseHybridWorker-RequiredVersion1.0 |
Next, run PowerShell cmdlet below specifying Workspace Name:
New-OnPremiseHybridWorker.ps1 -WorkspaceName Practical365Workspace |
PowerShell will prompt to provide additional information such as:
- Resource Group Name : practical365resourcegroup
- subscriptionID: XXXXXXX (Your tenant’s subscription ID)
- Automation Account Name: Practical365Automation
- HybridGroupName : Practical365HybridGroup (type appropriate name for the Group.)
During the installation process, you’ll need to authenticate against your Azure tenant.
To check if the installation is successful, navigate to Azure tenant, open the Azure Automation Account that we created earlier, and under the Hybrid workers groups, you should see a new group called Practical365HybridGroup.
Now you’ve completed the configuration of the Hybrid worker server.
Remember that the PowerShell scripts that you’re running on Server01 from Azure Automation Account will run under your System Local Account; which means you can run management tasks directly on this server. For example, you can create a runbook to stop or start a service.
In practice, you’ll use this Hybrid Worker Server (Server01) to manage other servers. For example, you can enable or disable AD accounts on Domain controllers, provision mailboxes on Exchange server, etc. You’ll also need to set up a Run As account (domain account) in Azure Automation so that your Hybrid Worker server can manage other servers in the local network.
It’s important to note here, when you configure Run As account, it will be applied to the entire Hybrid Worker Group. Currently, there is no way to link Run As account for each Runbook in Azure Automation.
How to set up a Run As account
- Open Azure Automation account
2. Navigate to shared resources
3. Click the Credentials link on the left navigation
4. Add a credential and populate any required information. Here, I’m using my domain admin account (Domain/Account), which is not recommended for production. Using the principal of least-privilege, you can create an account that strictly has access to ONLY what you need to accomplish.
5. Go back to the Azure Automation and select the Hybrid Worker Group that we created earlier in this article.
6. Select the one associated with your on-premises environment
7. Select Hybrid Worker Group settings in the left property menu and switch Run As field to Customs. From the drop-down, select the credentials that we created earlier.
You have now finished configuring your environment and it’s ready to test. The test use case I’m using will run the PowerShell script in the cloud to disable the on-premises AD account.
You must ensure here that your Hybrid Worker server has an appropriate PowerShell module installed. In this example, I made sure that the Active Directory PowerShell module is installed on Server01.
I logged in to the Domain Controller and opened Active Directory users and computers. As you can see, I have Adam Smith’s account enabled.
Next, I’ll create a Runbook in my Azure Automation account to disable this on-premises user:
- Navigate to Azure tenant and open Azure Automation account that we created earlier
2. Click on Runbooks on the left navigation menu
3. Click Create a Runbook
4. Complete the required information, make sure you select PowerShell for the type of the Runbook
5. In the editor window, type PowerShell cmdlet then Save and Publish.
disable-ADaccount -Identity Adam.Smith |
We’re now ready to run the PowerShell cmdlet. Click on Start, under Run on, switch to Hybrid Worker, and select the one we created earlier. The PowerShell script will be queued and executed, wait until the Job-status is set to complete.
Let’s go back to the on-premises domain controller and check the Active Directory Users and Computers.
Your domain account is now disabled. As you can see, we were able successfully run a cloud-hosted PowerShell command against on-premises server without exposing it to the internet.
This use case demonstrates how we can manage an on-premises workload using scripts stored and initiated in the cloud. It opens endless opportunities to manage both on-premises and cloud from a centralized location.
Daler is an MCSE specialising in Office 365. He builds business applications using SharePoint, PowerApps, Flow and PowerBI. Daler is passionate about automating day to day business processes to save customers time and increase revenue (automateiq.rocks). Connect with Daler on LinkedIn.
Thank you for viewing the article, if you find it interesting, you can support us by buying at the link:: https://officerambo.com/shop/
No comments:
Post a Comment