Objective
In this guide we will discuss and follow the steps necessary to create a new Azure tenant and configure the necessary tools to sync your on-premises accounts stored in a local Active Directory configuration with Azure Active Directory.
Reasoning
As business evolves we are seeing more necessity to migrate applications and services to Cloud Providers such as Azure. There are a few key benefits of migrating services away from on-premises solutions to cloud platforms. A few key ideas are:
On Demand Scalability
In some cases business may need to resize services or applications quickly. In such cases using a Cloud Provider such as Azure allows us to quickly up or down scale a solution to match the needs of the business without needing to worry about physical infrastructure overhead.
Hardware Requirements (Or Lack Thereof)
If the business can afford the subscription there is no real limit to what hardware can be provisioned for a specific task or need, whatever it is. Setting up a new virtual machine or application can be done entirely through the Azure portal and with (almost) whatever hardware requirements are required. This greatly simplified the process of hardware related overhead such as physical networking, management of physical servers, and hardware failures.
Availability
Many cloud providers including Azure offer native High Availability for their apps and features. For most services Azure guarantees at least 99.9% uptime, for some services up to 99.99%. This gives us a guarantee of no more than about 9 hours of downtime a year and no more than about 1 hour of downtime a year respectively for these services. For more information check out the Azure SLA at this link:
Service Level Agreements Summary | Microsoft Azure
Security Features
Azure specifically was created with the Windows Security Stack in mind. There are many powerful security features that can ensure your data remains secure while being highly available. There are many features that simply snap in to existing Windows deployments to allow ease of deployment, management, and compliance.
Compliance Features
Azure offers specific compliance configurations to ensure that many common regulatory guidelines such as HIPAA, GDPR, and more are met. This can significantly reduce complexity and cost when a business must adhere to certain guidelines set fourth by governing bodies.
Prerequisites
We will need the following to accomplish our goals
- A Microsoft account to serve as the owner of the tenant with an active subscription [Free Tier will work]
- An on-premises AD configuration
- At least Enterprise Administrator level credentials on the local Active Directory implementation and access to the Primary Domain Controller [Internet access to Azure is also required]
- A domain purchased from a third-party registrar such as Google or GoDaddy
Getting Started – Creating a Tenant
Sign in to https://portal.azure.com
In the Azure services window, click on Azure Active Directory
Find Create a Tenant and click it
In the Create a tenant pane select Azure Active Directory as the tenant type
In the Directory details pane you will be asked for some information including your Organization name and initial domain name. I am using the domain I purchased through Google as the organization name. You will also notice as you fill out the Initial domain name it will automatically update it to domainname.onmicrosoft.com. This is expected and we can add custom domain names later assuming you own the rights to the domain.
Azure will review your information and should confirm that your Validation passed. Review the information provided and click Create. The process for creating the tenant will take a few minutes, so this is a perfect time to refresh your coffee.
You should recieve a notification that your tenant was sucesffuly created. Click the link to open up your new tenant.
Necessary Tasks, Creating Break Glass before anything else
Now that we have a new tenant we are eager to sync it up with our on-premises infrastructure, but before we do we should consider making emergency break-glass accounts that can help us regain access to our tenant in the event of an emergency. These accounts should not be used for normal tasks or configuration, and should not be linked to or synced from your On-Premises infrastructure which is why we are doing this first. The accounts should also be under your .onmicrosoft.com domain in the event of any domain or DNS related issues. Care should given to how the company will store the credentials for the account. Setting up two-factor authentication is also highly recommended as anyone with access to these accounts can own the entirety of your Azure infrastructure. It is recommended to have at least two break glass accounts with Global Administrator rights. We will go through the process of configuring the first account and the same steps can be used for any additional accounts.
In your tenants Azure Active Directory portal click Users
Click New user
In the New user pane ensure the Create user radio button is selected
In the Identity fields fill out the User name and Name fields. As we will be following proper security methods I would not recommend any security-through-obscurity type naming conventions. Keep it simple and descriptive.
In the Password pane we can accept the initial Auto-Generated password as we will be manually updating both the password and two factor authentication options shortly. Click the Show Password checkbox and write down the generated password.
In the Groups and roles pane click the User link under Roles
In the Directory roles pane search for Global Administrator and ensure it is selected, then click Select. Confirm the Roles field is updated.
In the Settings pane confirm Block sign in is set to No. Determine the usage location for the account.
There is no necessary information in the Job Info pane but I like being thorough
Review the settings you have configured and click Create
When checking Azure Active Directory Users we should now see the Break Glass Account
Setting Sign In Options for the Break Glass Account
We now need to configure a strong password and two-factor authentication settings for the Break Glass Administrator account. Open a new private window in your browser and navigate to https://portal.azure.com and sign in using your Break Glass Accounts credentials.
You will be prompted to update the password for the account. Generate and store a secure password to be used by the Break Glass Administrator. Once the password has been updated continue to sign in.
Once you are succesffuly signed in as the Break Glass Administrator open a new browser tab and navigate to the Microsoft Security Info Manager at My Sign-Ins (microsoft.com)
Select Add method
At this point you should determine the best two-factor authentication tools for your use case. You will need to add one of the following for 2FA Prompts:
- A Phone number
- An Email Address
- An Authenticator App
Multiple 2FA solutions can be configured. I will begin with using a Third-Party authenticator app as my primary 2FA option. I will also be adding my phone number as a secondary option. It is important to remember that if you lose the ability to provide two factor authentication you will lose access to the account. Having backup two-factor options is a good idea, and so is testing them regularly.
Confirm your options are available in the Security Info page
At this point it would be a good idea to sign out and test signing in to make sure your Two-Factor prompt is both required and usable. Each method should be tested and confirmed.
Follow this process for all Break Glass Administrator accounts and store the credentials securely.
Setting up your Custom Domain
We can now begin the process of linking your owned custom domain to your Azure AD Tennant.
In Azure AD, navigate to Custom domain names
We should see our existing onmicrosoft.com domain, but we would like to add our own. Click Add custom domain
In the Custom domain name window enter the domain you own that you wish to add to Azure. I will be using my ad.labgrassa.com domain for this configuration. Click Add domain
You will be presented with a challenge to add either a TXT or MX DNS record to prove your ownership of the domain.
The process for adding records will be unique to your specific Domain Registrar. In most cases you can enter these records manually through a web console provided by your registrar. Here is an example of my configuration through Google Domains:
Please note that updating DNS records and allowing replication may take time. After creating your record use a tool like Dig (Dig (DNS lookup) (googleapps.com)) to make sure that your records are populating before continuing.
Once your domain is verified we should see the Verification succeeded. Click Make Primary to set this as your primary domain.
Setting Up Azure AD Connect
We are now able to begin the process of syncing our On-Premises Active Directory configuration with Azure.
We will need to create a Global Administrator account in our Azure tenant specifically for use with the sync application. Follow the process listed above for configuring a Break Glass Administrator but specify the account values to be used for Azure AD Sync.
Make sure the Domain for the Sync User is an onmicrosoft.com domain
Sign in to Azure and navigate to Azure AD – Azure AD Connect
Under the Provision from Active Directory page click the link to Download Azure AD Connect
You will be brought to the Download page for Azure AD Connect. Download the AzureADConnect.msi file. Once it is finished sign in to your Primary Domain Controller with at least Enterprise Administrator level credentials and copy over the installation files.
Launch the AzureADConnect installer on your Primary Domain Controller. The package will begin installing.
When completed we should see a shortcut for Azure AD Connect on your desktop.
If the Azure AD Connect tool does not start automatically launch it using the desktop icon.
Review the information provided and Accept the license terms and privacy notice. Click Continue
We now have the option to configure Custom Options or use the Express Settings. You may want to explore the custom options for things like changing the installation location, specifying an existing SQL Server, using a specific pre-existing service account, or to specify specific groups to be synced. Review these settings and determine what is best for your configuration. For the initial configuration we will use the Express Settings.
When prompted to credentials to connect to Azure AD, enter the credentials for the Global Administrator service account you created for the sync application and click Next.
The tool will validate your credentials and perform a check against Azure. Once completed you will be asked to enter Enterprise Admin level credentials on your local Active Directory configuration. This is not a service account that will be running but rather a one time tool to create the service account that will handle the local needs for the sync task. Once you enter your credentials click Next
Once the local domain check has completed you are ready to install and configure the application. If you wish to sync right away make sure the Start the synchronization process when configuration completes checkbox is selected. Click Install.
Once the configuration is completed we should see a Configuration complete window.
As this is my test environment I have not enabled the AD Recycling bin. If you are working in a non-lab environment it is highly recommended to do so.
We can now check Azure to see our on-prem account sync status.
In the Azure Portal under Azure AD > Users we can see if the accounts are populated.
Eureka! We can see a list of all accounts in the tenant. Notice that accounts synced from the local directory are listed as Directory Synced: Yes.
We can also see that under Azure AD > Azure AD Connect our Sync Status is Enabled and that the Last Sync happened less than an hour ago.
You may notice that if we click the Manage Azure AD cloud sync link we are shown that there are no Agents or Configurations set up yet. We now need to install the Azure AD Connect Provisioning Agent. Click the Download agent button to download the MSI and copy it to your Primary Domain Controller.
Installing the Azure AD Connect Provisioning Agent
We can now install the provisioning agent tool for Azure AD Connect.
Review the License Terms and Privacy notice and click Install
In the Welcome window click Next
When prompted, enter your Sync Service Accounts credentials.
You will be prompted to create a gMSA [Group Managed Service Account] for the Azure AD Sync or to use an existing one. For this process we will be creating a new account. Enter credentials that have at least Domain Administrator credentials and click Next.
In the Connect Active Directory window review the information and click Next
In the Agent configuration window review the information and click Confirm
We should receive a notice that the Azure AD Connect Provisioning Agent Package installed successfully.
Wait a few minutes for the local agent to finish configuration and to restart. When this process has completed you can click Exit.
Head back to the Azure Portal and navigate to Azure AD > Azure AD Connect > Manage Azure AD Cloud Sync
Click New Configuration
Confirm the domain to configure is correct and click Create
After a few moments the new configuration will be created and we will be asked for some settings. Define a notification email and set the Deploy field to Enable. We can leave the rest of the settings as default for now. Click Save
If we check the Azure AD Connect cloud sync page we should see our configuration as Healthy
From our configuration page we can also manually Restart Sync if necessary.
Testing Azure Sign In
Let’s take one of our local accounts that’s been synced to Azure and confirm we can sign in to Microsoft Azure services using the password locally defined in Active Directory.
Open a new private window and navigate to https://portal.azure.com
Enter the username for one of our synced accounts. In this case I am using my personal productivity account.
Enter the password configured by your local Active Directory configuration to sign in.
We should see we are successfully able to sign in to Azure using our now synced credentials.
Testing Enforcing MFA
Note: This is a feature that requires Azure Premium including Enterprise Mobility + Security E5 as well as Azure AD Premium P2 licenses. You can sign up for a free trial to test these features out.
We should first create a group that will enforce MFA on our local domain. We can then add users to this group and sync it through Azure AD Connect to allow targeted deployment of our MFA policies.
I have created the group Productivity Azure MFA Enabled in my local domain and populated it with the user alagrassa@ad.labgrassa.com.
Once the group is created, populated, and confirmed synced with Azure we can go to the Security pane in Azure. From there select Identity Protection.
From the Identity Protection window select MFA registration policy
We want to restrict MFA enforcement to only accounts in our synced AD Group for now. In the Assignments section click All users.
Ensure we are selecting Include, ensure the Select individual and groups radio button is selected, then click 0 users and groups selected
Find the group we have created for MFA enforcement, ensure it is selected, then click Select.
Set Enforce Policy to On and click Save
Testing MFA Enforcement
The next time a user from a targeted group signs in they will be prompted to enroll for MFA if they have not already. They are given a 14 day grace period for enrollment to complete.
When we sign in using an impacted account we are presented the following message
They are given the option to enroll with their choice of Microsoft Authenticator app, email or phone. They must register at least two methods. The enrollment process is similar to the process we saw earlier setting up MFA for our Break Glass and Service Accounts.
Testing Windows OOBE With Azure Sign In
We want to make sure our users can hit the ground running with newly acquired workstations. We have deployed Windows 10 Enterprise to a new workstation and want to make sure sign in works as expected.
From our new test deployment we can enter the proper information such as region and keyboard layout.
When prompted to sign in enter the Azure AD Credentials that are synced from the local domain.
Once the password is submitted we are asked for privacy settings. We can leave these as default and click Accept.
After a short wait we are prompted to enroll in Windows Hello. Click OK
Because we have MFA enforced we are prompted to enter our MFA credentials.
We should be prompted to set a PIN for our Windows Hello credentials. Set and confirm the PIN and click OK.
Once the PIN is set click OK
We can see that our identity is our account on the ad.LabGrassa.com domain
Under Settings > Access work or school we can see we are properly linked to the LabGrassa Azure AD Tennant
Conclusion
We have created and tested Azure AD Sync and confirmed a few test settings such as Azure Sign in, MFA Enforcement, and Windows Sign in. We will continue on this by exploring hybrid management in a future guide.