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.

Hybrid Microsoft Entra ID Join: Extending Identity to Devices

Syncing users was only half the picture. My domain joined machines were still completely invisible to Entra ID. They existed in on premises Active Directory but the cloud had no idea they were there. Hybrid Microsoft Entra ID Join is what fixes that.

Going back into the Microsoft Entra Connect configuration I selected Configure device options then Configure Hybrid Microsoft Entra ID join. This is different from a full Azure AD Join where a machine leaves the on premises domain entirely. Hybrid join keeps the machine in both worlds simultaneously. Still domain joined to emeka.cloud on premises, still managed by Group Policy, but now also registered in Entra ID and visible from the cloud.

Configure Hybrid Microsoft Entra ID join selected in Microsoft Entra Connect device options. This registers domain joined machines with Entra ID while keeping them joined to the on premises emeka.cloud Active Directory. The result is devices managed by Group Policy on premises and visible in Entra ID in the cloud at the same time.

The key thing Entra Connect configures during this process is the Service Connection Point. The SCP is an object written directly into my on premises Active Directory that tells domain joined machines where to find the Entra ID tenant. Without it machines have no way of automatically discovering Entra ID when they try to register. Once the SCP was written to emeka.cloud using Enterprise Admin credentials the domain joined machines could find the tenant and complete their registration.

I selected Windows 10 or later domain-joined devices only. The other option covers Windows 7 and 8.1 which require AD FS for hybrid join. This environment has no downlevel devices and no AD FS so that option was not relevant.

SCP Configuration showing the Service Connection Point being written to the emeka.cloud Active Directory forest using Enterprise Admin credentials. The SCP is the object domain joined machines look up in AD to find the Entra ID tenant when they attempt to register. Without this written to AD the hybrid join process cannot complete automatically

One thing I noticed after the configuration completed was a new computer account called AZUREADSSOACC appearing in the Computers container in Active Directory. This is created automatically by Entra Connect when Single Sign-On is enabled. It is not a real machine — it is a Kerberos decryption account that makes seamless SSO work. When a domain joined machine tries to authenticate to Microsoft 365 silently without prompting the user for credentials, it uses a Kerberos ticket. The AZUREADSSOACC account holds the Kerberos decryption key that Entra ID uses to validate that ticket. Without this account seamless SSO cannot function. It sits in the Computers container rather than any of my custom OUs because Entra Connect creates it there automatically and it should be left exactly where it is.

AZUREADSSOACC computer account created automatically in the Computers container by Microsoft Entra Connect during Single Sign-On configuration. This is not a physical machine. It is a Kerberos decryption account that enables seamless SSO. When a domain joined machine authenticates to Microsoft 365 silently it presents a Kerberos ticket which Entra ID validates using the decryption key held by this account. It lives in the Computers container because Entra Connect places it there automatically and it should not be moved

After the configuration completed I went to DELL-LAPTOP, ran gpupdate /force, restarted and then ran dsregcmd /join to trigger the registration. I ran the status check logged in as tina.timothy rather than the admin account to confirm hybrid join works for synced domain users not just administrators.

dsregcmd /status on DELL-LAPTOP confirming successful Hybrid Microsoft Entra ID join. AzureADJoined: YES and DomainJoined: YES simultaneously. The machine is managed by on premises Active Directory through Group Policy and also registered in Entra ID in the cloud. DeviceAuthStatus: SUCCESS confirms the device certificate is valid and Entra ID authentication is working. Run as tina.timothy to confirm hybrid join works for synced domain users not just the admin account."

Checking the Entra ID Devices page confirmed everything had registered correctly.

Microsoft Entra ID Devices page showing all registered devices. Dell-Laptop showing as Hybrid Microsoft Entra joined confirming the hybrid join completed successfully. ADCON-MID also showing as Hybrid joined because it is a domain joined Windows Server in the Servers OU which was included in the sync scope and registered automatically. iPhone 16 Pro Max showing as Microsoft Entra registered because signing into Microsoft 365 and Authenticator on the device triggered automatic registration. HP-PAVILION will appear once the same process is completed on that machine.

