Microsoft 365 & Copilot in the Enterprise · Chapter 2 of 12
Identity — the spine everything else hangs on
Directory sync, the three ways to authenticate, conditional access, and precisely which licence tier unlocks what.
Most enterprises already have an on-premises Active Directory — the directory that has held Windows user accounts since 2000 — and are not about to throw it away. So the first real engineering decision is how those accounts reach the cloud.
Getting accounts into the cloud
Two tools do this, and Microsoft's recommendation has changed, so older guidance misleads.
| Entra Connect Sync (older) | Entra Cloud Sync (recommended) | |
|---|---|---|
| Where it runs | A server you maintain | Microsoft's cloud, with a lightweight agent |
| Disconnected AD forests | No | Yes — named by Microsoft for mergers without forest consolidation |
| Multiple agents / failover | No — a single point of failure | Yes |
| Scale | Unlimited per domain | 150,000 objects; groups capped at 50,000 members |
| Hybrid device join | Yes | No — use Cloud Kerberos Trust instead |
| Cross-forest attribute merge | Yes | No |
Microsoft's stated position: new identity and synchronisation features are being developed primarily on the Cloud Sync platform, making it the recommended path forward for most organisations. Connect Sync has no announced retirement date — Microsoft says only that it retires once Cloud Sync reaches full parity.
A live deadline as this is written. Every customer must be on Entra Connect Sync version 2.5.79.0 or later by 30 September 2026, or, in Microsoft's own words, all synchronisation services in Connect Sync will fail.
If you inherit an estate, checking that version number is a five-minute task that can save you an outage.
Where the password is actually checked
- Password hash synchronisation (PHS). A cryptographic hash of the password — not the password — is synced to the cloud, and Microsoft checks sign-ins itself. Nothing on your premises has to be reachable for people to log in.
- Pass-through authentication (PTA). The password is never synced; an agent on your network validates each sign-in against your Active Directory in real time.
- Federation (AD FS). Sign-ins are redirected to your own Active Directory Federation Services servers, which issue the token. The most control, and by a wide margin the most infrastructure to run.
Microsoft's current recommendation is unusually direct: use or enable password hash synchronisation with whichever authentication method you choose. Its stated reasoning is worth repeating because it is an operational argument rather than a product one:
Why Microsoft pushes password hash sync so hard
Both pass-through authentication and federation depend on infrastructure on your premises that can fail. Password hash sync does not.
The ransomware case, in Microsoft's own framing: organisations that had hash sync configured as a standby recovered cloud access in a matter of hours. Organisations without it took weeks.
Leaked-credential detection requires hash sync regardless of your primary method.
Federation is positioned as the exception now — justified by an existing AD FS investment or a third-party multi-factor product that needs it, not as a default.
Note that the sync choice and the authentication choice are independent. You can run Cloud Sync with federation, or Connect Sync with hash sync. People conflate them constantly.
Conditional Access — the policy engine that does the real work
Conditional Access evaluates every sign-in against rules you write: if this user, from this location, on this device, reaching this application, then allow, block, or require multi-factor authentication. It is the mechanism behind essentially every modern security control in the estate, and it is the single capability most worth understanding in this chapter.
It requires Entra ID P1. Risk-based policies — ones that react to a sign-in Microsoft's models think is suspicious — require P2, because they depend on Identity Protection. Tenants with neither get Security Defaults, free, which is tenant-wide multi-factor plus a block on legacy authentication, with no granular targeting at all.
Multi-factor authentication is now mandatory, on a published schedule
| Phase | What it covers | Enforced from | Deferrable to |
|---|---|---|---|
| 1 | Azure portal, Entra admin centre, Intune admin centre | Rolling out from Oct 2024 | — |
| 1 | Microsoft 365 admin centre | Feb 2025 | 30 Sep 2025 |
| 2 | Azure CLI, PowerShell, mobile app, infrastructure-as-code tools, and the REST API (the web interface your automation calls) — create/update/delete only, not read | 1 Oct 2025 | 1 Jul 2026 |
There is no opt-out, only postponement by a Global Administrator. Workload identities — managed identities and service principals, the accounts your automation uses — are out of scope for both phases. It applies to the public Azure cloud only, not government or sovereign clouds, and guest users are in scope.
What each licence tier actually unlocks
| Capability | Free | P1 | P2 |
|---|---|---|---|
| Conditional Access | — | ✓ | ✓ |
| Risk-based Conditional Access | — | — | ✓ |
| Self-service password reset, cloud users | ✓ | ✓ | ✓ |
| Password reset written back to on-prem AD | — | ✓ | ✓ |
| Application Proxy, custom roles, Connect Health | — | ✓ | ✓ |
| Identity Protection (risky sign-in and leaked-credential alerts) | — | — | ✓ |
| Privileged Identity Management — time-limited admin rights | — | — | ✓ |
| Access Reviews, Entitlement Management | — | — | ✓ |
Standalone prices as observed in August 2026: P1 at $7.00 and P2 at $10.00 per user per month. P1 is included in Microsoft 365 E3, E5, E7, F1, F3 and Business Premium; P2 in E5 and E7. The practical consequence: P2-only features — time-limited admin rights, access reviews, risk-based policies — are the most common reason an organisation on E3 finds it needs to buy something extra.
Check yourself