Hybrid Identity in 2026: Entra Connect Sync vs Cloud Sync and When to Move

M365 FM - Hybrid Identity in 2026 - Entra Connect Sync vs Cloud Sync and When to Move 00:00:00 Speaker: Hybrid identity feels finished. You set it up years ago. Users sign in, mail flows. Nobody complains. But in reality, that quiet setup decides almost everything who can get in, what they can reach and what happens to your business. The day one server stops answering. Here's the thesis in twenty twenty six, the real question is not which sync tool you run, it's who holds the source of authority. So we'll go through it in order. The two sync engines, the three sign in methods, source of authority, migration resilience, and retiring ADFs. If you want the next identity decision to land on your terms, subscribe. Because the worst time to learn about your sync server is when it's already dead. But before the tools you need, the model behind them. Sponsor segment educational placement after intro. A quick note before we go on. Most tenant moves don't start with mailboxes. They start with identity duplicate addresses, odd UPN's accounts nobody owns. If that mess comes along for the ride, it follows you into the new tenant and breaks things there. So cleanup comes first. Always. Once identity is clean, the mailbox move becomes a technical job instead of a guessing game. That's where tools like stellar Migrator for exchange come in. It's one of the tools admins use in Microsoft migrations, and it fits that second step well. It won't fix a broken identity model though. That part is on us. So let's get back to the core problem. The model behind hybrid identity hybrid identity was built for a specific world active directory sat in the center. Everything else orbited it file servers, print queues, line of business apps, and then a little later, the cloud showed up. The cloud was a guest. That's the old model. The on premises directory is the only truth. Entry ID is a copy, a useful copy, a convenient copy, but still a copy. And that assumption has a cost. If a D is the only truth, every cloud decision has to wait for it a new hire, create the account on premises, then wait for sync a group change on premises. First a disabled user on premises, then wait. The cloud can't act on its own because it was never given the authority to you. Feel it in small ways. A thirty minute delay here. A ticket for an attribute there. A sync error that blocks one user for two days because nobody watches the logs, none of it looks like a design flaw. It looks like normal operations. That's the problem because in twenty twenty six, the center has moved. Think about where work starts. Now a person opens teams. A conditional access policy decides if they get in. An app asks enter ID for a token. Copilot reads from the Microsoft Graph using permissions enter ID grants. Not one of those steps starts at a domain controller. They all start from entry ID, so the cloud isn't a guest anymore. It's where access decisions get made. But the data those decisions rely on still comes from a directory that was designed for a different job. And that's the gap. Now here's where this episode takes a position. I think the answer comes down to three moves. First, reduce your on premises dependency not to zero in one weekend, but steadily. Every server that sits between a user and a cloud sign in is a server that can fail. Second, move authority on purpose. Don't let it stay on premises just because it started there. Decide object by object where the truth should live. Third, retire the legacy authentication paths. The Federation farms. The proxy servers, the certificates that expire on a Sunday notice what's not on that list? It doesn't say pick the right sync tool. The tool matters will spend a lot of time on it, but the tool is an implementation detail of the model, and the model is what's holding you back. Swap one sync engine for another and change nothing else. You've moved the same dependency to a new box. Same authority, same single point of failure. Same. Wait, that's a migration. It isn't a shift. A real shift starts with understanding what's actually moving between the two directories. So that's where we begin with what actually syncs. What actually happens between a D and entry ID? Start with the basics. Active directory holds objects. A user is an object. A group is an object. A computer is an object. Each one carries attributes which are just named values. Display name. Department manager. The list of email addresses. The sign in name sync copies those objects and attributes to entry ID, but it doesn't copy them straight across. Inside the sync engine, there's a holding area usually called the connector space. Think of it as a staging shelf. For each directory, objects land there first, then rules decide what gets matched, what gets changed on the way, and what gets sent on. That's the whole mechanism. Read stage, apply rules. Write the rules matter more than the copying. Which organizational units are in scope, which attributes flow, which ones get rewritten, one bad filter and a whole department vanishes from the cloud and nothing looks broken on the on premises side. Now what actually flows users? Yes, that's the big one. Groups. Yes. With their members contacts. Yes, devices are a bit different. Hybrid joint computers register and enter ID through a separate process and the sync engine plays a supporting role there. So when someone says we sync our devices, what they usually mean is something more tangled than that. What doesn't flow plenty. Group policy doesn't. Local passwords in the clear don't. Organizational structure doesn't. Not as a hierarchy. Entry ID has no real concept of ous. There a filter on the way in. Then they disappear next direction out of the box. Sync runs one way on premises to cloud Addy is the author. Entry ID is the reader a change made in the cloud to a single user. Say a new job title gets overwritten on the next cycle or blocked outright. That surprises people. They edit a synced user in the admin center. It looks fine for a while and then it snaps back. There are exceptions. Limited writeback exists for a few things. Password changes can flow back if you turn it on. Some group and device data can come back to depending on the engine. But these are narrow paths. They're not a second direction of sync. They're special cases, each with its own prerequisites and its own ways to fail. So the default stays the same. One way on premises owns the data. Now, here's the idea I want you to hold on to for the rest of this episode. Sync is not signed and those two things get blended together constantly. People say our sync is down when they mean users can't log in, or we use connect when they mean passwords are checked on premises. There are different jobs done by different parts of the system and they can fail on their own. Sync moves, identity data names, groups. Addresses the facts about a person sign in proves that the person is who they claim to be right now, with a password or a key, you can have one without the other running through the same machine. You can change one and leave the other alone. Once you separate them, the whole topic gets cleaner because there are really three layers and each one needs its own decision. Layer one is identity data. What gets copied and by which engine. That's the sync tool. Question layer two is the authentication method where the password gets checked. That's password hash sync pass through or Federation. Layer three is authority. Which directory is allowed to say what's true about an object and who gets to change it. Most teams only ever make the first decision on purpose. The second one gets made in a hurry years ago by someone who has since left. The third one never gets made at all. It just defaults to wherever the data started. That's what we're going to fix one layer at a time. So let's begin with layer one. The older of the two sync engines and the one most tenants are still running today interconnect, sync, interconnect, sync what it is and what it carries. Interconnect sync is a server a real one. Windows server domain joined sitting somewhere in your data center. On it, you'll find a local SQL database, the sync engine itself, and a rules editor where every filter and attribute flow lives. As a rule, you can open and read. Most small tenants run the built in SQL express that ships with it, larger ones pointed at a full SQL server, and that's the first thing to notice. It's not an agent, it's a platform. You install it, you sign in with a cloud account, and the wizard builds a connector to your directory and another to enter ID. From then on, a scheduler runs a delta sync about every thirty minutes. Read the changes, stage them, apply the rules, write them out. Now what does it carry? Quite a lot. Users, groups and contacts. Of course, but also hybrid joint support. So your domain joined machines can register an Android device right back, which pushes device objects back into ad group right back. So cloud groups can show up on premises password right back. So a reset in the cloud lands in AD. And the hooks that exchange hybrid depends on including the attributes your mail set up quietly relies on. That list is the reason it's everywhere. Then there's topology connect sync handles a single forest, sure, but it also handles multiple forests with matching rules that decide how a person who exists in two directories becomes one identity in the cloud. It handles resource forests, it handles account forests. It handles the strange layouts that grew out of a merger in two thousand and nine and never got cleaned up. If your directory is odd, Connect Sync has probably seen something like it. So why did it become the default? Because for twenty years it was the only answer. It started life under other names Dirsync, then Azure AD Sync, then Azure AD Connect, and the name kept changing while the shape stayed the same. Every tenant that went hybrid installed it. Every consultant knew it. Every guy told you to put it on a dedicated server and leave it alone. And people did exactly that. They left it alone. That's where the hidden cost shows up. Because this server isn't a normal server, it holds the keys to your cloud. The account it uses to write into entry ID has directory level rights. The account it uses to read AD can see every object you've chosen to sync, and with password, hash, sync or writeback turned on. It touches credential material to anyone who owns that box. Can reshape identity in your tenant. In security terms, that makes it tier zero. Same class as a domain controller and tier zero servers have rules. You patch them on schedule, you lock down who can log in, you monitor them, you back up the configuration you plan for the day, windows server hits end of support, and then you actually do the upgrade, which on this server means an in-place plan or a swing migration to a fresh box. Now here's what usually happens. Somebody builds it, it works. The project closes. The person who built it moves teams or leaves. Two years later, the server is three versions behind. The SQL express database is creeping toward its size limit, and the only documentation is a screenshot in an old ticket. Nobody calls that a risk. It's just the connect server until it stops sinking and a new hire sits there for a day with no mailbox. Or worse, a terminated user keeps their access because the disabled never arrived. There's also the single instance rule. You can have only one active connect sync server per tenant. A second one can run in staging mode, which means it reads and computes everything but exports nothing. It's a warm standby and you promote it by hand. That's useful. It's also a procedure someone has to remember and rehearse and trust. So here's the honest picture. Connect sync is powerful. It's flexible. It covers nearly every strange case you can throw at it. And the price is a heavy, privileged, long lived server that you own forever. That price is exactly what Microsoft tried to remove with the second engine lighter managed from the cloud, built on a different idea of where the work should happen. That one is called intra cloud sync. Intra cloud sync, what it is and how it differs. Intra cloud sync starts from a different question. Connect sync asks how do we build a sync engine inside the data center? Cloud sync asks why is the engine in the data center at all? So the engine moved. It now runs in the cloud. What's left on premises is a small piece of software called the provisioning agent. You install it on a domain. Joined Windows Server sign in once and it registers itself. No SQL database, no rules editor sitting on the box, no wizard that builds connectors. The agent reads from ad hands the data up and that's about it. The configuration lives in the admin center. You create a configuration, pick the domain, choose your scope, and set your attribute mappings in a browser. Change a mapping and it applies to every agent at once. Nothing to log into, nothing to export from a server and lose in a ticket. And the connection only goes one way. The agent calls out over https. Nothing calls in. So you're not opening an inbound port to a privileged machine. And that alone changes the security conversation. Now here's the part that fixes the old single box problem. You can install more than one. Agent three is the common recommendation. They all pull from the same configuration, and if one goes dark, the others pick up the work. No staging server, no manual promotion, no procedure. Somebody has to remember at two in the morning, agents also update themselves, so patching the sync layer mostly stops being a project, and that's a big shift in who carries the operational load. Then there's topology. And this is where cloud sync surprises people. It handles multiple forests and it handles them well. It can also sync from forests that have no network connection to each other. That's the disconnected case. A merger, a acquired company, a lab forest nobody could ever trust enough to link. Each one gets its own agent. Each agent talks outbound to the cloud, and the forests never have to see each other with connect sync. That layout needs careful network design. Here it just works. Cloud sync also sits inside a bigger idea. It's part of the entra provisioning service, the same service that handles HR driven provisioning. A user shows up in workday or Successfactors, and an account gets created in AD or straight in entra ID. That's inbound provisioning, and it's one of the cleanest ways to start moving authority out of AD. Hold that thought. We'll come back to it. There's more cloud sync can do provisioning in the other direction too. Creating and updating accounts in on premises ad from the cloud. Same service, same agent. That's something connect sync was never built to do. So the pitch is easy to hear, lighter, cheaper to run, smaller attack surface, better availability by default. But here's the problem. A lighter engine means fewer moving parts, and fewer moving parts means some things are simply not there. Cloud sync doesn't have the long tail of features Kinect sync has gathered over two decades. Attribute mapping is simpler. You get expressions and you get scoping filters, but you don't get the deep rule by rule control of the Sync Rules editor. Some write back paths exist and some don't. Device Writeback is a good example of a gap. The exchange hybrid attributes are another. And the support has been changing, with Microsoft closing gaps released by release. So what was true last year may not be true today. That's why I won't give you a list of what's missing here and call it done. A list like that goes stale. The Microsoft Learn comparison page and the Cloud Sync Support matrix are the source of truth, and we'll use them properly later in the episode. What matters now is the shape of the trade. Connect sync gives you depth and charges you a server. Cloud sync gives you simplicity and asks you to give up some depth. Neither is better in the abstract, the honest answer depends on what your tenant actually uses. So to see where each one wins, let's put them next to each other, side by side where each one wins. Start with architecture. Everything else follows from it. Connect sync is one server doing all the work. Cloud sync is a set of small agents with the work happening in the cloud one box you protect versus several boxes you barely touch. That difference shows up first in filtering and attribute flow. With connect sync, you get the rules. Editor. Every flow is a rule. You can open it, read it, change it, and write your own. Need to take the department field. Combine it with an extension attribute and build a new value on the way out. You can do it. Need a join rule that matches people across three forests using a field nobody else uses. You can do that too. The depth is real. Cloud sync gives you scoping filters and attribute mappings with expressions that covers the common cases and it covers them in a browser. But when your transformation needs five conditions and a lookup, you'll start to feel the ceiling. So the split is simple. Connect sync wins on flexibility. Cloud sync wins on how fast you can understand what it's doing now. Resilience. This one is lopsided. Connect sync allows one active server. The second runs in staging mode, computing everything and exporting nothing. If the primary dies, a person has to notice, login and switch the staging server on. That works, but it's a manual step that depends on someone remembering how cloud sync runs several agents at the same time. One goes down and the others carry on. Nobody flips anything in the moment it fails. There's no procedure to find and that leads to the cost. Nobody. Budgets for operations load. A connect sync server needs windows patching, SQL version upgrades, and a plan for the day the operating system ages out. Somebody owns that forever. Cloud sync agents update themselves. You still watch them, and you still keep them running on supported Windows Server. But the daily wait is a fraction of the old one for a small team. That's often the whole argument. So where does each one win? Connect sync wins when your directory is strange or your needs are deep, heavy custom rules. Complicated attribute logic Writeback features that cloud sync doesn't carry yet. If the sync layer is doing real work for you, it earns the server cloud sync wins when your directory is plain, or when it's messy in a different way. Many forests forests that can't see each other. A team that's tired of patching a security group that wants fewer privileged machines. If the sync layer is mostly just moving users and groups, a whole server is more than the job needs. Here's the grid spoken out loud. Since there's no table to look at. Row one architecture connect single server with a local database. Cloud. Lightweight. Agents. Cloud managed. Row two flexibility. Connect deep rule by rule. Cloud. Simpler. Expression based. Row three availability. Connect one. Active one warm. Standby. You promote by hand. Cloud. Several active agents. Automatic failover row for upkeep. Connect you patch and upgraded cloud agents mostly maintain themselves. Row five reach connect why does feature set built over two decades cloud narrower growing release by release. Read that grid and you'll see the pattern. Connect sync is stronger where you need control. Cloud sync is stronger where you need less to look after, but a grid like this hides the real decision because for most tenants, it doesn't come down to taste. It comes down to one or two specific features that either exist on the cloud sync side, or don't. A single missing writeback path can settle the whole question in one meeting. So before anyone talks about moving, there's a check to run a feature gap. Check line by line. The feature gap check before you move. Run this check before you move. Anything. 00:16:03 Speaker: Not after the pilot, not after the change ticket gets approved before. Because a gap you find in a meeting costs you an hour and a gap you find mid cut over costs you a week end start with device right back. If your on premises apps or policies read device objects from Adi. That's a dependency and you need to know it exists. Some tenants use it for older conditional access setups tied to on premises federation. Many don't use it at all and never knew it was on. So go look. Open the Connect Sync wizard, check which optional features are enabled and write them down. That list is your starting inventory. Next hybrid exchange. This is the one that ends more conversations than any other exchange. Hybrid depends on a specific set of attributes flowing in a specific way, and on right back of some of that data into Adi. If you still run exchange on premises or you keep a server around to manage recipients, treat this as a hard stop until you've read the current guidance. We'll return to that attribute problem in its own section because it's bigger than a single line on a checklist, then group write back. This feature has changed names and behavior more than once, and plenty of admins aren't sure what theirs is doing. Check whether any on premises process reads those groups back. Mail enabled distribution lists are the usual reason people turn it on. If nothing reads them, you may be carrying a feature purely out of habit. Now the part people skip custom sync rules, open the rules editor on your connect server and filter for rules that are not the default ones. Every custom rule is a decision somebody made years ago. Maybe it rewrites the sign in name. Maybe it blocks accounts with a certain prefix. Maybe it builds a value from three attributes. Cloud sync can handle some of that with expressions and scoping filters, but not all of it and not always the same way. So for each custom rule, ask two things. Why does it exist and can a mapping do the same job? You'll find rules nobody can explain. That's normal. Treat those as a finding, not a failure. Complex transformations deserve the same look. Anything that joins data across forests, anything that depends on a lookup, anything with nested conditions. Those are the cases where the lighter engine runs out of room first. Now password right back. It matters because self-service password reset only feels complete when the new password lands in add. Both engines can support it, but through different paths, and the setup steps differ, so don't assume it carries over. Confirm it, test a reset with a pilot user and watch the password actually change on premises. Success in the cloud portal doesn't prove the right. Reach the directory, then scale and timing. Connect sync runs a delta cycle about every thirty minutes. By default, Cloud sync runs on a shorter cycle around every two minutes, but both have limits on object counts per configuration, and those limits change. If you're syncing a very large directory, check the numbers before you assume the new engine fits. Also, check how fast you need changes to land. If a disabled account must reach the cloud within minutes, both timing models deserve a real test, not a guess. Here's how to run all of this without drowning. Make one sheet down the left side, every feature and every custom rule across the top three columns. Do we use it? Does cloud sync cover it? And what's the workaround? Fill it in with evidence, not memory, and use the right sources. The Microsoft Learn comparison between connect Sync and Cloud sync is the first one. The Cloud Sync Support matrix is the second. Both get updated as features land, so read the live pages the day you plan the move. Anything I tell you here has an expiry date. Those pages don't. When the sheet is done, you'll know one of three things. Nothing blocks you. A few things block you, and you can work around them or something fundamental blocks you and the honest answer is to stay on connect sync. For now, all three outcomes are good because all three are decisions and you made them on purpose. But notice what this sheet covers. It covers the sync layer. Layer one nothing on it tells you where passwords get checked. And that's a completely separate question with its own failure modes, and it needs its own decision. Sign in is a separate decision. Here's the second decision. Where does the password get checked? That's the whole question. Not which sync tool, not which server. Just one place, one moment. A user types a password and something has to say yes or no. There are three answers. Password, hash sync. The cloud checks it. Pass through authentication. Your domain controllers. Check it live while the user waits. Federation a separate system you run checks. It usually ADFs and tells the cloud what it decided. Three methods, one question. Each one answers it in a different place now. Why do teams blur this with the sync tool choice? Because in most tenants, the two were installed together. Same wizard, same afternoon. You ran the connect setup and one of the screens asked how users would sign in. You picked an option, click next, and the project moved on. From then on, connect meant everything the sync, the sign in, the whole hybrid setup, all one word in everyone's head. And that's how you get a team that says, we're moving off connect when they've only decided to change the sync engine and haven't touched where passwords are checked or the reverse, they plan to retire federation and somebody assumes the sync server goes away with it. It doesn't. They're separate pieces with separate lifespans. Here's what makes the separation easier to live with. Both sync engines support the common sign in options. Cloud sync works with password hash sync. Connect sync works with all three. There are caveats, and they depend on features you've turned on, so confirm the details against the current Microsoft documentation before you commit. But the broad rule holds. You can pick your sync engine and your sign in method independently, and change either one without being forced to change the other. That freedom matters because the risk sits mostly in the sign in choice. Think about what each answer means for a bad day. If the sync engine stops, new changes stop flowing, but people already in the system can still sign in. That hurts, and it's fixable. If the place where passwords get checked stops, nobody signs in at all. Every user, every app, every device. That depends on that check. So the sign in method sets the blast radius of an outage, and the sync tool mostly doesn't. That's why I'd weigh this decision more heavily than the first one, even though it gets a fraction of the attention in planning meetings and there's a clear order to look at them in. Start with the method Microsoft recommends as the default, because it's also the one that holds up best when things break. Password. Hash. Sync. Password. Hash. Sync. The default worth defending. Here's how it works. Your domain controller stores a hash of each password, not the password itself. A scrambled version produced by a one way function. Password. Hash sync takes that stored hash, runs it through another round of scrambling with a salt added, and sends the result to enter ID so the cloud never receives your password. It never receives the on premises hash. Either it receives a hash of a hash and that value can't be turned back into the original. When a user signs in, entry, ID takes what they typed, runs the same math, and compares the results. That's the entire trick. The check happens in the cloud against a copy that can't be reversed. Now the first benefit and it's the one that matters most on a bad day. Because the check happens in the cloud, it keeps working. When your site doesn't, the data center loses power. Sign in to Microsoft three hundred sixty five keeps going. The domain controllers are down for a patch. Gone wrong. Same thing. Users on their phones at home, at a customer site. They never notice. Nothing on premises sits between them and the answer. Compare that with the other two methods. Both need something of yours to be alive at the moment. Someone logs in. Hold that thought because we'll test it under stress in a moment. The second benefit is easy to miss, and it's about what the cloud can see. Identity protection watches for risk. One of its signals is leaked credentials. Microsoft finds username and password pairs in breach dumps and on criminal sites, and compares them against hashes. It holds a match, flags the user as risky, and a policy can force a password change before anyone gets hurt. That comparison needs the hashes in the cloud. Without password hash sync, you lose that signal. You're running an identity system that can't tell you when your own people's passwords are already for sale. So when someone says password hash sync is just a convenience push back, it feeds your risk engine. Now the objection, and I hear it in nearly every security review. We don't want passwords in the cloud. Fair instinct. Wrong target passwords don't go to the cloud. What leaves is a salted, iterated hash of a hash built so that a stolen copy can't be replayed as a login. An attacker who got every one of those values would still have to crack them one at a time, and the format is designed to make that painfully slow. Meanwhile, look at what the alternative asks you to trust a set of agents or a Federation farm sitting on your network, handling live passwords in the clear as users typed them. Those are the machines attackers actually go after. So the real comparison isn't password in the cloud versus no password in the cloud. It's a non-reversible hash held by Microsoft versus live credentials passing through servers. You run and defend yourself. Some organizations still have a rule that says no hashes may leave. If that's yours, ask where the rule came from. Often it was written before the cloud had these protections, and nobody has revisited it since. Sometimes there's a real legal or contractual reason. Then that's a decision and you document it, but check before you inherit it. One more point and it changes how I design nearly every tenant turn, password, hash sync on, even when it isn't your main method. Say you run Federation today or pass through enable hash sync alongside it. Anyway, it sits quietly in the background and it gives you a way out. If the farm fails. If the agents vanish, you can switch the domain to cloud authentication and users sign in with the hashes already waiting. No scramble, no rebuilding trust at midnight. That makes it a backup for every other choice. So that's the case. It works through an outage. It powers leaked credential detection. It exposes less than people fear. And it's the escape hatch for the methods that are more fragile. But some teams still want the password checked on their own domain controllers in real time, and they have a reason for it. Microsoft built a method for exactly that pass through authentication. Pass through authentication. Fewer moving parts. New dependencies pass through authentication works differently. No hash in the cloud. When a user types a password entry ID, takes it, encrypts it, and drops it in a queue. A small agent on your network picks it up, decrypts it, and checks it against a domain controller. Then it sends back one answer yes or no so the password is validated against. Add live every single time you install the agent on a domain joined Windows Server. It only makes outbound connections so you don't open an inbound port and you run more than one. Microsoft recommends at least three because the agents share the load and cover for each other. Now why did so many tenants pick it? Two reasons, and both are real. The first is that no password hash leaves your network for teams with that rule written into policy. This was the clean way to go hybrid without breaking it. The second is that your on premises account policy applies at the moment of sign in Logan hours, a disabled account, an expired password. The domain controller says no and the user is out right then. There's no delay waiting for a sync cycle to carry the change up. Compare that with hash sync, where a disabled account can still work for a short window. For some security teams, that gap matters, and on paper the setup is light. A few agents. No form, no certificates to renew, no proxy sitting on the internet. Fewer moving parts than federation by a wide margin. But here's the problem. Every sign in now depends on something you run for a user to get in. Three things have to be alive at once an agent, a route from that agent to a domain controller, and the domain controller itself. If all your agents go dark or the network between them and ad breaks, nobody signs in. Not to Microsoft three. Sixty five. Not to any app that uses entry ID. The cloud is up and it doesn't matter. That's the same blast radius we talked about earlier. You've shortened the chain compared to Federation, but you haven't cut it. There's also a quieter cost. Passthrough doesn't hand the cloud any hashes. So some of what runs on those hashes stops working. The leaked credential check we covered is the big one. Identity protection can't compare your users passwords against breach data if it never holds them. Other risk signals that lean on the same data go thin, too. You can still run conditional access. You can still require MFA, but a layer of detection is simply gone, and that's before the smaller items. Agent versions to track. Capacity to watch. Because a busy morning sends a lot of checks through a small number of boxes, domain controllers that need to be reachable from wherever those agents live. So why are many of those same tenants now reconsidering? Because the reason they chose it has shifted underneath them. The hash was the fear. But as we saw, what leaves is a salted hash of a hash built so it can't be replayed. Meanwhile, the dependency was the price and it's one they pay in every outage drill. The method that felt safer on paper turns out to be the more fragile one. In practice, there's a middle path, and it's the same one we described for every method. Run passthrough if you must, and turn password hash sync on beside it. Then you keep the real time policy check as your primary with a cloud copy standing by if the agents ever vanish. So pass through is a fair choice with a clear trade, fewer parts, but still tied to your data center. If you want to see what a heavier tie looks like, look at the oldest option the one with the farm, the proxy, and the certificates that expire on a Sunday Federation, Federation and ADFs. What you're really running Federation is the oldest answer here. Entra ID doesn't check the password at all. It hands the user off to a separate identity provider that you run. for most tenants, that's Active Directory Federation Services or ADFs. The user signs in there, the farm issues assigned token and entry ID trusted. So what are you actually running a farm of ADFs servers? Usually two or more with a database behind them in front of those web application proxy servers sitting in a DMZ. So people outside the network can reach the sign in page, a load balancer, public DNS and certificates, a token signing certificate, a token decrypting certificate, a service communication certificate. Each one has an expiry date, and each one lives in a calendar that somebody has to own. Then there are claims, rules. Those are small scripts that decide what goes into the token, which attributes get sent, how the user's identifier gets built, which relying parties get, which claims most of them were written once by someone who understood them and then left alone for years. Now, why did Federation exist at all? Because in the early days, the cloud couldn't do what enterprises needed. You wanted smartcard sign in. You wanted a third party MFA product your security team already owned. You wanted custom claims for an app that expected a very specific token entry. ID couldn't do those things. So you built a farm that could. That was a reasonable call at the time. It was the only call. But look at what it costs to keep. The farm needs patching and the patch window has to cover every server in a specific order. The certificates need renewing, miss the token, signing one or let auto rollover break quietly and every cloud sign in fails at once. That's the Sunday outage people remember not because the cause was complicated, but because nobody was watching the date. Then the attack surface, the web application proxy servers face the internet by design. They're the front door to your identity system, and attackers know exactly what ADFs looks like. Password spray against the sign in page. Exploits against the farm. Attacks that steal the token signing key, which lets someone forge a login as anyone with no password at all. That last one isn't theory. It's been used in real intrusions. Which brings us to the structural problem. ADFs is a single point of failure for every cloud sign in. Not most of them. All of them mailbox teams, SharePoint, every app wired to enter, ID, every phone, every browser. If the farm is slow, everything is slow. If the farm is down, everything is down, and you've built the whole path out of servers you patch and certificates you track. Compare that with where we started. Password hash sync needs nothing of yours to be alive. Pass through needs a few agents. Federation needs a whole stack exposed to the internet and healthy at the same moment. So here's the question to ask. Do the original reasons still hold? Mostly no. Entry ID now covers a lot of what Federation was built for. Certificate based authentication works natively, so Smartcard and certificate sign in no longer needs a farm. Fido2 security keys and passkeys are supported directly. An external authentication methods let you plug in a third party MFA provider without handing the whole sign in over to ADFs. That doesn't mean every federation setup can go tomorrow. Some tenants still have an app that needs an exotic claim or a regulatory rule that names a specific mechanism. Those are real and will deal with them when we plan the cutover. But a lot of farms are still running for reasons that expired years ago. So before we plan anything, let's compare all three methods under the same kind of pressure. One scenario, one bad day sign in methods under stress. Picture the failure. It's two fourteen on a Tuesday afternoon. The power feed to your primary data center drops. The generator doesn't catch. Every server in that room goes dark. Domain controllers, file servers, the ADFs farm, the pass through agents, all of it gone at once. Now ask one question can your people still sign in to Microsoft three hundred sixty five? Start with password hash sync. The answer is yes. The hash of the hash already sits in entry ID and the check happens there. A user opens outlook on their phone, types a password, and gets in. Teams works. SharePoint works. Nothing they touch needs a single machine from that room. You'll have plenty of problems that afternoon, but sign in isn't one of them. Now pass through here. The answer is no, or at least not for long. The agents live on servers, and those servers just lost power. Even if you ran agents in a second site, they still have to reach a domain controller to get an answer. If every controller sits in the dark room, there's nothing to ask. Entry ID drops the encrypted password in the queue, waits for an agent that never shows up, and the user sees an error. Tokens people already hold keep working until they expire so the damage arrives in waves. First, the new sign ins fail, then the refreshes, then as the hours pass, everyone. 00:32:02 Speaker: Now, Federation. This one fails faster and it fails wider. The moment the farm or the proxy is unreachable, the redirect from entry ID leads nowhere. The user types an address, gets bounced to your sign in page, and the page never loads. Every cloud app that trusts that farm breaks with it. And remember, the farm is only one link. Lose the load balancer, lose a certificate, lose the proxies route to the farm and you get the same result. More parts mean more waste to fail. Line the three up and the pattern is plain hash sync depends on nothing of yours. Pass through depends on agents and domain controllers. Federation depends on the whole stack front door included. Here's a wrinkle though. Seamless single sign on the feature that signs in domain joined machines without a password prompt relies on Kerberos tickets from your domain controllers. So during this outage, a laptop sitting inside the network loses that quiet convenience, but a user can still type a password, and with hash sync behind it, that still works. Hybrid joint devices are a bit different. They hold a primary refresh token, so people already signed in on them can often keep working for a while. It's a grace period, not a plan, and that's the part worth remembering. Resilience doesn't come from the quality of your data center. It comes from the distance between the user and the thing that says, yes, hash sync puts that thing in the cloud. The other two keep it at home. Which brings us to the question. Under all of this, we've been talking about where a password gets checked. But there's an earlier question we skipped. Who decided that Addy gets to say who a person is in the first place? That's authority. Source of authority. The question nobody asks. Source of authority is a simple idea for any object in your directory. One system owns the truth. It's the place where an attribute gets created, edited, and deleted. Every other copy is just a reflection of it. Take a user the name, the job title, the manager, the account status. Somewhere one system is allowed to say this is correct. Change it there and the change travels outward. Change it anywhere else and it gets overwritten or blocked or ignored. That's authority, not who stores the data. Who's allowed to change it. Now what's the default in a hybrid tenant active directory? Always when you install the sync engine. Years ago you made an implicit deal. Addy is the author and entry ID is the reader. Every synced object carries a flag that says so, and the cloud treats it as read only. For most attributes. You can see the user in the admin center. You just can't really own them there. We touched on this earlier with the edit that snaps back after a sync cycle. That was the symptom. This is the cause. And here's the problem with that default. Think about everything a modern organization wants to do in the cloud lifecycle workflows that onboard a person on their start date. Access reviews that remove people from groups every quarter, entitlement management that hands out access packages, HR driven provisioning where the system of record for people actually lives in the HR platform, not in a directory. Every one of those wants to write to the identity, and for a sync user, every one of them has to route through ad first. The cloud decides something, then waits for an on premises directory to accept it, then waits for the next thing to hear about it. Governance gets pushed through a funnel built in twenty twelve, so you end up with a strange split. Your cloud tools are modern. Your source of truth is the old directory, and the two spend their days arguing about who's right. Here's how I'd put it. In short beats. The old model authority starts in ad. Everything else is a copy. Changes flow one way. The cloud waits. The new model authority sits where the business decisions are made. Often that's an HR system feeding the cloud directly. Often it's entry ID itself. AD becomes a consumer kept alive for the apps that still need it and nothing more. That's the shift, not a new sync tool, a different answer to who's in charge. And this is where most teams go wrong. They treat sync direction as a technical setting. Something the identity admin tunes like a firewall rule. It isn't. Sync direction is a business decision. Who creates an account when someone joins. Who disables it when they leave? Who's accountable if the wrong person keeps access for three weeks? Those are questions for HR, for security, for the people who own the process. The sync direction just records the answer. When it stays on default, the answer is whoever happens to run the domain, nobody chose that. It's what was left over when the project ended. Think about how that plays out. A contractor leaves on Friday. HR closes the record in their system, but the account lives in AD and ad only hears about it when someone files a ticket and the ticket sits in a queue until Monday. Meanwhile, the cloud still shows an active user. Nothing technical failed. The model just had no owner for that handoff. Moving authority fixes the question at the root. The person who decides is the person whose system holds the record. The directory follows instead of leading. Now this doesn't mean Adi disappears. Plenty of on premises apps still read it. Plenty of file servers, print queues, and legacy tools still need those accounts, so the goal isn't to delete the directory, it's to stop treating it as the center of everything. And that idea has a practical edge, because for years there wasn't a clean way to do it. You either lived with Adi as the author, or you rebuilt your accounts from scratch as cloud only users, and nobody wanted that project. That's changed. Microsoft has given us supported ways to shift authority object by object, without throwing away the identities your people already use. So let's look at what those paths actually are. Moving authority. Source of authority. Transfer for users and groups. Start with the user. A single user is anchored to add the cloud copy carries a flag that says on premise is managed, and that flag controls what you can edit. Source of authority transfer flips it. You take a single user and convert them to cloud managed. So entry ID becomes the author for that object. The identity stays the same. Same sign in name, same object ID, same group memberships and licenses. Nobody gets a new account. Nobody has to rebuild a mailbox profile. What changes is who's allowed to write. You do it in steps and the order matters. First, you stop the sync engine from claiming that object, scope it out of the sync or flag it so the engine lets go. Then you convert it. Then you confirm that edits in the cloud actually stick. If you skip the first step, the next cycle can overwrite your change and you're back where you started. And you don't have to do it for everyone at once. This works object by object or group by group, which makes it a pilot. You can actually run, pick a small set of users, flip them, and watch what happens for a few weeks before you touch anyone else. Now groups. And this is where the payoff gets bigger. A group that lives in AD can only be managed through ad ad, a member in the cloud, and the sync fights you that blocks most of what cloud governance wants to do. Access reviews can't cleanly remove people. Entitlement management can't add them. Lifecycle workflows hit the same wall. Group source of authority conversion changes that convert the group to cloud managed and enter ID takes over membership. Now an access review can remove a member and have it stay removed. An access package can add one without a ticket to the directory team. The group becomes something the cloud can govern and not just display. That's the real unlock. Governance stops routing through a funnel. But here's the problem on premises apps don't know any of this happened. Some of them read those groups from Addy to decide who gets a file share or who can open a legacy app. If you convert a group to the cloud and nothing writes it back, the copy and add goes stale. People get removed in the cloud and they still have access on premises. That's a worse failure than the one you started with because it looks fixed. So before you flip anything, ask what still reads the object which attributes matter to your on premises apps? Does something look at a department field to build a mailing list? Does the script check a manager attribute? Does a file server rely on a security group? List them for each one. Decide whether you need writeback, whether the app can move, or whether that object should stay on premises for now. Then there's the risk of orphans, an object that's cloud managed but still expected in AD can end up in a strange middle state. The directory holds a record, nobody updates and the cloud holds a record ad can't see disabled in one place, active in the other. Those are the accounts that surface in an audit and nobody can explain. The cure is boring. Track every object you convert. Keep a list of what moved, when and why. Check that the write back you expect is actually running and confirm it with a test. Not a hope. One more caution. This capability has been growing. Microsoft has been widening which object types and scenarios are supported, and some of it is still rolling out in stages or sitting in preview, so don't take my list as final. Read the current Microsoft Learn guidance on source of authority. Transfer the week you plan the work and check what your exact scenario supports. Because authority moves in more than one direction, and the biggest anchor holding most tenants to add isn't users or groups, it's mail. The exchange attribute trap. Mail is where most authority projects stall. Here's why. When you ran exchange on premises, the mailbox settings were written straight into ad proxy addresses. The mail nickname. The remote routing address a handful of values that tell the system what a mailbox is and where it lives. Exchange didn't just read the directory, it wrote the directory. Then you move to exchange online and the attributes stayed. They kept flowing up through sync and the cloud kept trusting them. So even a tenant with every mailbox in the cloud still has Addy acting as the author of its mail. That's the trap. The mail data looks like cloud data, but the pen is still on premises. Now the obvious move is to shut down the last exchange server, decommission it, remove the role, and be done. Plenty of admins did that and then discovered they couldn't edit a recipient properly anymore. No tool to change an address without editing raw attributes in Addy. Microsoft's guidance for this is specific. Keep one exchange server for management and for a lot of tenants. That's a supported pattern. It isn't running mail, it's just there. So you have a proper way to change those attributes and have the change land correctly. Microsoft has also been working on a way to manage recipients without that server. The details keep moving, so check Microsoft Learn for what's supported today before you pull the plug on anything. Now think about what happens when you shift authority and these attributes are still in play. Say you convert a user to cloud managed entry ID is the author now, but the mailbox attributes were written by an exchange server and anchored in Addy, and the cloud may still expect that data to arrive the old way. You can end up with an address change that takes effect in one place and not the other. Or a mail enabled group that no longer updates its members cleanly. Nothing throws an error. The mail just routes oddly, or an alias quietly fails to work. That's the dangerous kind of failure because it hides. So the question to ask for every object is simple does this one have a mailbox or is it mail enabled? If yes, find out where its mail attributes are managed today and where they need to be managed after the change? Don't flip authority on a user or a group until you've answered that. And this is where the two sync engines part ways. Again, Connect sync has long handled the exchange hybrid attribute flow, including the Writeback. That hybrid depends on. Cloud sync has been catching up, but it doesn't cover every hybrid scenario yet. If you still run any hybrid mail configuration, that's a gap. You check first line by line against the live support metrics. Not from memory, not from a blog post, including this one. There's a practical way to hold all of this. Split your objects into two piles. The first pile has no male attributes tied to on premises. Those can move cleanly. The second pile still depends on exchange data and add those weight. Or they get a plan you don't have to solve male first. You just have to know which pile each object is in. Because once you know that, the bigger question becomes concrete not should we modernize? But which of these gaps actually block us and which only look like they do? And the answer to that decides whether a move to cloud sync is worth doing. Now, when to move to cloud sync. So when does the move actually make sense? Start with the signals that say yes. The first one is simple your feature gap sheet came back clean. No device right back. You actually use no group. Write back that something reads no custom rules. Nobody can defend. If the sheet says nothing blocks you, the technical argument is mostly over. The second signal is multi forest pane. Maybe you've got three forests from three acquisitions and one of them can't see the others. Connect sync can handle that, but it takes careful design and a lot of rules. Cloud sync was built with that shape in mind. Agents sit in each forest, they only call out. And nobody has to open a route between networks that never wanted to talk. The third is an aging server. Maybe the box is still on an operating system nearing end of support. May be the SQL installers a version nobody wants to touch. Maybe the person who built it left in twenty nineteen. And the notes are one page long. When the old server needs a rebuild anyway, that's the cheapest moment to ask whether you need to rebuild it at all. Now the counter signals. These are just as clear device. Write back that something depends on stay an exchange hybrid setup you can't yet manage another way. Stay at least for that part. Exotic transformations the kind with nested conditions and lookups across forests stay. If the sink layer is doing real work for you, that's what the server is for, and replacing it with something lighter just moves. The problem. Staying isn't a failure, it's a result. You checked, you found a real dependency, and you made a call. Revisit it in six months because the support matrix keeps changing. Then there's the business side, which usually decides the timing. Fewer servers is the first driver. Every server you retire is one less thing to patch, one less thing to back up, one less line in the audit. Simpler audits is the second. An auditor asking what has privileged access to your cloud directory gets a shorter answer when the answer is a few agents and not a full server with a database holding credentials and less tier zero exposure is the third, which will cover properly when we get to security. The sync server is one of the machines an attacker most wants to own, and shrinking that footprint pays off in ways that never show up as a feature. So what's the honest answer? It depends on who you are. Here are the profiles I see most. The small or mid-sized tenant with one forest, a plain directory, and a single admin who's also the help desk move. The patching load alone justifies it, and the feature gaps rarely apply to you. Pair it with password hash sync and you've cut your on premises identity footprint to almost nothing. The multi forest company built through mergers move and probably sooner than you think. This is where cloud sync saves the most pain because it handles the shape you've been fighting with. Rules the enterprise with hybrid exchange device writeback and years of custom rules. Don't move everything. Look at which forests or populations are simple and consider running cloud sync for those. While Connect Sync keeps the complicated core. Microsoft supports running both side by side, as long as they don't claim the same objects and the regulated organization with a hard rule on where data lives. Read the rule first, then decide. One thing holds for all four. The decision isn't Kinect or cloud. It's which objects need what. Some will move this quarter, some won't move for a year, but none of them move until the groundwork is done. And that groundwork is where most projects quietly fail long before anyone installs an agent. Pre-migration discovery and clean up. Most failed migrations fail here in the dull part. Not at the install, not at the cutover. Weeks earlier, when somebody decided the data was probably fine, it usually isn't. So start with an inventory and start with names. Pull every user principal name in the directory and look at the domain part you're hunting for suffixes that don't exist in the cloud. A local one like Corp local that was never a real internet domain. Cloud sync and connect sync. Both need a routable verified domain in your tenant. If a user carries a name, the tenant can't verify the sync, either rewrites it or throws an error, and neither outcome is one you want to meet for the first time on cutover day. Next proxy addresses. This attribute holds every email alias a person has, and years of mergers pile up in it. Two users with the same address. A stray address on a disabled account. An alias that points at a domain you dropped in twenty seventeen. Duplicates. Here are the classic sync blocker because the cloud refuses to let two objects own the same value, one of them loses, and it's rarely the one you'd pick. Then look at the odd characters trailing spaces. A comma where a period belongs. A name with a symbol. The cloud won't accept small things. They're invisible in the console and they stop an object cold. You don't have to find all of this by I run. I'd fix. It's a free Microsoft tool that scans your directory and flags attribute errors before the sync engine ever sees them. Duplicates bad formatting values that are too long. It lists each problem, shows you the value, and suggests a fix. Run it early. Run it again after you fix things. The first pass is almost always longer than anyone expected, and that's the point of running it now instead of mid-project. Then stop and write down what the old engine is doing. This part gets skipped most often. Your connect server has been quietly shaping data for years, and none of that logic lives anywhere you'd think to look. Except the server itself. Open the rules editor. Export the configuration, record every filter. Which domains are in scope, which organizational units are in, which are out. Record any attribute based filtering like skipping accounts with a certain prefix. Cloud sync handles scoping differently. It uses scoping filters and attribute mappings set in the cloud, and the model isn't one to one. So a filter you wrote in the old tool has to be rebuilt, and you can't rebuild what you never wrote down. If nobody can explain a rule, flag it, don't copy it blindly into the new setup. A rule with no owner is a risk in either engine. Now map your write back dependencies. We covered the feature gap sheet already, so this is the hands on version for each write back feature that's turned on. Find the thing that reads it a script, an app, a policy. A person who opens a console every Friday. If you find a feature turned on and nothing reading it good, that's one less thing to carry. If you find something reading it, that item goes on the blocker list until it has a plan. Last the prerequisites because they're short and they bite. 00:47:43 Speaker: Check your licensing. Cloud sync works with the entry ID licenses most tenants already hold, but some features, like certain provisioning scenarios, sit behind higher tiers. Confirm yours before you promise anything. Check where the agents will live. They need a domain joined Windows server with a supported operating system. Outbound access to Microsoft endpoints over standard web ports, and enough headroom to run quietly. Plan at least three if you want real redundancy and decide who owns them. Because an agent with no owner is next year's forgotten server. When this stage is done, you'll have a clean directory, a written record of the old engines logic, a blocker list, and a short list of hosts and licenses. That's a project you can actually plan, and only now does the install make sense. The migration path connects sync to cloud sync. Now the install. Start with the agents. Put the provisioning agent on your domain. Join servers the ones you picked during discovery. Sign in with a hybrid identity admin account and the agent registers itself with your tenant. Install the second one, then the third. You want them running before you configure anything, because the cloud side needs somewhere to send the work. Then open the intra admin center and create a new cloud sync configuration. Pick your forest, pick the scope. And here's the rule that says projects start small test scope. First. A handful of users in a test owe you nothing that touches a real department. Cloud sync lets you run in a provisioning on demand mode so you can pick one account, run it through, and read exactly what the engine would do before it does it. Read that output every time it shows you the attribute mappings, the values that would flow, and the errors you'd hit. A bad mapping court here costs you five minutes. Court after a full sync. It costs you an afternoon of cleanup. Now the part that decides everything. How does an object keep its identity matching? When cloud sync meets a user that already exists in the cloud, it needs to decide whether this is the same person or a new one. Connect sync used the source anchor, and for most tenants, that's the MSDS consistency guide stored in Addy and turned into the immutable ID in the cloud. Cloud sync takes over that same value for matching. If the anchor lines up, the object keeps its identity along with its mailbox, its licenses, and its group memberships. If it doesn't line up, you get a duplicate or worse, a deletion followed by a Recreate, so check the anchor before you move a single O. You confirm which attribute your connect server uses. Confirm the values match what's in the cloud. A mismatch you find now is a fixable data problem. A mismatch you find after cutover is an outage with a name on it. Next the staged move. This is the safest path and it's the one I'd run for nearly everyone. You don't flip the whole directory, you move a pilot ou and connect sync keeps the rest. Here's how that works. In practice, you scope your pilot OU out of the connect sync filter. You scope the same OU into the cloud sync configuration. Both engines are live, but each one owns different objects and they never claim the same one. That last part is critical. Two engines writing to the same user is how you get attribute fights and flapping values, and nothing about it is obvious until a ticket shows up. Move the pilot. Let it run for a full cycle. Check that the users still match, that their attributes still flow, and that sign in still works. Then widen it one OU at a time and keep a log of each step. Which o you which date? Who checked it? Now the honest note about configuration. There isn't a one click export that carries your old rules across the scoping filters and attribute mappings get rebuilt by hand using the notes you wrote during discovery. That's why the discovery work mattered. Microsoft supported cutover process for moving. A configuration is documented and keeps changing, so follow the current. Learn guidance for the exact order of steps, and don't trust a walkthrough that's more than a few months old. Which brings us to the safety net. The rollback plan. Keep the old connect server fully intact until you've finished validating. Don't uninstall it. Don't delete the database. Don't even turn it off. If you can avoid it, just set it to stop exporting for the objects that moved. Put it in staging mode if you need a clean, quiet standby. If something breaks in week two, you want a working server. You can point the objects back to not a rebuild. You start at midnight. Define done before you start. Say it out loud with the team. All pilot objects syncing without errors for two weeks. No stale attributes. No help desk tickets. Trace to the move. Only then does the old server get decommissioned. Because here's what we've really done so far. We've moved where the data comes from, but we haven't touched where the password gets checked. A user can sync perfectly through cloud sync and still be sitting behind a Federation farm that's waiting to fail. That change needs its own plan. Changing sign in method without locking anyone out. Start with the safety net before you touch a single sign in setting. Turn on password hash sync. If your federated. Today, enable it alongside the form. Let it run a full cycle and confirm that the hashes have landed in the cloud for the users you plan to move. This takes a few hours, sometimes a day, and it costs you nothing in production. The farm keeps working. Nobody notices. But now you have a place to land. Skip this step and you're flipping a domain to cloud authentication with no hashes waiting. Every user fails on the first attempt. That's the lockout people remember. Now the move itself. You don't flip the whole domain at once. Staged rollout is built for this. In the admin center, you enable staged rollout for cloud authentication, then add users through groups. Put twenty people in a pilot group. Their sign ins now go through the cloud using the hashes while everyone else keeps hitting the farm. Same tenant, same domain. Two paths running side by side. Pick the pilot carefully, not just the IT team because they'll forgive anything. Add a few people from. Finance, a few from the field, someone who works from a phone most of the day. You want the awkward cases early, then widen it group by group A hundred users, then a department, then a site. Each step gets a pause and the pause has a purpose. You're watching sign in logs, looking for failures and reading the error codes instead of waiting for the ticket. While that runs, validate conditional access. This is where surprise is hired. A federated sign in carries claims that enter ID may have been trusting, like whether the user came from inside the corporate network moved the user to cloud authentication, and that signal can change a policy. That said, skip MFA when on the corporate network may start prompting or worse, stop trusting. Open your policies, read each one, then test it with a pilot user from inside the office and from outside. Check MFA the same way. If your farm was handing MFA to a third party product, the cloud path has to cover that job. Confirm that pilot users are registered for MFA or an external method you've configured. Find out now whether anyone is about to get a prompt they can't answer. Now the stragglers. Every tenant has them. Legacy clients first an old mail client, a scanner that sends email. A script that authenticates with basic credentials. These sometimes depend on how the farm handled the request. Pull the sign in logs and filter by client app. Anything marked legacy goes on a list. Each entry gets one of three outcomes. Updated, replace it or accept that it breaks and tell its owner before it does. Service accounts. Next. These are the quiet ones. An account that runs a sync job or feeds a line of business app with a password nobody has typed in years. Does it sign in to the cloud at all? If so, how? Find out. Then confirm the pilot covers it. Line of business apps. Last, and this is the one that gets underestimated. An app that trusts your farm directly doesn't care that you moved the Microsoft three hundred sixty five domain. It still redirects to ADFs. That doesn't break in this step, but it tells you the farm can't shut down yet. Noted. We'll deal with it when we take the farm apart. Then communicate and keep it plain. Don't send a message that says we're migrating authentication protocols. Say what changes for the person reading it. Most users will notice nothing. Some will see a slightly different sign in page. A few may be asked to register for MFA. Tell them when. Tell them what it looks like and give them one place to ask. Send it before the group moves, not after, and keep your own rollback close. Removing a user from the staged rollout group sends them straight back to the farm. That's your undo button and it works in minutes. Use it without guilt. The moment something looks wrong, when the last group has moved and the logs are clean for a couple of weeks, you convert the domain from federated to managed. That's a small change at that point because the hard work is already done, but the farm is still running and it's likely doing a job you haven't fully counted. Retiring ADFs the application inventory. Here's the assumption that syncs most ADFs retirements. Teams think the farm exists for Microsoft three hundred sixty five, so they move the domain to managed authentication, watch the sign ins hold steady, and call the farm dead. Wait, but ADFs was never only a Microsoft three hundred sixty five. Sign in server. For years, it was your general purpose identity provider. Every app that wanted single sign on got a relying party? Trust the expense system, the learning platform, the vendor portal a department bought on a credit card in twenty eighteen. Each one points at your farm and each one keeps working until the day the farm goes away. So before anyone plans a shutdown count what's actually attached, start by opening the relying party trusts in ADFs. That's your first list. It shows every app that was ever configured and the word ever is the problem. Some of those trusts belong to apps that were retired years ago. Others belong to apps that run every morning at eight oh five. The list can't tell you which is which. For that, use the ad FS Application Activity report in the Entra Admin center. It reads your ADFs sign in data and shows which relying parties people really use, how many users and how many sign ins over a recent window. It also flags which apps are ready to move, and which ones have settings that need attention before they can run it early and run it more than once. A report taken in a quiet month will miss the app that only matters at quarter end payroll annual benefits enrollment, the audit tool that opens once every twelve months and breaks everyone's plans when it can't sign in, cover a full business cycle if you can, or at least ask the people who run those cycles. Now sort the app's three buckets and every app lands in one migrate. The app is alive, people need it, and it can talk to entra ID. Most modern apps support Saml or OpenID connect, so you register them as enterprise applications and point them at the cloud. Replace. The app is alive, but it can't move. Maybe it only speaks a protocol entry ID doesn't handle or the vendor is gone. These need a new home, and that's a project with its own owner and budget. Retire. Nobody uses it. The report shows zero sign ins and the business owner shrugs when you ask. Don't just trust the shrug, though. Disable the trust. Wait and see who complains. Then remove it. Then the translation problem. Every migrating app comes with claims. Rules those small scripts that decide what goes into the token. Enter ID has its own way to do this. You map attributes in the app's single sign on settings, build any transformations there and send the claims the app expects. Often that's simple a name identifier, an email, a group list. But some rules do odd work a lookup against an attribute store, a condition that sends different values to different users. A regex nobody has read since it was written. Pull each rule out. Write what it does in plain words, and then decide how enter ID reproduces it. If you can't explain a rule, find the person who asked for it. If that person left, test carefully because the app will tell you when you get it wrong and it won't do it politely. And now the surprise. There's always one. An app that works fine that nobody on the identity team has ever heard of. A department head set it up with a vendor. Someone added a trust to your farm years ago, and it's been running quietly ever since. Finance runs a monthly close on it. Nobody knows. The report catches it only if the window is long enough. So don't rely on one source. Compare the trust list, the activity report, and a short survey of business owners where those three disagree. You found something worth a conversation. When the inventory is done, you'll have every app in a bucket, every claim rule explained, and every owner named. Then you can plan the cutover retiring ADFs the cutover sequence. Now the order of operations. Start with the part you've mostly finished. Move your Microsoft three hundred sixty five domains from federated to managed. By now, the staged rollout has done the real work, so this step is just the formal switch. Convert one domain first, ideally a small or secondary one. Watch the sign in logs for a day, then convert the primary domain and pick a quiet window, because the change can take a little while to settle across the tenant. Once that holds the apps, Don't move them all at once, move them in waves and build each wave from the buckets you made during inventory. The first wave is the easy ones. Modern apps with clean Saml or OpenID connect support and a few simple claims register each as an enterprise application, map the claims and assign a pilot group. Let those users sign in through entra ID while everyone else keeps using the farm. Same trick as before. Two paths in parallel test, like the app owner would not like an admin sign in. Open the thing people actually use. Check the claims that arrive because an app can accept a login and still show the wrong name or the wrong role, or no access at all. Ask the owner to confirm it there. Yes is the exit criteria, not yours. The second wave takes the harder apps. The ones with translated claims rules give each its own test window and its own rollback. And the third wave is whatever's left. The replacements and the stubborn ones. Some of these will run past your planned date. That's normal. And it's fine as long as you say so early. Then retire the apps in the third bucket, the ones nobody uses. Disable the trust first and leave it disabled for a few weeks. If nobody calls, remove it. Now the Other decommission and the order matters. Take down the web application proxy servers first. There the internet facing piece and once no external sign in depends on them, their pure attack surface pull them out of the load balancer, watch for a week, then shut them down if the sign in logs stay quiet. You've confirmed that nothing outside needed them. Next, the farm itself stopped the ADFs service on the internal servers. But don't delete anything yet. Leave the servers powered off but intact along with the database and the configuration backup. If an app you missed starts failing, you can bring the farm back in an hour instead of rebuilding it. Only after that comes the clean up. Remove the relying party trusts you no longer need. Retire the certificates, the token signing one included, and take the calendar reminders with them. Then DNS remove the public record for the Federation service name and the internal one. Do this last because a record that points nowhere is harmless. While a record you deleted too early turns a quiet problem into a noisy one. Through all of it, keep a written fallback one page which step you're on, what you changed, and exactly how to undo it. Keep that page current until the final shutdown and don't count the farm as gone until the last server is deleted and the team has signed off. One more thing, and it's the requirement that keeps some tenants on ADFs longer than they planned. Smartcards and third party MFA for smartcards. Check certificate based authentication in entry ID, you upload your certificate authority, configure the rules that bind a certificate to a user, and the sign in works without a farm tested with real cards and real readers first and tested on the devices people use, not just the ones in your lab. For third party MFA, look at external authentication methods your existing provider plugs in as an MFA option, and entry ID stays the place where the sign in happens. Confirm that your vendor supports it before you commit to a date. If they don't, you have a real blocker and the farm stays until you replace the product or the vendor catches up. When the last server is gone and the logs stay clean, the sign in path is finally yours, and that changes what failure looks like. Resilience designing for the day the sync server dies. Let's talk about what actually breaks when the sync layer stops. Most people expect a blackout. It isn't one. Users who already exist keep signing in their licenses, hold their mailboxes. keep delivering. The cloud has its own copy of everything, and it doesn't phone home to check. What stops us change. A new hire gets created in AD and never shows up. In entra ID, a person leaves and the account stays active in the cloud. A password reset goes through on premises and the hash doesn't follow. A group membership changes and the app that reads it keeps the old answer. Nothing crashes. The two directories just start drifting apart quietly, one mist cycle at a time. That drift is the real failure, and the longer it runs, the more expensive the cleanup. So the first design question isn't how do we prevent an outage? It's how fast can we get a working engine back for connect sync? The answer is the staging server. It's a second install configured the same way running in staging mode. It reads from AD and builds its own picture of what it would export, but it doesn't write anything to the cloud. When the primary dies, you take the staging server out of staging mode and it becomes the active one. The catch is that it only helps if it matches the primary rules. Filters scope version drift between those two is its own quiet failure, and it tends to show up on the one day you need it. So treat the staging server as a real asset. Patch it. Compare its configuration to the primary on a schedule. Microsoft ships a tool for exporting and comparing sync settings, and it's worth using every few months, not once. Cloud sync works differently, and that's the point of the design. You install several agents and they all stay active. Each one can take work. If one server goes down, the others carry on and there's nothing to promote. The configuration lives in the cloud, so you can't lose it with a host. That's a real structural advantage, not because the agents never fail, but because failure of one is a non-event. Even so, resilience isn't a feature you buy once. It's a procedure, you prove. Here's what usually happens. A team builds a staging server, writes a recovery document, and files it. Two years later, the primary fails. Somebody opens the document and it references a server name that no longer exists. A service account that was rotated and a sequel version nobody runs. The plan was real. It just was never tested. So tested. Pick a quiet window and fail over. On purpose. Promote the staging server. Watch a change flow, confirm the export, then fail back. Time every step and write the real numbers down. If it takes forty minutes, you know it takes forty minutes. If it doesn't work, you found out on your schedule instead of the outages. 01:03:44 Speaker: Back up the configuration to separately from the server for connect sync. That means exporting the settings and keeping them somewhere that doesn't depend on the host. If the box is gone and the settings went with it, you're rebuilding from memory for cloud sync. Note your scoping filters and mappings in a document. Anyway, the cloud holds them, but a human still needs to know what they were meant to do. And then the part. Most teams underestimate time to detect a sync server that's down for ten minutes is a footnote. One that's down for ten days is an incident. And the difference isn't the failure. It's who noticed and when. If your first alert is a user saying their new colleague can't be found, you've already lost a week. Uptime on the server tells you almost nothing. A machine can be perfectly healthy while the sync it runs has stalled, errored out, or stopped exporting. What matters is whether data is moving, whether the last successful sync was recent, whether changes made today appear in the cloud today. That's a monitoring problem, not a hardware one. And it deserves its own treatment because most of the damage happens in the gap between it broke and somebody new. Monitoring sync health and catching failures early. Start with what Microsoft already gives you for connect sync. That's interconnect health. You install a small agent on the sync server and it reports back to the cloud sync errors, latency, the time of the last successful cycle, all visible without logging into the box for cloud sync. The equivalent lives in the intra admin center. The provisioning logs show every object the agents touched, what changed, and what failed. Agent status sits right next to them so you can see which hosts are connected and which went quiet. But a dashboard nobody opens is just decoration. So build alerts and keep the list short. Three of them cover most of the damage. First stale sync time. If the last successful sync is older than a few cycles, somebody gets paged, not an email that lands in a shared mailbox. A page connect health can send this for you, and with cloud sync, you can pull the same signal from the logs into whatever alerting you already. Run. Second export errors. An object that fails to write is rarely alone. One duplicate address becomes forty alert on the first error, not the fortieth, and you fix a data problem instead of a backlog. Third, agent disconnects with cloud sync. One agent dropping is a non-event for users, but it's also how you slide from three agents to one without anyone noticing. Alert when the count falls below your target, not when it hits zero. Now the failure. That looks fine. Everything is green. The service is running. The last sync was four minutes ago. And yet a department changed managers on Tuesday. And the cloud still shows the old name attributes stopped updating and nothing said. So this happens. A filter gets edited. A mapping breaks after a schema change, a permission on the connector account gets trimmed during a cleanup. The sync keeps running because technically it succeeded. It just stopped carrying that one thing. Green status measures whether the engine ran. It doesn't measure whether the data arrived. So test the data. Pick a Canary account, something harmless in a test OU once a day, a script changes one attribute in Add like a description field with a timestamp. Then it checks the cloud copy after the expected sync window. If the value matches, the pipeline works end to end. If it doesn't, you know within a day instead of within a quarter. It's a small script and it catches exactly what the dashboards miss. Add a second check for counts. How many users does Addy say are in scope and how many does entry ID hold? They won't match perfectly, but the gap should stay stable when it jumps. Something moved. Then the part that isn't technical somebody has to own this. A named person with a backup who reads the alerts and knows what normal looks like. Without that, the alert fires three people see it, and each assumes another one has it. The incident lasts as long as the silence does. Give that owner a run. Book one page per failure type sync stalled. Do this. Export error spiking. Check that agent missing. Here's the restart order. Write it for the person who gets paged at two a m and has never touched the server, because someday that person will be you tired and review it every quarter. Read the run book against reality server names, change accounts Get rotated. A runbook that describes last year's environment is Worse than None because it sounds confident. Treat the sync layer like production. Because it is. It decides who can sign in and what they can reach. Which raises the other side of that coin. The same machines that carry your identity into the cloud are the ones an attacker would most like to sit on. Security shrinking the tier zero footprint. Every hybrid identity component you run is a door. The sync server. The ADFs farm. The pass through agents. Each one opens a path from your on premises network into your cloud. Tenant and attackers know this. They don't need to break entry ID, they just need to own one of these machines because the machine already carries the trust. Start with the sync server it holds the most. It runs under an account that can write to your cloud directory. Connect sync creates a connector account for that, and in the tenant it carries powerful rights over user objects. On the server itself sits a local database, and that database stores the credentials the engine uses to talk. To add. Anyone with admin on that box can pull them out. From there. They can change users, reset passwords, or sync an account they control straight into the cloud. That's why this machine belongs in tier zero. Same protection as a domain controller, not a server the app team looks after. So harden it and start with the basics. Give it a dedicated host. Don't share it with a file roll, a print roll, or that one monitoring tool somebody installed in twenty twenty one. Keep the admin list tiny. A few named people, each with a separate, privileged account. Those accounts log into tier zero machines and nothing else. And nobody browses the web from this server not to download a patch, not to read a forum thread, download the file somewhere clean, check it, then move it over, then lock down the network. The server needs outbound access to Microsoft and align to your domain controllers. It doesn't need to accept connections from the whole office. Cut inbound to the minimum and log what's left. Patching matters here too, but the order matters more. Know what's installed, know the version, and keep the staging server on the same one. An outdated sync engine is a known weakness with a public writeup. Now the ADFs farm. It's heavier and it faces the internet. The proxy servers sit on the edge, taking requests from anywhere. The farm behind them holds the token signing certificate and that certificate is a master key. Steal it and an attacker can forge a sign in for any user, including ones with no password and no MFA prompt. Real attacks have used this. It's a main reason retiring the farm counts as a security project, and a tidy up is only part of it. Pass through agents are lighter, but they aren't harmless. Each one validates passwords against your domain controllers, which means it sees the request in the clear before it checks it. A compromised agent host can be turned into a credential collector. Treat those servers like the sync server, not like utility boxes. Now cloud sync does it fix all of this? It shrinks it. There's no local database full of connector credentials, and the configuration sits in the cloud with the rest of your admin controls. Agents only call out so no inbound door stays open. Fewer moving parts means fewer things to patch and fewer things to forget. But the agent still runs on a domain joined server and it still has rights. And add own that host and you own what it can touch. So the same rules apply just with less at stake. Dedicated host. Small admin list. Current patches. Watched. Logs. Last. Tie this back to the cloud side. The best server hardening in the world won't help if an attacker steals an admin session and signs in as them. Put conditional access around every hybrid identity admin role. Require phishing resistant MFA Fido2 keys or certificate based sign in. So a stolen password or a tricked prompt isn't enough. Keep those admin accounts cloud only, so a breach on premises can't reach them and alert whenever someone changes a sync setting or adds a privileged role, you've now seen the whole picture in pieces. The question is how to turn it into a decision you can take to your team. The decision framework. Choosing your hybrid identity shape for questions. That's the whole framework. Answer them in order because each one narrows the next question. One where is authority? For every population of objects users, groups, devices. Who holds the pen? If the answer is a D and we can't say why, that's the first. Finding authority isn't a technical default you inherit. It's a choice you either make on purpose or get made for you. Question two where does the password get checked? Not which sync tool you run where the check actually happens in the cloud against the hash on premises, through an agent or at a farm. You maintain you covered this earlier, so just write down the answer you have today and the one you want. Question three what must be written back? Go through the list. Device data groups passwords. Exchange hybrid attributes for each one. Name the thing that reads it. If nothing reads it, it's off the list. If something does, it's a constraint and it stays on the sheet until it has a plan. Question four what must survive an outage? Be specific. If the data center goes dark at nine a m, which people still sign in and to what? Say it in one sentence. If the sentence makes you nervous, you've found your next project. Now map the answers to a shape. Most tenants land in one of three. The first shape is cloud sync with password. Hash sync. Authority moves toward the cloud. Passwords are checked in the cloud, and the on premises footprint shrinks to a few agents. This fits when question three comes back nearly empty, and question four demands that sign in survive without the data center. It's the target for most small and midsize tenants and for any multi forest company. Tired of fighting its own topology? The second shape is connect sync with password hash sync. Same sign in story, but the heavier engine stays because something real depends on it. Device Writeback hybrid exchange rules that earn their keep. You're not behind. You're carrying a real requirement and the server is how you carry it. Just treat that server as tier zero and keep the staging copy honest. The third shape is the rare one. Something still needs more than that. Maybe a smart card rule that certificate based authentication can't meet yet, or a third party MFA product with no external method support. Then federation or pass through stays for a narrow slice with a written date to revisit it. Notice the wording. A slice with a date, not the whole tenant forever. If it helps, here's the rule of thumb for each starting point as short steps starting from Federation enable password, hash sync, first run staged rollout inventory the apps, then retire the farm starting from passthrough. Add password hash sync as a standby, then decide whether you still want the agents at all, starting from connect Sync with a clean feature sheet, build Cloud Sync agents pilot one and move in waves starting from connect sync with real Writeback needs. Stay harden and move only the populations that don't depend on it. And starting from. We don't actually know that's the most common one. Spend a month on discovery. It's cheaper than any wrong answer. Last piece. Timing. Not everything needs to happen this quarter. This quarter. Do the work that reduces risk without changing anything. Turn on password. Hash. Sync everywhere. Run it. Document the sync rules. Name an owner for the sync layer. Start the ADFs app inventory because that one takes the longest and surprises the most. Set up the Canary check and the Stale Sync alert this year. Do the moves stand up cloud sync for the populations that qualify. Convert domains to managed. Migrate apps in waves. Shut down the proxy servers, then the farm and decide object group by object group where authority should live. Notice what that sequence does. The first list is mostly free. The second list is where the effort goes, but the first list is also what makes the second one safe. Now you can bring this to your team as a set of answers, but someone above your team still has to sign off, and they won't ask about agents or hashes. They'll ask what it changes for the business. The executive view what this change is for the business. Leadership doesn't care which sync engine you run. They care about three things what breaks, what it costs, what it blocks. So say it in those terms. Start with the servers. Every machine in the identity path is when somebody patches on a weekend a sync server, a staging copy, a Federation form a pair of proxies, a handful of agents. Each one has a certificate, a service account, and an owner who may or may not still work here. Retire the farm and the proxies and a whole class of after hours calls simply stops. Nobody gets paged because a token signing certificate expired on a Saturday. That's not a feature. That's a quieter on call rotation, then onboarding. In most organizations, a new hire starts in HR, becomes a ticket, lands an ad, waits for a sync cycle, and shows up in the cloud later. Three handoffs. Each one has a delay and a person who can forget. When authority sits in the cloud, the chain is shorter. The record is created once where access decisions are made. Groups, licenses, and reviews all work from the same object. Same for leaving a departure is one change, not a change that has to travel through a server first. Next the audit. An auditor asks a plain question who can change who has access to our cloud? Today the honest answer may include a server, a database, a connector account, a farm, and the admins of all four. That's a long conversation with fewer components. The answer gets short, and a short answer is easier to prove. Fewer privileged paths means fewer controls to document, fewer exceptions to explain, and fewer findings that come back every year. Now, the one executives are hearing about from every direction copilot and AI in general. These tools don't create identity problems. They expose the ones you already have. Copilot respects what a person can already reach. So if group membership is stale, if a lever still has access for three days, if nobody can say who owns a set of permissions, the assistant will faithfully surface all of it. Clean identity data was always a good idea. Now it decides what the AI is allowed to show and to whom. That's the argument that tends to land, not we should modernize, but we can't safely switch this on until our identity data is trustworthy. Then cost. And be careful here. If you frame this as a licensing question, you'll lose. Licenses are a rounding error next to the real numbers. Frame it as risk. What does a day of failed sign in cost the business? What does one compromise sink server cost and how likely is it compared with last year? Put a figure on the outage you already know could happen. Then show how many of its causes disappear. The saving isn't on the invoice. It's in the incident that never gets written up. And be honest about the price of the project. There's effort in discovery, in app migration, in testing and in communication say so a plan that admits its cost gets approved more often than one that pretends there isn't any one more point because it's the one they'll test you on. Ask for decisions, not just money. Who owns the sync layer? Who signs off on moving authority? Who can accept the risk of leaving something on federation for another year? Those are leadership calls. The project stalls without them. But even with the right sponsor and a clean plan, hybrid identity projects still go wrong and they tend to go wrong in the same few ways. Common failure patterns in hybrid identity projects five patterns You'll recognize at least two. The first one is treating the tool swap as the whole project. A team installs cloud sync, watches objects flow, and announces the migration is done. But the sync engine was never the hard part. The hard part is everything that leaned on the old setup without telling anyone the sign in path, the right back, the apps, the scripts. Swap the engine and leave those alone and you've moved a box. You haven't changed the model. The second pattern is skipping the app inventory before retiring. ADFs it looks safe. The Microsoft three hundred sixty five domains are managed. Sign ins are healthy. The logs are quiet, so the farm gets shut down on a Friday. Then Monday morning. Finance can't close the month because a vendor portal still pointed at a server that no longer answers. Nobody on the identity team knew it existed. The report would have shown it if somebody had run the report across a full cycle. Third, moving authority without checking exchange attributes, somebody flips a group or a user to cloud managed and the change looks clean in entry ID, but the mailbox attributes still live in on premises ad. Now the object that owns them and the object that edits them are in different places, and admin changes an alias in one console and watches it quietly not happen in the other. Nothing errors. The two sides simply stop agreeing. Most of the exchange work in this whole topic exists to prevent this one moment. Fourth, no tested rollback. Every plan has a rollback section. Very few have a rollback. Somebody has actually run teams right? Restore the old server and never check that the server still boots, that the database is intact, or that anyone remembers the service account password. The rollback only gets its first test in the middle of an incident with the CIO watching. Run it once on purpose. On a quiet afternoon, write down how long it took, and the fifth is the quietest. The assumption that it works today means it will keep working. A sync server that has run for six years feels permanent. It isn't. The operating system ages out, the engine version falls behind and old versions stop being supported. A certificate expires. The one person who built it moves on and takes the only copy of the knowledge with them. Nothing is wrong today. That's exactly why nobody schedules the work. Stable is not the same as safe. It just means the failure hasn't picked its date yet. Notice what these five share. None of them is a bug in a product. Each one is a gap in the plan. Something unlisted, untested, or unowned. The tools did what they were designed to do, so the fix isn't a better tool. It's a longer list, an honest test, and a named owner. Conclusion from navigation to context. So here's the argument with the nuance it earned. The tool you pick matters less than you think connect, sync, or cloud sync. Both can carry identity into the cloud. What matters more is who holds the authority, and how many single points of failure sit between your users and their sign in. Move authority on purpose. Remove the servers that can take. Sign in. Down with them. One action for this week. Make a list of everything that depends on your sync server and your ADFs farm apps scripts Writeback features sign in paths. Just the list. You'll learn more from it than from any plan. If this episode helped leave a review, it helps other admins find an identity episode before their own outage does. And connect with me, Mirko Peters on LinkedIn and tell me what to cover next. Because somewhere in your environment, there's a server nobody remembers building, and it's the one that will decide your next outage. Closing sponsor segment. One more note before you go. Whatever identity path you choose, the cleanup comes first. Clean names, clean addresses, clean attributes. That's true for sync projects, and it's just as true for any Microsoft migration that follows. If a mailbox move is on your list. Stellar Migrator for exchange is one tool people use for those jobs. Thanks for listening. See you in the next one.