With users synced and devices registered in Entra ID the hybrid identity picture is now complete for this environment. Users that started in on premises Active Directory now exist in Entra ID. Machines that were only known to on premises AD are now visible in the cloud. The foundation is in place for everything that follows.

Microsoft Entra ID

Managing Cloud Identities

Once the sync ran and the hybrid join completed, Entra ID became the central identity platform for the entire environment. On premises users exist here. The cloud only admin account exists here. Devices are registered here. Every application that needs to verify who someone is goes through Entra ID. It is the single point of identity for both on premises and cloud resources.

Microsoft Entra ID All Users page showing all accounts in the emeka.cloud tenant. The On-premises sync enabled column tells the whole story, emeka@emeka.cloud shows No, confirming it is a cloud only account created directly in Microsoft 365

Cloud Only vs Synced Accounts

This is the most important distinction I had to understand in a hybrid environment.

emeka@emeka.cloud is a cloud only account. I created it directly in Microsoft 365 before any sync was configured. It exists only in Entra ID and can only be used to sign into cloud services. I deliberately keep it this way as a break-glass global admin account. If the sync ever breaks, if Entra Connect goes down, if something goes wrong with the on premises environment, this account still works and I can still get into the tenant. That is why Microsoft recommends keeping at least one cloud only global admin account in every hybrid environment, (Microsoft).

Other users are synced accounts. They started life in my on premises Active Directory and Entra Connect brought them into Entra ID. The critical thing about synced accounts is where changes must be made. If I need to update a synced user's name, department or job title I have to do it in ADUC on DC1. Not in Entra ID. The next sync cycle picks up the change and reflects it in the cloud automatically. Trying to edit those attributes directly in Entra ID does not work because most of them are greyed out.

Attribute Properties of an on-prem user

Properties of emeka@emeka.cloud in Microsoft Entra ID confirming cloud only attributes.

Licence Assignment

Synced users appear in Entra ID and Microsoft 365 automatically after the sync but they arrive unlicensed. They exist as identities but cannot access any Microsoft 365 services until a licence is assigned. With two Microsoft 365 Business Basic licences available, emeka@emeka.cloud holds one as the global admin account. The second licence goes to tina.timothy who is the primary standard user for demonstrating Microsoft 365 services throughout this project.

emeka.iwu, tina.tymokhin and james.bond sync to Entra ID and are visible for identity management but remain unlicensed. They cannot access Microsoft 365 apps but their identities are centrally managed alongside everyone else.

Microsoft 365 Business Basic licence assigned to tina.timothy@emeka.cloud. As a synced account Tina arrived in Microsoft 365 unlicensed after the Entra Connect sync. Licence assignment is done manually here or can be automated through group based licensing in Entra ID. With the licence assigned Tina now has access to Exchange Online, Teams, SharePoint and OneDrive

Groups Synced from On Premises AD

The security groups built during the ADDS project did not stay on premises. Entra Connect synced them to Entra ID alongside the user accounts. HR-Staff, IT-Staff and the other department security groups all appear in Entra ID Groups. This matters because those same groups will be used to control access in SharePoint and Teams later in this project. The group that gives someone access to the HR shared drive on premises is the same group that gives them access to the HR SharePoint site in the cloud. One group, consistent access control across both environments.

Microsoft Entra ID Groups page showing all groups including security groups synced from the on premises Active Directory.

MFA, Conditional Access and Self Service Password Reset

Securing Cloud Identity

Having user identities in the cloud is only valuable if those identities are properly protected. A username and password alone is not enough. I already knew this before this project as every time I sign into my global admin account Microsoft asks me to confirm a code on my Authenticator app. Setting it up deliberately for other users in this project made me understand exactly how it works and why it matters.

What MFA Actually Is

I implemented MFA, meaning that signing in will require more than just a password. After entering the correct password a user is asked to prove their identity a second way like; approving a notification on the Microsoft Authenticator app, entering a code from the app or using another registered method. Even if someone steals a password they still cannot get in without that second factor.

