Changing AAD after domain migration
Looking for some guidance on reconfiguring our Azure AD connect tool. Some background: We recently underwent a domain migration where we moved from older 2012 AD boxes to newer 2019 boxes. Internally our domain has changed from an .edu domain to a .local domain, however externally everything remains the same. We’ve migrated all our users and groups using ADMT, and their attribute did NOT change, they retain the same samaccountname, UPNs, email addresses, mS-DS-ConsistencyGuid, etc. If I try to reinstall the AAD tool using the exported settings it pulls the old .edu domain as that is what it’s set to sync, when we’d like it to pull from our .local AD servers now instead. When I run through the Customize Sync Options wizard I can add the .local forest to the connected directories option (if I use the /skipLDAP command), and it allows me to go through the wizard with no issue. Before I continue with this process, I figure I’d see if I could get some questions answered: Our anchor is mS-DS-ConsistencyGuid, and they are the same on both domains, so if I go ahead and connect the .local forest, will it still create a new account still or will it simply make the connection with the current 365 account/mailbox? (Mailboxes/Exchange are in 365, we do not use on-prem exchange.) Would it be easier to just completely uninstall the Azure AD tool, and re-install it without importing the exported settings? The only reason I’m hesitant to do this is because I’m not all 100% sure on what settings are configured, other than what is shown to me on the View or Export Config settings page. Thanks!Cross-tenant synchronization (Private mode)
Cross-tenant synchronization enables you to automate provisioning identities across tenants in your organization and simplify collaboration within your organization. In addition, automate removing accounts when users don't need access and keep accounts synchronized across tenants. This feature will not appear on all tenants until Microsoft releases it as preview.Hybrid Join Lifecycle Model
Microsoft Entra hybrid join is still a common reality in enterprise environments. For many organizations, it remains necessary because legacy applications still rely on Active Directory machine authentication, Group Policy is still in use, and on-premises operational dependencies have not fully been retired. At the same time, the long-term direction for endpoint identity is increasingly cloud-native. That creates an important architectural question: Should hybrid join be treated as a permanent device state, or as a lifecycle stage in a broader modernization journey? In practice, hybrid join is often discussed as a binary condition: the device is either hybrid joined or it is not. But from an operational perspective, that view is too limited. In real enterprise environments, hybrid join behaves much more like a lifecycle. A device moves through provisioning, registration, trust establishment, management attachment, steady-state operation, recovery, retirement, and eventually transition. That distinction matters because most hybrid join issues do not fail loudly. They usually appear as stale objects, pending registrations, broken trust, inconsistent management ownership, and environments that remain temporarily hybrid far longer than intended. Why a lifecycle model is useful Treating hybrid join as a lifecycle helps explain why so many organizations struggle with it even when the initial implementation appears technically correct. The challenge is usually not the first successful join. The challenge is everything that happens around it: Provisioning quality Trust validation Management ownership Drift detection Stale object cleanup Exit criteria for transition to Entra join Without that lifecycle view, hybrid join often becomes a static design decision with no clear operational model behind it. The eight phases 1. Provisioning The lifecycle starts when the device is built, imaged, or provisioned. This stage is more important than it looks. If the device is provisioned from a contaminated image, or if cloning and snapshot practices are not handled carefully, later identity issues are often inherited rather than newly created. Provisioning should be treated as an identity-controlled event, not just an OS deployment task. 2. Registration The device becomes known to Microsoft Entra. This is where many environments confuse visibility with readiness. A device object may exist in the cloud, but that does not automatically mean the hybrid identity state is healthy or operationally usable. 3. Trust Establishment This is the point where hybrid join becomes real. A device should not be considered fully onboarded until both sides of trust are present and healthy. In operational terms, this means the device is not only registered, but also capable of supporting the expected sign-in and identity flows. 4. Management Attachment Once trust exists, governance becomes the next question. Many organizations still balance Group Policy, Configuration Manager, Intune, and legacy application dependencies at the same time. That is exactly why hybrid join often persists. But if management ownership is not clearly defined, organizations end up with overlapping policy planes, inconsistent control, and unclear accountability. 5. Operational Steady State Hybrid join does not stop at successful registration. The device must remain healthy over time, and that means monitoring trust health, registration state, token health, line-of-sight to required infrastructure, and management consistency. A device that was healthy once is not necessarily healthy now. 6. Recovery Every real environment eventually encounters drift. Pending states, broken trust, orphaned records, reimaged devices, and inconsistent registration scenarios should not be treated as unusual edge cases. They should be expected and handled with formal recovery playbooks. Recovery is not an exception to the lifecycle. It is part of the lifecycle. 7. Retirement Retirement is one of the weakest areas in many hybrid environments. Devices are replaced or decommissioned, but their identity records often remain behind. That leads to stale objects, inventory noise, and administrative confusion. A proper lifecycle model should include a controlled retirement sequence rather than ad hoc cleanup. 8. Transition This is the most important strategic phase. The key question is no longer whether a device can remain hybrid joined, but whether there is still a justified reason to keep it there. Hybrid join may still be necessary in many environments today, but in many cases it should be treated as transitional architecture rather than the target end state. Practical takeaway Looking at hybrid join as a lifecycle creates a more useful framework for architecture decisions, operational ownership, troubleshooting, directory hygiene, governance, and transition planning toward Microsoft Entra join. That is the real value of this model. It does not replace technical implementation guidance, but it helps organizations think more clearly about why hybrid join exists, how it should be operated, and when it should eventually be retired. Final thought Hybrid join is still relevant in many enterprise environments, but it should not automatically be treated as a default destination. In many cases, it works best when it is managed as a lifecycle-driven operating model with defined phases, controls, and exit criteria. That makes it easier to stabilize operations today, while also creating a clearer path toward a more cloud-native endpoint identity model tomorrow. Full article: https://www.modernendpoint.tech/hybrid-join-lifecycle-modelDisplay On-prem Password Policy on SSPR Page
Hi All We are beginning to rollout SSPR with on-prem writeback. So far so good. Is there a way we can display our on-prem password policy requirements on the SSPR screen? I have seen the MS docs, but can't really make any sense of them so any help would be greatly appreciated. SKJoin Merill Fernando and other guests for our Identity and Network Practitioner Webinar Series!
This October, we’re hosting a three-part webinar series led by expert Merill Fernando for Identity and Network Access practitioners. Join us as we journey from high-level strategy to hands-on implementation, unifying identity and network access every step of the way. Each session builds on the last, helping you move from understanding why a unified approach matters to what are the foundations to get started, and finally to how to configure in practice. The goal is to equip you with actionable skills, expert insights, and resources to secure your organization in a unified, Zero Trust way. Register below: Identity and Network Security Practitioner Webinar Series | Microsoft Community HubMigration to Cloud Sync (passwords)
We want to migrate from AAD Connect Sync to Cloud Sync. When provisioning new users we could use temporarily passwords in AAD Connect Sync, through this feature: Set-ADSyncAADCompanyFeature -ForcePasswordChangeOnLogOn $true Is this feature still available in Cloud Sync? If not what is the workaround?
Implementing Azure ADConnect in a live environment
I have been tasked with implementing Azure ADConnect for my company. We currently have 2 locally virtualized domain controllers and are already utilizing Office365 for mail. What would be the easiest way to implement ADConnect while having the least amount of downtime/user interruptions.Double entries in userCertificate avoids Hybrid Join
Hey guys, I have an interesting situation at a customer. He utilizes a third party MFA provider while being on a federation. That means new computers never will have a registered state. For users it is mandatory that theirs clients have fulfilled the Hybrid Join to use M365 apps, what can be a real pain. So the Automatic-Device-Join task has to create the userCertificate on the OnPremises computer object, before it can be synchronized to Entra. Here comes the issue. In some cases we see that some computers will create two userCertificate entries. This situation will lead to an inconstistent Hybrid Join. I already tried to remove one of the certificates, but for me it is impossible to recognize which is the right one. Only solution for me was to remove both entries under userCertificate and let the Automatic-Device-Join task create a new one. Afterwards the Hybrid Join will work. I want to understand, which process or scenario might create the double userCertificate entries?
