Sync scope and filtering
Confirm which organizational units, groups, and attributes are actually in scope, and whether an old filtering rule quietly excludes or exposes accounts it shouldn’t.
Independent IT security review
Confirm what actually decides who can sign in to Microsoft 365.
Cloud identity still depends on on-premises infrastructure for many organizations. The review reads Azure AD Connect sync rules, domain controllers, and the servers or VMs behind them as part of the sign-in path-not as someone else’s problem.
- Before any access
- Written question and scope
- Agreed evidence method
- No automatic tenant changes
Read sync rules as identity policy, not background plumbing.
Azure AD Connect’s filtering, attribute flow, and authentication method decide which on-premises accounts reach Microsoft 365 and how they prove who they are. A default install made years ago is still making that decision today.
Authentication method choice
Distinguish password hash synchronization, pass-through authentication, and federation, since each changes what happens to sign-in if an on-premises component fails.
Writeback and attribute flow
Review password writeback and attribute flow direction so a change made in one direction does not silently overwrite an intended value in the other.
Trace the on-premises chain before trusting the cloud identity.
Domain controllers and the Azure AD Connect server itself sit upstream of every hybrid sign-in. If that layer is fragile, the cloud identity built on top of it is fragile too-regardless of how well Conditional Access is configured.
Domain controller health
Check patch level, replication health, and time synchronization, since authentication errors upstream can appear as a Microsoft 365 sign-in problem.
Single point of failure
Confirm whether a single Azure AD Connect server is the only path for sync and password writeback, and what happens to new sign-ins while it is down.
Staging server and high availability
Review whether a staging server exists and is actually tested, rather than installed once and never promoted or verified.
Connect virtualization and recovery evidence to sign-in risk.
When domain controllers and the Azure AD Connect server run as virtual machines, the hypervisor’s health, backup coverage, and recovery time become part of the identity conversation-not a separate infrastructure topic.
Hypervisor dependency
Identify which host or cluster the identity-critical VMs run on, and whether that host has its own single point of failure.
Backup evidence for identity infrastructure
Confirm domain controllers and the Azure AD Connect server are actually included in backup scope, not assumed to be covered by a general server backup job.
Recovery time versus business tolerance
Compare how long a domain controller or sync server would realistically take to restore against how long the organization can operate without new Microsoft 365 sign-ins.
Decide what a hybrid-identity finding actually changes.
A finding in this area can point to a sync-rule fix, a domain controller or hypervisor remediation, or a longer conversation about moving toward cloud-only identity. Each has a different owner and a different timeline.
Sync fix versus infrastructure fix
Separate a configuration change inside Azure AD Connect from a server, hypervisor, or backup change that requires its own change window.
The cloud-only option
Where dependency on on-premises infrastructure is itself the finding, document what a move toward cloud-only identity would require and what it would remove.
Sequencing with other identity findings
Coordinate hybrid-infrastructure remediation with any Conditional Access or privileged-role changes already planned, since both touch the same sign-in path.
Next step
Define the review before sharing evidence.
Start with the trigger, decision, and known boundaries. Do not send passwords, recovery codes, or tenant exports.