The way I configured MFA here is through Conditional Access rather than the older per-user MFA settings. Conditional Access is the modern recommended approach. It gives granular control over when MFA is required, for which users, on which apps and under what conditions. Per-user MFA is a blunt instrument — it is either on or off for each person. Conditional Access is a policy engine that evaluates multiple signals before making an access decision.

Authentication Methods Policies page in Microsoft Entra ID showing the available MFA methods for the emeka.cloud tenant. Microsoft Authenticator and Passkey are enabled for all users. Email OTP and Software OATH tokens also enabled. SMS and Voice call disabled because they are less secure methods and not needed when Authenticator is available. These are the methods users can register and use for both MFA and Self Service Password Reset.

Conditional Access — The Policy Engine

Conditional Access evaluates who is signing in, what they are signing into, where they are signing in from and what device they are using. Based on those signals it either allows access, blocks access or requires additional verification like MFA. It is a set of rules that can be as broad or as targeted as needed

Conditional Access Policies page showing two active policies in the emeka.cloud tenant. Both policies are enabled and enforcing. Conditional Access requires Entra ID P1 or above, which is not included in Microsoft 365 Business Basic. The Entra ID P2 free trial was activated to access this feature and demonstrate it properly.

Policy 1: Require MFA for All Users

The first policy is the most fundamental. Every sign in to any cloud app by any user in the tenant requires MFA. No exceptions for standard users. The policy targets all users, all cloud apps and grants access only when MFA has been satisfied.

Require MFA for All Users policy configuration targets all users (except the global admin), all cloud apps, granting access only when multifactor authentication is satisfied. This is the baseline security policy for the tenant. Every sign in to Microsoft 365, Azure or any connected app requires a second factor regardless of who the user is or where they are signing in from.

Policy 2: Block Sign In Outside the UK

The second policy is a location based control. Sign in attempts from outside the United Kingdom are blocked entirely. To make this work I first created a Named Location in Conditional Access called United Kingdom. The policy then includes any location and excludes the United Kingdom, meaning anything that is not the UK gets blocked.

I deliberately excluded the Global Administrator role from this policy. This is important. If you block all users including yourself from signing in outside the UK and you happen to be abroad, you lock yourself out of the tenant with no way back in. Excluding Global Administrator from blocking policies was a safety measure.

Named Location configured in Conditional Access for the United Kingdom. Named Locations are referenced in Conditional Access policies to target or exclude specific geographic regions. The Block Sign In Outside UK policy includes any location and excludes this named location, meaning any sign in attempt originating outside the UK is blocked at the policy level.

Block Sign In Outside UK policy configuration — targeting all users with Global Administrator excluded deliberately. Including any location and excluding the United Kingdom named location. Grant set to Block access. Global Administrator excluded as a safety measure

Testing MFA as Tina Timothy

To test, I signedin in as tina.timothy@emeka.cloud for the first time after the policy was enabled. Signing into office.com as Tina triggered the MFA registration prompt immediately. She was asked to set up Microsoft Authenticator before being allowed to continue. Once set up the Authenticator app was registered and Tina was signed in with full access to her licensed Microsoft 365 apps.

I also tested with emeka.iwu@emeka.cloud. MFA kicked in for that account too even though emeka.iwu has no Microsoft 365 licence. The account authenticated successfully through MFA but landed on a limited view with no access to Microsoft 365 apps. That is exactly what I expected and it demonstrates two things at once; Conditional Access applies to all users regardless of licence status, and licences control what apps you can access after authentication.

MFA registration prompt appearing for tina.timothy@emeka.cloud on first sign in after the Conditional Access policy was enabled

tina.timothy@emeka.cloud signed into Microsoft 365 after completing MFA registration. Full app access available; Outlook, Teams, Word, Excel, PowerPoint, OneNote, OneDrive and SharePoint all accessible. MFA satisfied, Conditional Access policy passed, licence assigned.

