Picking which Azure AD Synchronization Technology! AAD Connect vs Cloud Sync

hey everyone in this video i wanted to walk through the options we have to synchronize objects between our active directory domain services environment ie ad and our azure ad environment because we do have a couple of options now as always if this is useful please like subscribe comment and share and hit the bell icon to find out about new content if we think about a typical organization today it has its active directory instance now it may have multiple active directories may have multiple domains in one forest it may have multiple forests but for now we'll think about hey we just have this active directory now when i talk about active directory remember it's basically domain controllers that hold that content and those domain controllers could be on premises they could be in is virtual machines it could be a mixture in a hybrid environment it really doesn't matter so we have our active directory and then we think about well we have our azure active directory instance and typically most companies will just have a kind of a single azure id and services like office 365 dynamics 365 or azure subscriptions many other third-party applications will trust our azure ad as its identity provider because while ad supports things like kerberos and ntlm that's not super useful for those more cloud-based sas applications they want to talk saml uh oid connect a wharf 2 etcetera which is what azure detox so i have my accounts i can think about in my active directory my users are used to using that account now yes i could actually go and create separate cloud accounts up here but that would be a lousy experience for the end user so we don't really want to do that so we really want to do is give the users a pleasant seamless experience so we want to be able to synchronize the accounts really from ad up to azure id that that's really the primary flow we have today and so there were two options we have for this now the first option is azure ad connect now this has gone through a number of iterations from dur sync to azure adsync both of those are no longer supported so what we currently have which is azure ad connect so i can think about i have this azure ad connect now once again this can run on premises it could run in an is virtual machine it just has to have network communication to the domain controllers for the domains that it is synchronizing to azure ad now with this azure ad connect i can have a single instance of this azure ad connect to a particular azure dm we'll talk more about that but in terms of the engine there is one azure ad connect instance that is active so i just have one active instance and this is built on the microsoft identity manager solution so i can think about hey it has the synchronization service that's gonna look very familiar it's not all the features of mim it's very much focused around hey ad to azure id but it has kind of a rules editor i have those capabilities into it so because it's built on that mim it has the idea of kind of hey connector spaces for the directories it's replicating and synchronizing with ied and azure id and then it has its metaverse where it kind of brings all those things together so i can think about this flow is really primarily this way that's the big direction of the flow there is a tiny little potential some data going back but it's really this way 80 is the source of truth going up to azure ad with this you kind of get this 30 minute it is configurable you get a 30 minute sync cycle and you do get a two-minute kind of password hash it's actually the hash of the hash it doesn't just send the regular so if we actually look at this super super quickly we'll see it does look very familiar with a lot of the old kind of old mim capabilities so here i'm running the the synchronization service manager you can see i have various operations and connectors it's connected to both my active directory domain services environment so i can kind of see that right here and it's connected to my azure active directory as well and then we have kind of this metaverse search where it brings all the things together so if i look at a particular user object like mine well i can see this object is really the sum of information from my active directory object and my azure ad object so it's bringing those things together and then we have the sum of those various attributes now also with this we have things like the rules editor i can customize i've added my own custom rule in here so what my rule does here essentially is i don't want to synchronize a particular organizational unit and i'll explain why later on but i'm basically adding a clause to not replicate that particular one but we can customize things about what we're doing we have different join rules we can add there are transformations we can do so here i'm saying cloud no flow to true for those objects so i have a lot of flexibility there's a lot i can do with the azure ad connect so lots and lots of power now when i think about this azure ad connect i can actually replicate from multiple domains multiple forests so i can think about hey i've got another ad over here with its objects and providing this azure ad connect has a line of sight to it hey i can replicate that as well there would essentially be a separate connector space but then i could merge the objects in if i wanted to so you get those choices maybe it's based on some mail attribute or i could synchronize them with separate objects so i have that choice to be able to do that if i have a single account that's represented as i accept single users manifested as separate accounts across domains it can merge them together in the metaverse so there's just one object sent to the azure id i can configure that i have that full control but when i think about azure ad connect remember i have one active instance and multiple domains and azure ads there are some key kind of rules if you ever saw gremlins they're like these keywords don't feed it after midnight etc etc so we have rules for azure ad connect so real kind of one on this whole thing is an azure ad connect instance can only sync to a single azure ad instance sometimes it's hard to talk and write at the same time to a single azure ad instance likewise an azure ad instance only syncs with single aad connect instance so the key point here is this relationship is a one to one an azure ad connect yes i can talk to multiple domains in the forest as i have line of sight but a single azure id connect can only replicate to one azure ad and one azure ad instance will only talk to a single azure ad connect it is a one-to-one mapping so a single azure id connect cannot replicate to multiple azure ids a single azure id cannot be spoken to from multiple azure ad connect so that's really important especially when you think about well what about if i had forests that were disconnected that didn't have a line of sight to this azure ad connect well i couldn't do that today with azure ad connect now i said this is a single instance of the azure id connect what i can do is i can have azure ad connects running in staging mode and i can have multiple of those now this has all the same kind of connector spaces it has its metaverse etc etc but it only reads so it's only getting the sync that way it can't write anything back and likewise it's getting that very small pieces of information back that way it doesn't write any data so it's staying current and up to date but it's not changing anything now the reason we have these is well if this went down if it had a problem i can manually fail over and take this out of staging mode so now one of the staging becomes active i might also when i'm upgrading azure ad connect hey i'll put this in staging mode take this out of staging mode and then i can upgrade in kind of a rolling pattern so that can be useful again this replication from azure id this way is very very small it's really that direction is the primary flow but we do have that ability to have the staging now remember with this azure 80 connect instance or instance is if we have the staging mode we have to maintain these now sometimes the azure ad connect will auto update as there are new versions of azure ad connect it will tell you in the change log if it will auto update for example the v2 currently none of those auto update and i did a video about that saying hey make sure you go and manually update those there is kind of a lightweight sql database it uses if it's built in but if it's a larger environment then hey you're also maybe maintaining a sql server environment now a key point this synchronization remember is essentially creating objects up here and so the user gets this seamless experience if i turn on things like seamless sign on if they're on an a.d joined machine they don't even get authenticated even if it's the same password they just get this very transparent experience but what is the link what's the relationship between these because they are separate objects so the link is this way it is the azure ad object it has a source anchor attribute and the source anchor attribute essentially points to the good of the user now i'm saying the word good it has an object guide but potentially that could change if the users move between domain or forests so by default what azure ad connect will do is it uses an msds consistency guide which it copies the guide into and then make sure that never changes but the direction is pointing that way so the azure id object knows hey this is my ad object equivalent the ad object has zero clue about this it knows nothing about an azure ad object and you can see this so if we jump back over for a second so if we went back and looked at this kind of john savile object again you'll notice there's a bunch of different attributes and what we can see in here is if we quickly kind of we could look at one of the so we see the source anchor so that's the kind of point from the azure ad object so if we look at the azure id object specifically we can see it has this source anchor attribute and then if we actually looked at the 80 object we can see well it has the object guide here and that is actually copied into this msds consistency guide the first time it sinks because then if it change domain change forest it's immutable that msds consistency grid would never get changed so that source anchor points to that value now you might be looking at those saying that doesn't look like the same value if you look again at that kind of source anchor it's completely different format than that object guide and it's just because it's encoded that's all it is and you can actually switch that out so if i actually jump over for a second and paste in that source anchor attribute and we decode it notice then it's at 13 f1 e48 blah blah blah blah well that does now look like that 13 e f1 8 blah blah blah blah so that's the link the link is very much from the azure ad to the ad object the ad object has zero knowledge about any kind of azure ad object so that brings us to kind of rule three so rule three is an ad object can only be synced by one sync technology one instance i i can't have multiple azure id connects replicating the same object maybe to different places and even when we introduce cloud sync this rule still applies so an object can only replicate by one sink instance so what i couldn't do is have another azure ad connect instance and try and replace the same user that is not an allowed scenario that will not work now what you could absolutely do is i could have a subset now you saw the rule i added in my azure ad connect to ignore a certain ou so that would let me do is imagine i go back to my kind of aed again making it a bit bigger because remember in active directory we can have the concept of organizational units so i could absolutely have a scenario where maybe i have two azure ad instances maybe kind of a prod and a test for example and i could have an azure ad connect instance that is configured to only take those ou's to there and then i could have another azure ad connect instance which just takes that or another subset of ou's that's not breaking any of my rules an azure ad connect instance can only sync to a single azure id true true and azure id instance can only sync with a single azurity connect instance true true and an object can only replicate by one sync instance well their different objects go to the different places so this is absolutely an allowed topology so if you have that scenario of different objects i can absolutely do it i'm not breaking any of the rules now there's an entire list of different scenarios you can have and remember obviously you can't have the same upn in different you can't have the same custom domain in multiple azure ad instances so they would have different upns in the different azure instances microsoft has a great document so this goes through the topology supported for azure ad connect and here we can see kind of the things i spoke about you can't have mobile sync servers that are active you could have staging remember i can have multiple forests for a single azure ad connect to a single azure id i can't have multiple azure ad connects talking to a single azure id we talked about that rule it talks about hey you can match users i merge them or not match them and it really just goes through different combinations and it does say hey am i staging a server yes it can do kind of the read but it's not writing to anything multipliers radio tenants hey i could have different azure id connect instances or i could have a subset based on kind of for example ous going to different azure id connects to different azure ad instances this is a fantastic document i've got the link below in the description this video so definitely recommend you take a look at that now one thing i want to stress from a supported topology perspective these rules still apply even if i'm using different clouds so imagine i have commercial cloud i what most of us use and then maybe gov cloud or china cloud these rules still apply especially this one an object can only replicate by one sync instance i could not have in the publicly supported topologies i'm kind of stressing that a little bit publicly supported i could not take the same user and replicate them to an azure ad tenant in commercial and then azure ad tenant in gov if you look at the documentation it will tell you how you'd either have to have multiple user accounts in your ad one to commercial one to gov or i would create cloud accounts for example for gov this is supported public topologies what i would say to you if you are a large company and you do need to use for example commercial and gavel commercial and china talk to your microsoft accounting because there are things that can be done to avoid having kind of those duplicate account scenarios for those larger companies and special kind of agreements so if you are in that world talk to microsoft before you start creating duplicate accounts or creating cloud accounts also today you can't be to be across clouds so i couldn't create the accounts in commercial and then b to b them to gov or china can't do that today either so that's azure id connect and i said there were two technologies so the other technology is azure ad cloud sync and i did a whole video about azure ad cloud syncing so we're going to talk about this pretty quick but then we have azure ad connect cloud sync and here we have the same idea of hey look there's azure id we have our azure ad instance and we still have our on-premises domains that again are personified by domain controllers but what happens with azure ad cloud sync is instead of having this engine running on premises that's built on kind of mim the brain of this service actually now kind of sits up here what we have now sitting in the azure id is this kind of hybrid identity service and it's actually built on top of service bus which is an azure ad sorry an azure feature and what happens now is there's no engine up here it's all running in this hybrid identity service all of the configuration is done via the portal i'll show that in a second but what we now have are these very lightweight agents that run on premises now i have to have these agents for every single domain and i can have multiple of them so for every domain we're going to have these agents now all of these agents establish this kind of outbound connection to the service bus but it's now these separate agents they're all over 443 so i'm going to open up firewall ports inbound 443 is generally open anyway but they can be disconnected now i could have disconnected forests all going into this hybrid id identity service there is like a group managed service accounts that gets leveraged and my other video goes into detail about that but these agents are super lightweight and they're windows server 2016 and above they are domain joined it's not recommended to put them on the domain controllers but you actually can do they are multi-use agents so some of that provisioning where i integrate with a hr system and actually creates objects on prem it's that same agent that does this the boxes i install these agents on should be considered secured in the same manner as my domain controller so i think kind of tier zero but they all auto update the same rules apply to this though an object can only replicate by one sync instance so i can't say hey have this user synced to one azure id by azure id connect and the same user via azure ad cloud sync somewhere else that is not supported you cannot do that now as i mentioned this this is all kind of managed the engine is running in azure and it is not mim based if we go and look at this super quickly and if i just go and jump over if i look at my azure active directory i can go and look at my azure ad connect so we can see in my environment i do have azure ad connect sync running yep and i also have azure ad cloud sync running now how is that possible remember i said the same object can't replicate remember in my azure ad connect i blocked that particular organizational unit from azure ad connect well that ou that i've blocked with azure ad connect is the ou that i do sync with azure ad cloud sync so not breaking my rules the same object is not replicating by different technology instances but here you can see i can scope which users i can manage certain attribute mappings i can see hey i have certain notifications i can prevent accidental deletions as thresholds it's super easy to kind of deploy these various configurations again i just deploy this very lightweight agent it establishes that outbound connection and i'm kind of good to go but those same rules apply a single object is only replicating by one technology i cannot have the same object replicating through multiple israeli connects or multiple azure id cloud syncs or an azure ad connect and an azure id cloud sync but as long as they are unique i could do this so in this kind of picture i drew here with this model another option would have been for example well hey i absolutely could have kind of my cloud sync agent so instead of this or i could have used cloud sync for that oh you which is exactly what i did in my environment so i could go kind of this way so i can totally mix them up and as a document at the end i'll show you that kind of talks through those so we have choices yeah we have azure 80 connect engine runs on premises a single active instance but very very configurable and then i have azure 80 connect cloud sync super lightweight agent the engine runs in the cloud multiple running active active very very simple so with that how do you know which one you actually want to use and there's actually a fantastic document that talks through the options so let's quickly look at these it tells you what is supported for each of the technologies so open the wrong document let's look so actually what this document i meant to open this earlier this is the supported scenarios for azure ad cloud sync so this talks about hey a single to azure ad multiple disconnected forests to azure ad a mixture potentially of azure id connect and then a disconnected forest or a new forest using cloud sync a hybrid environment maybe i'm blocking certain overuse and so it goes through those but here are the features so what's unique here is you can see well look azure id connect cloud sync well it supports uniquely disconnected forest something i cannot do with azure id connect it has to have line of sight it also has those multiple agents and a lightweight installation but then we can see well connect it supports ldap directories which azure ad connect cloud sync does not azure ad connect also supports device objects which cloud sync does not now if we keep scrolling down well i can have customer defined a d attributes in cloud sync which i cannot sorry in azure id connect which i cannot do in cloud sync it supports pass-through authentication with azure ad connect that's where i actually when i try and authenticate to azure id it actually sends that authentication request to domain controllers to authenticate and then send that back so azure ad connect supports that cloud sync does not i can filter on objects attribute values with azure ad connect then there's a whole bunch of things that connect allows like advanced customization for attribute flows right back that's huge write back of password devices groups azure ad domain services support that's where it sends the regular password hash in addition to the hash of the hash then there's things like hybrid right back unlimited numbers of objects so we can kind of get those additional capabilities and azure id connect supports groups with up to 250 000 members so that isn't supported by cloud sync so we can see there are things that azure ad connect supports that cloud sync does not whereas cloud sync has things that connect can't do like the disconnected forest lightweight agents multiple active agents for better kind of failover so the what you're going to have to do is for your environment look at what are the things you are actually using and then once you have those you can kind of make a decision on which one of these is the right fit so when i think of cloud sync because i think the direction is cloud sync that's where things are going this from a timing perspective is a two minute interval so it's two minutes both for kind of users groups and kind of the password hashes so it's actually a bit quicker than the ad the azure id connect which is by default with 30 minutes for the kind of user group etc but so there is no ldap directory support that that may be an issue the bigger one i think is this lack of right back depending on what you're using that that may be a big deal to not have that there is no support for azure ad domain services so that managed domain that i might want created in azure and linked to a network it doesn't support that regular password hash sync so it can't do that there's no pass-through authentication support where i'll use the domain controllers and there are no 250 000 group support i don't know how many people have those but hey i can't do that but on the plus side hey i get disconnected forest support and remember i can mix these i could absolutely have the idea of azure ad connector in my regular domain and i get some new disconnected forest i could use cloud sync for that i can mix them we get those active active agents so if an agent fails on a particular os instance no big deal i don't have to manually do a failover like with azure ad connect and the staging it's just going to carry on working they're lightweight there's no big maybe a sql database i have to worry about maintaining or updating an azure id connect there's very little to do and i really do think of it as kind of the future focus and realize these gaps it has today i would fully expect to go away this is new cloudsync is new over time i would expect those to disappear and for nearly all environments eventually you'd be able to use cloud sync maybe apart from them really complicated environments then you would maybe still use azure ad connect so in terms of which one do you use my guidance would be if you can then this would be my kind of first choice so i would want to use azure id connect clouding so i'm reducing my responsibilities i'm getting these nice lightweight agents i'm getting this active active set of capabilities and i get that disconnected forest support but if there are features it does not have that i need then obviously hey i'll use azure ad connect because that probably does things that i can't do remember the whole point of this is you can mix them so i can absolutely have this scenario where hey maybe i'm using azure ad connect for the bulk of my environment um but i'll use azure cloud sync for maybe a subset of other objects and remember the whole key point here as well if i had some disconnected forest i could use azure ad connect for my main domain my main forest and then i could absolutely use cloud sync to the same azure ad for the disconnected forest i have multiple of those all going here so i get some nice combinations i'm not breaking my rules the rules are about azure ad connect one azure ad connect can talk to one azure id one has ready control to one azure id connect instance i'm not breaking that role this is not an azure ad connect instance i can do this an object can only replicate by one sick instance i'm not breaking that rule these are a different set of objects than that so that's it i just wanted to kind of go through those explain them as a direction you're going to try and use azure id connect cloud sync if you can if it does the features you need over time i would expect those things it doesn't do to go away but maybe you're going to stick with azure ad connect maybe there's certain rich rule sets you're building there's the features that you need today hey just stay on azure ad connect maybe you can start to step in the water of azure ad connect cloud sync but maybe having maybe certain ou's to start testing it and actually have documentation on that and again that's in the description but if you want to try around that it talks about piloting azure ad connect cloud sync in an existing hybrid forest and it has a tutorial on doing that setup so the configuration i had while i was ignoring a certain ou for azure ad connect it walks through how to do that and then limiting cloud sync just to that ou so it walks you through the entire thing these are in the description and so you could go and play around with it but i hope that helped yes two technologies yes this is where i want to go but maybe it doesn't do everything i need right now and so i would use this so good luck and i'll see you in the next video you

Channel: John Savill's Technical Training

Views: 11,004

Keywords: azure, azure cloud, microsoft azure, microsoft, cloud, azure ad, active directory, azure ad connect, cloud sync, identity provider

Id: 9XBcc2b62Ys

Length: 35min 27sec (2127 seconds)

Published: Tue Oct 12 2021