Microsoft 365, Azure and Hybrid Identity: Cloud Administration Home Project

Extending on-premises Active Directory to the cloud using Azure AD Connect, Microsoft Entra ID, Exchange Online, Teams, SharePoint, Intune, MDT and Azure Arc.

PROJECT OVERVIEW

The ADDS project gave me a working on premises Active Directory environment. Two Domain Controllers, Group Policy, user lifecycle management, shared storage and a Hyper-V home lab all running on emeka.cloud. That was the foundation. This project is what comes next.

Most organisations do not run purely on premises or purely in the cloud. They run both, connected through hybrid identity. A user's Active Directory account on premises is the same identity they use to sign into Microsoft 365, access their emails, join a Teams call and open a SharePoint document. Building that connection myself, understanding how it works under the hood and documenting it is exactly what this project is about.

There is also a bigger picture I am working toward. When I complete the MID Server project, I want my on premises Active Directory environment, my Microsoft 365 cloud environment and my AWS EC2 infrastructure all feeding into a single ServiceNow CMDB. That is a complete ITOM picture built entirely from scratch in a home lab. This project is the middle piece that makes it possible.

What This Project Covers:

This project is more complex than the ADDS project and deliberately so. Starting from a verified Microsoft 365 tenant and a free Azure account, I extended the on premises emeka.cloud Active Directory environment into Microsoft Entra ID using Microsoft Entra Connect. From there the project covers cloud identity management, MFA and Conditional Access, Windows Hello for Business, Exchange Online email administration, Windows deployment using MDT and ADK, Microsoft 365 Apps deployment using the Office Deployment Tool, Intune device management across Windows, macOS and iOS, LAPS for Entra ID, Windows kiosk mode, update rings, app protection policies, server management using Windows Admin Centre and Azure Arc, Teams and SharePoint administration and Microsoft 365 security and compliance.

Every section is built hands on and documented as I go. Nothing is pre-configured or templated. Same approach as the ADDS project.

Skills Demonstrated:

Hybrid Identity and Azure AD Connect Syncing on premises Active Directory users to Microsoft Entra ID using Microsoft Entra Connect (formerly Azure AD Connect). One identity working both on premises and in the cloud.

Microsoft Entra ID Managing cloud identities, understanding the difference between cloud-only and synced accounts, assigning licenses, and managing access from the Entra ID portal.

MFA, Conditional Access and Windows Hello for Business Enforcing Multi Factor Authentication, building Conditional Access policies that control how and where users sign in, and configuring Windows Hello for Business for passwordless authentication.

Exchange Online Full cloud email administration. Mailbox management, shared mailboxes, distribution groups and email flow. Email fully migrated from Zoho to Microsoft Exchange Online as part of this project.

Windows Deployment with MDT, ADK and Office Deployment Tool Building an automated Windows deployment pipeline using Microsoft Deployment Toolkit and Windows Assessment and Deployment Kit. Task sequences, boot images and network based deployment. Microsoft 365 Apps deployed using the Office Deployment Tool and Office Customisation Tool.

Microsoft Intune and Endpoint Management Enrolling and managing Windows, macOS and iOS devices from a single Intune console. Compliance policies, configuration profiles, app protection policies, update rings, Windows kiosk mode, LAPS for Entra ID and device actions across multiple device types and operating systems.

Windows Admin Centre Browser-based management of on-premises Domain Controllers and Hyper-V hosts from a single modern interface without using multiple MMC consoles.
Azure Arc Onboarding on-premises servers to Azure for cloud-based monitoring, policy enforcement and security assessment without moving them to the cloud.

Teams and SharePoint Administration Creating and managing department Teams and SharePoint sites. Permissions tied to the security groups built in the ADDS project, so access management stays consistent across on-premises and cloud.

Microsoft 365 Security and Compliance Microsoft Secure Score, audit logging, usage reporting and security posture management across the entire Microsoft 365 environment.

