Lab ID
IB-ENTRA-SEC-09
Lab Metadata
Core technologies
Scenario and Description
IN PLAIN TERMS
Picture your on-premises directory and the cloud as two buildings joined by one private bridge, with a single caretaker who holds the keys to both ends. If a burglar takes over the caretaker's office, they do not need to break into either building, they own the connection itself. This lab treats that bridge and its caretaker as the most guarded room on the whole site, changes the shared locks that were fitted years ago and never rotated, and removes an old side-gate that would let someone forge a pass for anyone.
Northgate did not start in the cloud. Like most financial firms it runs on-premises Active Directory, and it synchronises those identities to Entra so staff have one account for both worlds. That synchronisation is convenient and necessary, and it is also a bridge that attackers love, because the components that build it sit astride both the on-premises and cloud trust boundaries.
The synchronisation server, whether it runs Microsoft Entra Connect Sync or the lighter Entra Cloud Sync agent, is a tier-zero asset: as sensitive as a domain controller. Its service account holds directory-replication rights, which is the same capability a DCSync attack abuses to extract every password hash in the domain. If Seamless single sign-on is enabled, a shared computer account in AD holds a Kerberos key that, left unrotated, enables ticket forgery. If federation with AD FS is in play, theft of the token-signing key enables Golden SAML, forging a valid token for any user, bypassing every cloud control you built in the earlier labs.
This lab is about seeing and shrinking that hybrid attack surface. You will assess the tenant's hybrid configuration from Graph, choose and justify the right sync topology, ensure Password Hash Synchronisation is enabled (which also powers the leaked-credential detection you use in Lab 10), then harden the sync account, isolate the sync server as tier zero, rotate the Seamless SSO Kerberos key, and plan the migration off AD FS. The on-premises commands are documented precisely so you can run them against a lab domain if you have one.
Prerequisites
Prior labs
Labs 01 and 05 recommended. The domain and federation assessment from Lab 05 feeds directly into the hybrid posture check here, and Password Hash Sync configured in this lab enables the leaked-credential detection used in Lab 10.
INFO: what is hands-on versus documented
Installing Entra Connect or Cloud Sync needs an on-premises AD and a Windows server, which a cloud-only trial tenant does not have. The tenant-side assessment (Graph) is fully hands-on. The sync topology, hardening and Seamless SSO key rotation use precise on-premises commands you can run if you have a lab domain (for example a single Windows Server VM promoted to a domain controller). Everything is documented to production standard either way.
Graph scopes introduced
| Scope | Why it is needed |
|---|---|
OnPremDirectorySynchronization.Read.All | Read the on-premises synchronisation configuration and features |
Organization.Read.All, Directory.Read.All | Read tenant sync state, synced users and federated domains |
Real-World Problem Statement
Every cloud control you have built assumes the attacker comes through the front door. Hybrid components are a side door that bypasses them. If the sync account or server is compromised, an attacker does not need to beat Conditional Access or phishing-resistant MFA, they can operate as the directory itself.
| Dimension | Why this matters |
|---|---|
| Risk | The sync account can DCSync the domain, and a stolen AD FS token-signing key enables Golden SAML. These bypass cloud MFA entirely. |
| Compliance | Tier-zero asset protection and identity-bridge hardening are core expectations in any serious identity audit. |
| Productivity | Cloud Sync with a group managed service account and high-availability agents reduces the operational burden of the legacy Connect server. |
| Security posture | Hardening the hybrid bridge protects the on-premises and cloud estates at their most exposed junction. |
Concrete scenario: Northgate runs an ageing Entra Connect server that also hosts other tools, its sync account has a weak password set years ago, Seamless SSO was enabled once and never revisited, and two domains are still federated to a decommissioning AD FS farm. Your job is to bring the hybrid bridge up to tier-zero standard and remove the token-forgery paths.
Skills Mapped to Production Solutions
| Skill learned in this lab | Real-world enterprise application |
|---|---|
| Assessing hybrid sync configuration via Graph | Auditing PHS, writeback and federation posture across the estate |
| Choosing Cloud Sync versus Connect Sync | Selecting the right, most secure topology for a given environment |
| Hardening the sync account and server as tier zero | Protecting the identity bridge to the standard of a domain controller |
| Rotating the Seamless SSO Kerberos key | Closing a persistent ticket-forgery path |
| Planning AD FS to cloud-auth migration | Removing the Golden SAML risk from the estate |
Architecture Overview
The hybrid bridge has a small number of highly sensitive parts. Understanding which they are, and what an attacker gains from each, is the whole point of the hardening that follows.
The sensitive components and what an attacker gains
| Component | What it is | Attacker payoff if compromised |
|---|---|---|
| Sync service account | On-prem account used by Connect Sync, with directory-replication rights | DCSync: extract every password hash in the domain |
| Sync server | Host running Connect Sync or the Cloud Sync agent | Full control of the identity bridge, both directions |
| AZUREADSSOACC | Computer account created by Seamless SSO, holds a Kerberos decryption key | Silver Ticket forgery for Seamless SSO if the key is never rotated |
| AD FS token-signing key | Private key that signs SAML tokens for federated sign-in | Golden SAML: forge a valid token for any user, bypassing cloud MFA |
PRODUCTION CONSIDERATION
Entra Cloud Sync is Microsoft's strategic direction for most topologies. It runs a lightweight agent that uses a group managed service account (no static sync-account password to steal), supports multiple agents for high availability, and is configured in the cloud. Where the environment fits Cloud Sync's supported scenarios, it is both simpler to run and a smaller attack surface than the classic Connect Sync server.
Step-by-Step Implementation
Phase A - Assess the hybrid posture (hands-on, tenant side)
1Read sync state, PHS, writeback and federation from Graph
Purpose: know exactly how this tenant is bridged before changing anything.
Assess the on-premises synchronisation configuration
Connect-MgGraph -Scopes 'Organization.Read.All','Directory.Read.All', 'OnPremDirectorySynchronization.Read.All' -NoWelcome # Is directory sync on, and when did it last run? Get-MgOrganization | Select-Object DisplayName, OnPremisesSyncEnabled, OnPremisesLastSyncDateTime # Sync feature configuration: PHS, writeback, and hard-match protection. $sync = Get-MgDirectoryOnPremiseSynchronization $sync.Features | Format-List # Federated domains (AD FS present) - reuse the Lab 05 lens. Get-MgDomain -All | Where-Object { $_.AuthenticationType -eq 'Federated' } | Select-Object Id, IsVerified, AuthenticationType # How many users are actually synced from on-prem? (Get-MgUser -All -Property onPremisesSyncEnabled | Where-Object { $_.OnPremisesSyncEnabled }).Count
VERIFICATION
In a cloud-only trial tenant,
OnPremisesSyncEnabled is false and there are no synced users or federated domains, that is the expected clean baseline. In a hybrid tenant this reveals whether PHS and writeback are on and whether any domain is still federated, which drives every decision below.
What just happened? You produced a factual hybrid posture: sync on or off, PHS on or off, writeback on or off, and whether AD FS federation still exists. This is the map you harden against.
Phase B - Choose topology and enable Password Hash Sync
REAL WORLD ANALOGYPassword Hash Sync does not send your password to the cloud. It sends a fingerprint of a fingerprint, a hash of the hash, which cannot be used to open anything. Its value is comparison: when criminals publish stolen credentials online, the cloud can hold its smudged copy against the published list and shout if yours appears, which is exactly the leaked-credential alarm Lab 10 wires up.
2Decide Cloud Sync versus Connect Sync, and turn PHS on
Purpose: land on the most secure supported topology and enable the sign-in method that also unlocks leaked-credential detection.
Topology decision and PHS enablement (on-premises)
# TOPOLOGY DECISION: # - Prefer Entra Cloud Sync when your environment fits its supported scenarios # (uses a gMSA, HA agents, cloud-configured, smaller footprint). # - Use Entra Connect Sync for complex scenarios Cloud Sync does not yet cover # (e.g. certain writeback and filtering needs). Ensure it is v2, not the # retired v1. # # ENABLE PASSWORD HASH SYNC (recommended for almost all tenants, even if # federated or using pass-through auth, as a backup and to enable leaked- # credential detection in Identity Protection - see Lab 10): # Entra Connect: rerun the wizard > Customize > User sign-in > # tick 'Password hash synchronization'. # Cloud Sync: PHS is part of the provisioning configuration. # # Confirm PHS from the cloud side afterwards: (Get-MgDirectoryOnPremiseSynchronization).Features | Select-Object PasswordHashSync
INFO: PHS does not send the actual password
Password Hash Sync sends a hash of the on-premises password hash, not the password and not the usable NTLM hash. It cannot be used to sign in on-premises. Its value is that Entra can then detect when a user's credentials appear in a known breach corpus, which is the leaked-credential signal Lab 10 acts on.
Phase C - Harden the sync account and server (tier zero)
REAL WORLD ANALOGYThe caretaker who holds keys to both buildings gets the same guards as the vault itself. In practice that means the sync server does one job only, no email, no browsing, no other software, and only the most trusted staff may even enter the room. Any convenience granted to that machine is convenience granted to whoever eventually compromises it.
3Protect the identity bridge to domain-controller standard
Purpose: make the highest-value hybrid assets as hard to compromise as a DC.
Tier-zero hardening checklist
# SYNC ACCOUNT (Connect Sync's on-prem AD DS connector account, e.g. MSOL_...): # - Treat as tier zero. It has Replicate Directory Changes rights (DCSync). # - Ensure a long, random password; rotate on any staff change. # - Do not use it for anything else, and never interactively log on with it. # - Cloud Sync avoids this by using a gMSA, prefer that where possible. # # SYNC SERVER: # - Dedicated, hardened host. No email, no browsing, no other applications. # - Administer only from a Privileged Access Workstation (PAW). # - Restrict interactive and network logon to named tier-zero admins via # Group Policy (Deny log on locally / through RDP for all others). # - Patch aggressively, enable full audit logging, ship logs off-box. # - Place in a tier-zero OU with a restrictive GPO baseline. # # CLOUD SIDE: # - The Entra 'Directory Synchronization Accounts' role is used by the # connector. Do not add members, and alert on any change to it. # - Enable Microsoft Entra Connect Health to monitor sync and agent health.
CRITICAL
A common and fatal mistake is running Entra Connect on a general-purpose server that also does other jobs, or letting ordinary server admins log on to it. Anyone who can run code on the sync server can, in effect, DCSync the domain and manipulate the cloud directory. Isolate it as ruthlessly as you isolate a domain controller.
Phase D - Close the token-forgery paths
REAL WORLD ANALOGYThe Seamless SSO key is a shared padlock code that many past staff once learned, so you change it on a schedule whether or not you suspect anyone. The AD FS signing key is worse: it is the company seal, and whoever holds it can stamp any letter as official, a forged pass for any employee, bypassing every front-door check. That is why the plan is to retire the seal entirely, or lock it in a hardware safe and watch it.
4Rotate the Seamless SSO Kerberos decryption key
Purpose: remove a persistent Silver Ticket forgery path created by a never-rotated shared key.
Context: Seamless SSO creates a computer account named AZUREADSSOACC in AD. Its Kerberos decryption key should be rotated regularly (Microsoft advises at least every 30 days), because a leaked key allows forging Kerberos tickets for Seamless SSO.
Rotate the AZUREADSSOACC key (on the Entra Connect server)
# Run on the Entra Connect server, in an elevated PowerShell session. Import-Module 'C:\Program Files\Microsoft Azure Active Directory Connect\AzureADSSO.psd1' # Authenticate to Entra as a Hybrid Identity Administrator. New-AzureADSSOAuthenticationContext # Confirm Seamless SSO status and which forests are enabled. Get-AzureADSSOStatus | ConvertFrom-Json # Provide on-prem domain admin credentials, then roll the key. $onPremCred = Get-Credential Update-AzureADSSOForest -OnPremCredentials $onPremCred # This resets the AZUREADSSOACC Kerberos decryption key. Schedule it (<= 30 days).
VERIFICATION
Get-AzureADSSOStatus shows Seamless SSO enabled for the forest, and the rotation completes without error. In production, put this on a recurring, monitored schedule, an unrotated key is a standing risk.
5Plan the migration off AD FS to cloud authentication
Purpose: remove the Golden SAML risk by retiring federation where it is not required.
AD FS to managed (cloud) authentication approach
# AD FS holds a token-signing key that can forge tokens for any user # (Golden SAML). Unless a specific requirement demands federation, migrate # federated domains to cloud authentication (PHS or PTA + Seamless SSO). # # Staged approach (Entra Connect supports a controlled cutover): # 1. Enable Password Hash Sync (Phase B) as the target sign-in method. # 2. Use the 'staged rollout' feature to move pilot groups to cloud auth # while the domain is still federated, validating sign-in. # 3. Convert the domain from federated to managed once validated. # 4. Decommission the AD FS farm and protect any remaining token-signing keys # in an HSM until then. # # If AD FS must remain, deploy Microsoft Defender for Identity sensors on the # AD FS servers (Lab 10) to detect token-signing abuse.
PRODUCTION CONSIDERATION
Federation is not wrong by default, some organisations need it. But every federated domain is a token-forgery surface, so the default posture should be cloud authentication, with federation retained only where a concrete requirement justifies protecting and monitoring the AD FS key material to a very high standard.
Testing and Validation
- Posture read: run Phase A, confirm you can state sync, PHS, writeback and federation status factually.
- PHS confirmation: in a hybrid tenant, confirm
PasswordHashSyncreads true after enabling it. - SSO key rotation: on a lab domain, run the rotation and confirm it completes and Seamless SSO still works.
- Federation check: confirm which domains are federated, and that your migration plan targets each one.
- Server isolation: verify that only tier-zero admins can log on to the sync server.
| Symptom | Cause | Resolution |
|---|---|---|
Get-MgDirectoryOnPremiseSynchronization returns nothing | Tenant is cloud-only | Expected, no on-prem sync configured |
| PHS still false after enabling | Wizard change not applied, or replication delay | Re-run the sign-in configuration and force a sync cycle |
| SSO rotation fails | Wrong module path or insufficient rights | Import AzureADSSO.psd1 from the Connect install path, use domain admin plus Hybrid Identity Admin |
| Users cannot sign in after AD FS cutover | PHS not enabled before conversion | Enable and verify PHS, use staged rollout before converting the domain |
Security Analysis
The hybrid attack paths, named
- DCSync via the sync account: its directory-replication rights let a compromised sync account or server extract all domain hashes. Mitigation: tier-zero isolation, gMSA via Cloud Sync, monitoring.
- Silver Ticket via AZUREADSSOACC: a never-rotated Seamless SSO Kerberos key enables ticket forgery. Mitigation: rotate the key on a schedule.
- Golden SAML via AD FS: a stolen token-signing key forges tokens for any user, bypassing cloud MFA. Mitigation: migrate off AD FS, or protect keys in an HSM and monitor with Defender for Identity.
What makes this sound
- Tier-zero treatment: the sync server and account are protected to domain-controller standard, matching their real blast radius.
- Smaller surface: Cloud Sync with a gMSA and retiring AD FS remove two of the most dangerous components entirely.
- Defence in depth: PHS both improves resilience and feeds cloud detection.
Production hardening
- Alert on any membership change to the Directory Synchronization Accounts role and on any interactive logon to the sync server.
- Deploy Defender for Identity sensors on domain controllers, AD CS, AD FS and the Connect server (Lab 10).
- Schedule and monitor Seamless SSO key rotation, and track AD FS decommissioning to completion.
Cleanup Instructions
INFO: mostly assessment
The tenant-side steps here are read-only and leave nothing to clean up. On a lab domain, the SSO key rotation is a legitimate operation to keep, not to reverse.
Disconnect the Graph session
Disconnect-MgGraph
Recommended Learning Links
Key Takeaways and Next Lab
- The sync server and sync account are tier-zero assets, treat them like domain controllers.
- Cloud Sync with a gMSA and retiring AD FS shrink the hybrid attack surface materially.
- Password Hash Sync improves resilience and enables cloud leaked-credential detection.
- Rotate the Seamless SSO Kerberos key and remove AD FS token-forgery paths.
Next
Lab 10 - Detection: Microsoft Defender for Identity and Identity Protection
You turn the leaked-credential signal PHS enables into risk-based Conditional Access, then deploy Defender for Identity sensors that watch the very on-premises components you hardened here, detecting DCSync, Golden Ticket and the token abuse this lab set out to prevent.
Identity Bytes // IB-ENTRA-SEC Track // Lab 09 of 12. British English. For lab and training use against a disposable tenant only.