emeka.iwu@emeka.cloud signed into Microsoft 365 after completing MFA. Limited app access compared to tina.timothy because emeka.iwu has no Microsoft 365 Business Basic licence assigned

Self Service Password Reset

SSPR lets users reset their own passwords without calling the helpdesk. In ITIL terms this reduces the volume of password reset incidents that would otherwise hit the service desk — one of the most common ticket types in any organisation. I enabled SSPR for all users in the tenant through the Password Reset properties page in Entra ID.

With Password Writeback configured during the Entra Connect setup, any password reset through SSPR automatically writes back to the on premises Active Directory. The user ends up with one consistent password across both on premises and cloud without IT needing to touch anything.

Self Service Password Reset enabled for all users in the emeka.cloud tenant. With Password Writeback configured through Microsoft Entra Connect, any password reset through the SSPR portal automatically updates the on premises Active Directory password as well

Exchange Online

Cloud Email Administration

One of the first decisions I made when setting up this project was whether to keep Zoho handling my email or move everything to Microsoft Exchange Online. I decided to move fully to Exchange Online. It made more sense to have everything under one platform; identity, email, Teams and SharePoint all connected rather than split across two providers.

Exchange admin centre showing active mailboxes for the emeka.cloud tenant. emeka@emeka.cloud and tina.timothy@emeka.cloud both have Exchange Online mailboxes assigned automatically when their Microsoft 365 Business Basic licences were activated.

Shared Mailbox: helpdesk@emeka.cloud

A shared mailbox is one that multiple people can access and send from without needing a dedicated licence. The helpdesk@emeka.cloud shared mailbox was created so that helpdesk emails can be received and responded to centrally rather than going to one person's individual inbox.

I delegated access to emeka@emeka.cloud so the admin account can read and send on behalf of the helpdesk address. In a real organisation this would be delegated to the whole IT support team so any member can handle incoming helpdesk emails without them needing to share login credentials.

helpdesk@emeka.cloud shared mailbox created in Exchange Online with emeka@emeka.cloud delegated as a member. Shared mailboxes do not require a Microsoft 365 licence which makes them cost effective for team inboxes like IT support, finance queries or general enquiries. The delegation means the admin account can read, reply and send as helpdesk@emeka.cloud without needing a separate login.

Shared mailbox showing the left panel of emeka@emeka.cloud mailbox. This is only possible because permissions were already assigned

Distribution Group: All Staff

A distribution group is an email address that delivers to multiple recipients at once. I created allstaff@emeka.cloud as a distribution group with both emeka@emeka.cloud and tina.timothy@emeka.cloud as members. Sending an email to allstaff@emeka.cloud delivers it to both accounts simultaneously.

The distinction between a distribution group and a security group is that a Distribution groups are email only, they cannot be used for permissions, SharePoint access or Conditional Access targeting. Security groups handle access control.

All Staff distribution group created in Microsoft 365 with emeka@emeka.cloud and tina.timothy@emeka.cloud as members. Sending to allstaff@emeka.cloud delivers to both accounts simultaneously.

Internal Email Flow

Testing the internal email flow was straightforward. Signed into Outlook as emeka@emeka.cloud, composed an email to tina.timothy@emeka.cloud and sent it. Opened Outlook as tina.timothy in a separate browser window and the email had already arrived. As it was a communication between users in the same tenant, no MX records was involved, no external routing, Microsoft delivered it internally within the tenant instantly.

This matters because it confirms Exchange Online is working correctly for the most common scenario in any organisation, like colleagues emailing each other. Everything else like shared mailboxes, distribution groups and email rules builds on top of this basic internal flow working correctly.

Internal email composed and sent from emeka@emeka.cloud to tina.timothy@emeka.cloud through Outlook online. Both accounts are in the same Microsoft 365 tenant so Microsoft delivers this internally without it leaving the platform or going through MX records.

The same email received in tina.timothy@emeka.cloud's Outlook inbox confirming internal email flow is working correctly between tenant users. Delivered instantly without any external routing.

Page updated

Google Sites

Report abuse