MDT vs Intune: Traditional vs Modern Deployment Demonstrating both traditional on-premises Windows deployment using MDT and modern cloud-based device management using Intune. Most organisations are somewhere between the two during their transition to modern management. Understanding both is what makes the difference in a real IT support role.

Microsoft 365 admin centre for the emeka.cloud tenant. Microsoft 365 Business Basic subscription with Exchange Online fully configured and emeka.cloud set as the primary domain.

Microsoft Entra ID overview for the emeka.cloud tenant. Entra ID sits at the centre of this project by connecting on-premises Active Directory through Azure AD Connect, securing access through MFA and Conditional Access and managing identities across both Microsoft 365 and Azure.

Azure subscription activated under emeka@emeka.cloud — the same account used for Microsoft 365 and Entra ID. Free account with $200 credit providing access to Azure services, including Entra ID, Azure AD Connect configuration and Azure Arc for on-premises server management.

ENVIRONMENT SETUP

What I Built and What I Used:

Before building anything, I needed a clear picture of the full environment. This project does not replace anything built in the ADDS project. Everything on premises stays exactly as it was. This project layers cloud identity, cloud administration and modern device management on top of that existing foundation.

Microsoft 365 Business Basic Monthly rolling subscription for 2 users. Includes Exchange Online, Teams, SharePoint, OneDrive and the Microsoft 365 admin centre. Email has been fully migrated from Zoho to Microsoft Exchange Online as part of this project. emeka.cloud is the primary domain, and all users have @emeka.cloud addresses.

Microsoft Azure Free account activated under emeka@emeka.cloud with $200 credit. Entra ID is included permanently under the free tier. The same account connects Microsoft 365, Azure and Entra ID under one identity; no switching between accounts, no separate tenants.

emeka.cloud Custom Domain Verified in Microsoft 365 admin centre as the primary custom domain. Used across Microsoft 365, Entra ID and Azure under the same tenant. SPF record updated in Namecheap to cover Microsoft Exchange Online and sends on behalf of emeka.cloud without conflicting.

ADCON-MID Dedicated Windows Server 2022 VM on the same Hyper-V host as DC1. 2 vCPUs, 4GB RAM, 50GB storage. Domain joined to emeka.cloud. This single VM hosts multiple roles, including Azure AD Connect for hybrid identity sync, MDT and ADK for Windows deployment, and the ServiceNow MID Server in the next project. Kept on the same host as DC1, so it stays available whenever the host is running.

Windows ADK and Windows PE Add-on Windows Assessment and Deployment Kit installed on ADCON-MID. Provides the deployment engine, Windows PE boot environment and the imaging tools MDT depends on. Free download from Microsoft. ADK installed before MDT because MDT cannot function without it.

Microsoft Deployment Toolkit MDT installed on ADCON-MID alongside ADK. Provides the automated deployment framework, including deployment shares, task sequences and network-based Windows deployment. Free tool from Microsoft used alongside ADK to build a traditional Windows deployment pipeline.

Office Deployment Tool Free Microsoft tool for deploying and customising Microsoft 365 Apps. Used alongside the Office Customisation Tool to configure exactly which apps get installed, which features are included and how updates are managed. Installed and configured on ADCON-MID as part of the deployment pipeline.

Existing On Premises Environment DC1 and DC2 running Windows Server 2022 on separate Hyper-V hosts. DELL-LAPTOP running Windows 11 and HP-PAVILION running Windows 10 on bare metal. All domain joined to emeka.cloud. Three on-premises users ready to sync to Entra ID via Azure AD Connect.

Why ADCON-MID Runs Multiple Roles:

In an enterprise environment, each of these roles would typically run on a dedicated server. Azure AD Connect on its own VM, MDT on its own deployment server. For a home lab, that approach would mean creating and managing several additional VMs, which adds unnecessary complexity without adding meaningful learning.

