JUMP TO SECTIONChoose a lesson section
Follow the trust boundary.
Every modern Windows support ticket becomes easier once you know which system owns the identity, the policy and the resource.
AD DS and Entra ID work together—but they aren't the same directory.
Traditional Active Directory Domain Services (AD DS) manages Windows domain identities, machine accounts, GPO and Kerberos services. Microsoft Entra ID is a cloud directory and identity platform for modern apps. Hybrid identity connects selected objects across them; it doesn't merge their protocols into one authentication service.
Active Directory Domain Services
Northstar's existing on-premises directory stores domain users, security groups, computers and GPO-linked organizational structure. Domain controllers provide AD-integrated DNS, LDAP directory services and Kerberos authentication.
An AD DS object does not automatically exist in Microsoft Entra ID.Microsoft Entra ID
The cloud identity plane used for Microsoft 365 and many modern applications. Synced identities are represented here, while cloud-only users remain possible. Application authorization, Conditional Access and MFA are additional layers.
A successful Entra sign-in doesn't prove access to an on-premises SMB file share.Directory synchronization
A configured synchronization engine projects in-scope identities and selected attributes into Entra. Northstar's example uses Entra Connect Sync; Cloud Sync is another deployment option with different supported features and architecture.
Directory synchronization is not the same as authenticating a user.Windows authentication
Domain-joined computers can discover domain controllers and obtain Kerberos tickets for correctly configured on-premises services. Name resolution, reachable DCs, time and resource permissions matter.
A Windows sign-in or Kerberos ticket is not blanket authorization to every file share.For a user sourced from AD DS, many synchronized attributes and group memberships should be corrected at the authoritative on-premises source. For cloud-only accounts, the cloud directory can be authoritative. Don't fix missing synchronization by casually creating a duplicate cloud identity or disabling tenant-wide synchronization.
Connect Sync, Cloud Sync and the limits of a sync cycle.
Northstar's fictional environment uses Microsoft Entra Connect Sync to synchronize selected AD identities. Microsoft Entra Cloud Sync offers a separate, cloud-managed architecture with on-premises provisioning agents. Both can provision objects and synchronize passwords in supported scenarios, but their feature coverage, topologies and migration requirements differ. Compare the current Microsoft decision guide before choosing or migrating.
Entra Connect Sync
A synchronization engine with configured directory connectors, rules and OU filtering. Investigate its operation, source objects, synchronization scope and resulting cloud records.
Entra Cloud Sync
Uses provisioning agents and cloud-managed configuration. Supports several hybrid scenarios, but it isn't merely a different button for every Connect Sync feature.
For Jordan Reyes, an existing on-premises user in OU=Operations-Archive, the approved synchronization selection excludes that OU. The AD account can be healthy and still never appear in Entra. The right action is to understand source, scope and logs first—not assign licenses or reset a password in an unrelated cloud identity.
Hybrid synchronization triage
Work through three decisions. Review the available evidence, choose an action, and explain why it is safer than the alternatives. Fictional environment; no live tenant access.
The first password-hash cycle reports an error.
- Northstar enabled Cloud Sync for a small AD DS pilot group.
- The cloud provisioning log still shows the employee as not created.
- Initial password hash sync reports that no matching Entra user exists.
What do you investigate before changing authentication?
What actually validates a cloud password?
The synchronized object is an identity representation. The organization's configured authentication method determines how a password-based Entra sign-in is validated. It is independent from how a normal Windows Kerberos service ticket is issued for an on-premises file server.
Password Hash Synchronization
A derived, further-processed password hash is synchronized from AD DS to Entra. The on-premises AD password isn't transmitted in plaintext. Cloud authentication typically does not need a live domain controller at the moment of sign-in.
The cloud credential must be current, and Conditional Access/MFA still apply.Pass-through Authentication
Entra receives the sign-in request and securely works with an on-premises PTA agent to validate the password. Agent availability and the on-premises domain matter at authentication time.
PTA configuration is not the same thing as Cloud Sync provisioning.Federation
Entra redirects or delegates authentication to a trusted federated identity provider, often AD FS in traditional deployments. The provider's infrastructure and policies affect sign-in.
Do not assume all hybrid organizations use federation or that it is required for Entra hybrid join.Microsoft synchronizes a further-processed, derived hash—not plaintext passwords. Entra can validate cloud sign-ins when the configured method is PHS; other sign-in paths have different infrastructure dependencies. MFA and Conditional Access remain separate decisions.
Same employee. Different request paths.
Choose a workflow below to trace directory synchronization, cloud sign-in, domain file access, or a Windows Hello for Business hybrid trust scenario. Notice where the path depends on a synchronized object, an authentication service or direct domain-controller connectivity.
Directory synchronization
Jordan Reyes is an on-premises account. Northstar's Connect Sync engine projects in-scope directory objects into Entra, after examining filtering, mapping and provisioning results.
- 01AD DSAuthoritative Jordan Reyes user + approved source group
- 02Scope and sync serviceOU and attribute filters, Connect Sync connectivity and export results
- 03Microsoft Entra IDSynchronized representation of Jordan and supported group membership
- 04Cloud applicationLicense/assignment, permissions and Conditional Access still apply
A successful synchronization cycle alone is not a guarantee of app entitlement or an accepted login.
DNS, time and Kerberos turn a UNC path into a working file share.
Northstar's older workstation OPS-LT022 is joined to AD DS and hybrid joined with Entra. When the user connects to a protected SMB share on FS01, Windows may need to discover a domain controller, acquire an appropriate Kerberos ticket-granting ticket and service ticket, and present that ticket to the file server. Share and NTFS permissions still decide authorization.
AD-aware DNS is essential. A public DNS resolver generally won't have Northstar's private AD domain SRV records. And Kerberos tickets rely on time: the default Windows Kerberos clock-skew tolerance is commonly five minutes. We deliberately model both an incorrect resolver and nine-minute skew in Practice 011. Fixing one without checking the other won't restore the workflow.
Service principal names (SPNs), DNS resolution, network reachability and account rights also matter. A valid ticket doesn't make someone a file-share owner. Avoid deleting ticket caches, changing SPNs, or modifying domain time settings without evidence and authorization.
Cloud Kerberos trust is a bridge—not a replacement for Active Directory.
Windows Hello for Business (WHfB) can use device-bound credentials for sign-in. For hybrid organizations, Microsoft's current deployment guidance describes cloud Kerberos trust, key trust and certificate trust. Which model fits depends on prerequisites and the need for certificates.
Cloud Kerberos trust
Uses Entra Kerberos infrastructure to help establish on-premises access without user certificate deployment for this trust model. On-premises DCs still issue service tickets and evaluate domain authorization.
Key trust
Uses the user's enrolled key, with required domain-side trust and certificate prerequisites for domain controller validation.
Certificate trust
Uses user sign-in certificates, with enterprise PKI infrastructure and associated management complexity.
Cloud Kerberos trust requires a supported Windows/domain environment, the Microsoft Entra Kerberos setup, configured WHfB policy, and domain controller line of sight for on-premises protected resources. A client may sign into Windows but still be unable to reach an internal file server when off the corporate network. Cloud Kerberos trust is not an unconditional offline replacement for an on-premises KDC.
In Microsoft's hybrid WHfB guidance, a configured certificate-trust policy can take precedence over cloud Kerberos trust. Know which policy is actually applying before troubleshooting a seemingly ignored cloud-trust setting.
Intune manages one plane; Group Policy can still control another.
Group Policy uses AD DS structure, linked/scoped GPOs, SYSVOL contents and client processing. Intune deploys cloud-managed policies to enrolled devices. On a hybrid-managed device, both can exist; their targeting and policy conflicts must be evaluated rather than assuming one silently replaces the other.
Northstar has an authorized GPO that maps an OPS file share. The setting won't apply if the client can't locate a domain controller, read SYSVOL, authenticate correctly, or match the GPO's link/security filtering. Start with gpresult and the Group Policy operational log. A blind gpupdate /force doesn't repair DNS or time.
Account missing from Entra
Symptom: AD DS object exists but Entra user search returns no matching account.
Next evidence: Verify source OU scope, connector status, filtering, provisioning logs and the object's UPN/source anchor. Confirm an actual completed cycle before changing tenant-wide settings.
Cloud sign-in fails after password change
Symptom: On-premises sign-in accepts the new password; cloud sign-in does not.
Next evidence: Determine PHS, PTA or federation first. For PHS, inspect password-sync health; for PTA/federation, inspect the associated agent or identity provider path. Cached sessions can complicate tests.
Domain sign-in succeeds, file share fails
Symptom: A Windows session exists but access to a UNC file path is denied or unavailable.
Next evidence: Separate name resolution, DC reachability, tickets/SPN, SMB connectivity and ACL authorization. Access Denied and cannot find server are different clues.
GPO not applied
Symptom: Expected drive mapping or machine setting is missing.
Next evidence: Run gpresult, review GPO scope/filters and links, then event logs and SYSVOL reachability. A successful refresh cannot repair an absent policy link.
Ask the right question before you change a setting.
These commands help observe what Windows, AD DS and synchronization tools report. Most are read-only; availability, permissions and output context depend on the endpoint and installed modules.
Get-ADUser -Identity jreyes -Properties UserPrincipalName,DistinguishedNameInspect an AD-sourced user's attributes and OU (requires appropriate RSAT tooling and rights).
Get-ADGroupMember -Identity 'NS-Inventory-Users'Check the authoritative source group's membership before assuming cloud assignment.
Get-ADSyncSchedulerInspect Connect Sync scheduler configuration on a Connect Sync server. This command doesn't invoke synchronization.
dsregcmd /statusInspect Windows join and registration evidence; run in the correct device/user context.
ipconfig /allReview the DNS server addresses actually configured on the endpoint.
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.northstar.internalLook for AD domain-controller locator records in Northstar's fictional internal namespace.
nltest /dsgetdc:northstar.internalTest domain controller discovery and learn which DC the client locates.
w32tm /query /statusRead Windows time-service status; check time source and offset.
klistInspect Kerberos tickets for the current logon session; use ticket details carefully.
gpresult /rSee applied/filtered Group Policy information for the current context.
gpresult /h gp-report.htmlProduce a detailed resultant-policy report in a file for analysis.
Never disable synchronization tenant-wide, bypass MFA, force an unsupported authentication fallback, or broadly relax group and share access because one user or computer fails. Investigate the authoritative source and exact failing layer.
Verify the design before implementing it.
Northstar Services and all hostnames are fictional. The simulator models dependencies—not real directory, password, ticket or policy processing. Consult current Microsoft documentation and your organization's approved change controls.