Running multiple roles on one dedicated VM is a conscious decision based on the scale of the environment. The machine is not a workstation, and it is not a Domain Controller. It is a dedicated utility VM that exists purely to run background services and tools. That distinction matters and is worth understanding that it is the same thinking that drives server consolidation decisions in real organisations.

How This Connects to the ADDS Project

The OU structure, security groups, user accounts and Group Policy objects all remain on premises exactly as documented in the ADDS project. Azure AD Connect will sync those identities to Entra ID. Intune will manage the same physical devices that were domain-joined and GPO-managed in the ADDS project. The security groups from ADDS will set permissions in SharePoint and Teams. This is one environment built in two phases: on-premises first, cloud second.

ADCON-MID, A dedicated Windows server VM domain joined to emeka.cloud on the same Hyper-V host as DC1. Hosts Azure AD Connect, MDT and ADK and will host the ServiceNow MID Server in the next project

ADCON-MID moved into the Servers OU in Active Directory Users and Computers. Separated from workstations deliberately as servers and workstations have different management requirements and keeping them in separate OUs means Group Policy can be targeted correctly at each.

Microsoft Deployment Toolkit Deployment Workbench open on ADCON-MID

Hybrid Identity with Microsoft Entra Connect (formerly Azure AD Connect)

Connecting On Premises to the Cloud:

This is the section where the ADDS project and this project actually meet. Everything I built on premises including the Domain Controllers, the OUs, the user accounts which existed in isolation up to this point. Microsoft 365 was set up but had no idea my on premises Active Directory existed. Microsoft Entra Connect is what bridges that gap.

Once the sync ran, my on premises users existed in two places at once. They are still in Active Directory on premises, managed the same way they always were. But now they also exist in Entra ID in the cloud. One identity, two locations. That is hybrid identity and that is what most organisations actually run today.

Microsoft Entra Connect Get Started page showing two sync options: Cloud Sync and Connect Sync. Connect Sync selected deliberately. Cloud Sync is a newer lightweight approach designed for simpler environments but has limitations around which scenarios it supports. Connect Sync is the full installation that supports all hybrid identity scenarios including Hybrid Azure AD Join, password writeback and granular OU filtering. This is what enterprise environments use and what this project needed

Why Customise Over Express:

The wizard gave me two options straight away: Express or Customise. Express would have synced everything in my directory automatically using Microsoft defaults. That sounds convenient but the problem is it would have pushed Domain Controllers, Builtin accounts and system containers into Entra ID. These are objects that have no business being in the cloud.

I chose Customise because I wanted to control exactly what gets synced. That meant selecting specific OUs, choosing the authentication method deliberately and understanding every decision I was making rather than clicking through a wizard and hoping for the best.

Microsoft Entra connect Sync wizard showing the 2 setup paths: Customize and Express

How Users Authenticate to the Cloud:

One of the most important decisions in the whole setup is how users prove who they are when signing into Microsoft 365. There were three main options — Password Hash Sync, Pass-through Authentication and Federation with AD FS.

I chose Password Hash Sync. It syncs a hash of the on premises password up to Entra ID so users sign into Microsoft 365 with the same credentials they already use on their domain joined machines. The reason I picked this over the others is resilience. Pass-through Authentication and AD FS both need the on premises environment to be available every time a user signs into the cloud. If my DC goes down, cloud sign in breaks too. With Password Hash Sync the hash is stored in Entra ID, and cloud authentication works independently of whatever is happening on premises.

I also enabled Single Sign-On. This means a user already logged into DELL-LAPTOP does not get asked for their password again when they open Teams or Outlook. The machine's existing Windows session is used to authenticate them automatically. That is the experience enterprise users expect and it is how it should work.

User Sign-In screen showing Password Hash Synchronization selected and Single Sign-On enabled. I chose Password Hash Sync over Pass-through Authentication and AD FS because it does not create a dependency on my on premises environment being available for every cloud sign in. Single Sign-On means users already logged into a domain joined machine authenticate to Microsoft 365 automatically without being prompted.

Connecting to the On Premises Directory:

The next step was pointing Entra Connect at my on premises emeka.cloud forest. When I clicked Add Directory it asked for domain administrator credentials. What happens behind the scenes is Entra Connect uses those credentials once to create a dedicated synchronisation service account in Active Directory, a service account with only the permissions it needs to read the directory and run the sync. My administrator credentials are not stored after that. Future syncs run under that dedicated service account.

That is least privilege applied correctly. A specific account for a specific job with nothing extra.

Active Directory forest asking for a service account to sync with

emeka.cloud Active Directory forest successfully added as a configured directory, the green tick confirms Entra Connect can communicate with DC1 and has the right permissions. A dedicated sync service account was created automatically in my on premises AD during this step. All future sync operations run under that account rather than the domain administrator credentials.

Choosing What Gets Synced:

The OU filtering screen was the most important part of the whole setup. By default every OU and container in the domain is selected, which means if I had just clicked Next without thinking, Domain Controllers, Builtin accounts, system objects and internal containers would all end up in Entra ID.

I went through the list deliberately and unticked everything that should never go to the cloud.

What I kept:

Departments: my three on premises users live here across the HR, IT and Operations OUs
Workstations: DELL-LAPTOP and HP-PAVILION
Servers: ADCON-MID
Disabled Accounts: worth keeping for visibility and audit purposes

This is exactly why I chose Customise over Express. Express would have synced everything. Customise let me be deliberate about what ends up in the cloud.

Domain and OU Filtering showing only the OUs that need to be in the cloud are selected. Domain Controllers, Builtin, System and other internal containers excluded. Departments, Workstations, Servers and Disabled Accounts included. This is what Customise mode is for, keeping the Entra ID directory clean and scoped to objects that have a real reason to exist there.

Password Writeback:

On the Optional Features screen I enabled Password Writeback alongside Password Hash Sync. This one matters for Self Service Password Reset which I configure in Section 5. Without Password Writeback, if a user resets their password through the cloud SSPR portal their on premises password stays unchanged. They would end up with two different passwords for what is supposed to be one identity. Password Writeback closes that gap. Cloud password resets flow back to on premises AD automatically.

Optional features with Password writeback enabled.

Configuration complete. Microsoft Entra Connect Sync installed and running on ADCON-MID. Password Hash Sync, Single Sign-On and Password Writeback all confirmed. The initial sync started automatically as soon as installation finished. mS-DS-ConsistencyGuid is being used as the source anchor, this means even if a user's UPN changes in the future their cloud identity stays correctly linked to their on premises account.

Verifying the Sync Worked:

Once the installer finished I went straight to three places to confirm everything had actually synced correctly.

Synchronization Service Manager on ADCON-MID showing all connector operations completing successfully after resolving a permission issue on the sync service account. The emeka.cloud Export operation previously showed completed-export-errors with error code 8344, meaning insufficient access rights. Delegating the correct write permissions to the MSOL sync account on the domain resolved it. Password Writeback is now fully operational, cloud password resets will write back to on premises AD automatically

Microsoft Entra ID showing all accounts in the emeka.cloud tenant after the first sync. emeka@emeka.cloud is my cloud only global admin account, created directly in Microsoft 365 and intentionally never synced from on premises. It stays as a cloud only break-glass admin account that works even if the sync breaks. emeka.iwu, tina.timothy, tina.tymokhin and james.bond all came from the on premises Active Directory, their identities started on premises and now exist in both places.

Microsoft 365 admin centre showing all synced users now visible as Active Users. emeka@emeka.cloud holds the Microsoft 365 Business Basic licence. The rest are unlicensed existing as identities in the tenant but cannot access Microsoft 365 apps until a licence is assigned. Tina Timothy gets the second licence as the primary standard user for demonstrating Microsoft 365 services throughout this project.

Page updated

Google Sites

Report abuse