About this talk
This talk focuses on the challenges and solutions involved in recovering Active Directory (AD) after a ransomware attack. The speaker, Josel Manipinto, who specializes in identity recovery, explains the importance of choosing the right backup when AD has been compromised, emphasizing that the most recent backup is often the best choice despite potential security concerns. He discusses the steps required for recovery, including performing a security assessment and securing the environment before re-enabling synchronization with Entra ID. The session covers the need to recreate objects in AD that may have been lost during the attack and the implications of synchronization between AD and Entra ID, including the importance of the immutable ID in maintaining consistency. Ultimately, the talk highlights the necessity of preparation and disaster recovery planning to minimize downtime and data loss.
Full transcript
Good morning. Thank you. So this is a presentation where I will try to explain to you what the problem is when you perform a recovery of active directory and also at the same time what the solution will be and also throughout the presentation I will guide you through the number of steps on how to let's say step by step to fix this problem because it's an important
problem that needs to be taken into account. So why is this not working? Because it's not on So my name is Josel Manipinto. I'm based in the Netherlands working for S per three plus years. Uh focusing on identity recovery and um many other things related to scripting also security. I'm the original writer of the cryptgt password reset script. So any feedback welcome. Um so let's get started.
So this is one of the scenarios because there's another one. Let's say that this is the scenario we are going to focus on today is where Entra ID is healthy. Everything is fine. There's no problem. And for whatever reason, somebody dropped a bomb on your active directory burned to the ground due to for example ransomware. You need to recover. What do you do? Let's have a look
at the the options. A timeline where Enra ID and Active Directory are initially obviously happy together. Somebody dropped a bomb on your active directory and it's ransomware. It's down. You have to recover. What are your options? Let's say that you have a backup of yesterday, your most recent backup. And when you look at the guge above, you will see that the so-called security state posture is in
the red zone. In other words, it's not that good. The other option is you have a backup that's 10 days old. The 10 is just an example for which the security posture appears to be in the green zone. In other words, a little bit better. Which one do you choose? Well, first of all, you have to ask yourself, how do you even know what the security posture
is of your active directory when just having a look at the backup? Unless you have performed a security scan before taking that backup and then reporting it somehow in telling you, hey, this is good or bad, etc. In other words, you don't know. But then again from my perspective it's not even important to understand what the directory within a certain backup. And I will explain why because
when you perform a recovery going back to production consists of two phases. The first phase is obviously recovering the active directory making sure it's up and running again. And the second stage is per uh securing it. But before being able to secure it, you have to perform a security assessment to understand what is wrong, what is bad, categorized in three lists, short, mid, and long-term actions. Obviously,
the short-term actions are the ones that you need to take into account and do as soon as possible before going back to production. So regardless which backup, you have to perform the security assessment no matter what. But then again the question still remains which backup do you choose? Do you choose the one from yesterday where you only have these set of changes? So this is the delta
between for example today and yesterday when the backup was taken or do you choose the the backup that 10 days old for which the changes are obviously more and when you look at the slides you will see that it's about not just about the changes between the recovered AD and let's say the uh AD of today just before the ransomware but it's also about the whichever it
is and any other system interacting with active directory including entry ID itself. So the further you go back in time the more headaches you will have because think about the following. If you go back in time using a backup of 10 days ago you have an active directory state that might not include for example servers application service accounts that were created after that backup. Suddenly those systems
stop working. The same applies with Entra ID. There's there's a huge gap. That gap needs to be closed. In other words, the larger the gap, the more headaches you will have in closing that gap because you don't only have to interact with active directory itself. You have to interact with all kinds of other systems interacting with active directory. So you have to go outside of AD which
is even more work and more difficult. You may even need to have to interact with other teams which makes this even maybe a lengthier process. The security although the one on the right appears to be less good compared to the one on the the left in my opinion is not important. You still have to perform the security assessment and you still have to fix whatever needs to
be fixed and all the stuff that you need to fixed is ad focused. So, it's centralized and it's maybe under your control. And if it's under your control and centralized, it's easier to fix. What are things that you can think of? For example, ransomware. I always disable all admin accounts, create new ones. The default permissions groups, clean everything out. And those are just a few examples of
things that we do by default. And obviously it also depends on whatever comes out of the security assessment because customers did whatever they did within the AD. In other words, no matter which backup you should choose, no matter sorry, no matter what the situation is, you should always choose the most recent backup no matter what. Because the more changes you have to deal with by the backup
that you choose, the more headaches that you will have. The end conclusion in this case would be and also my opinion is to keep the gap as small as possible because it will be the least of your headaches. What's the problem? Either way, choosing one or the other backup, there's still a problem. It's just how big is that problem? Normally, Active Directory is syncing happily with enter
ID. Everything is fine. Now, look at the users and the groups at both systems. four groups, four users in AD, four users, four groups in enter ID and you also have even have a few deleted objects. So, but everything is in sync. Active directory is ransomware. You have to do something. You have to recover. But before you start recovery, you have to do one important thing because
there's a sync between AD and ENT ID. And that thing is to disable the synchronization. Make sure to disable the synchronization because you don't want that as soon as detects that AD is back up and running again, it starts synchronizing immediately because that's where it will hurt. So you have to disable sync. you have recovered your active directory and then when you look carefully at the at
the slides you will see that the recovered AD is missing group one user one group three user three and user and group five are suddenly back again when you look at the the the groups one and three and also the users that means that those objects were created after the backup that's why they don't exist in the backup and number five group five and and user five.
Those were deleted after the backup. That's because after the recovery of the backup, those are back again. Now, if you had not turned on synchroniz, sorry, not turned off synchronization or if you now suddenly turn on synchronization, this is what will happen. Look at the right. The absence of the objects in your active directory will cause the deletion in entra ID and obviously for group five and
user five re reestablish the creation of those objects. So in this case it's not a deletion that occurred in your AD. No, it's the absence of the objects that will cause the deletion and the the system thinks it is a deletion that that uh that caused all this which is not the case. is just a different scenario. And because of this, you will shoot yourself in the
foot. You will lose your own data. And for uh users that are happily working obviously not working against your active directory or systems connected to your active directory but talking about systems connected to enter they are working and suddenly out of nothing they can't work anymore because for example those users were impacted because they were created or provisioned after the backup. Suddenly they can't work anymore uh
using whatever system or application that is connected to enter. And how long does it take? Well, how long does it take for those users to be able to work again? Well, it really depends on how fast you are able to fix all this and re-synchronize. Depending on the size of your environment, the synchronization might take hours and for some organizations even days because you have to reync
everything. So, you have to be careful with this scenario and determine how big the problem is before doing anything. And regarding the object that is being recreated again, suddenly you have an object in Entra which also will have a password and suddenly that object could be misused if that person is able to log on again remotely. So could be a issue. What is the solution? Well, let's
look at the state from enter ID which is for example today in the recovered active directory. As you can see, difference where active directory normally at least normally in this scenario is the authoritative system and entra ID is the non-authoritative system. When you look at the timeline, it doesn't match. Entra ID suddenly knows more than the authoritative system itself. And that's not the right thing. It should
be the other way around. But to make sure that it is the other way around, you have to fix it yourself. It won't happen automatically. So what do do? The key thing is to prevent objects in entra id from being deleted because of the absence of the objects. As I mentioned, enter id knows more than ad. So you ask entra id you perform a query where you
ask enter ID for all the hybrid hybrid objects give all give me all of them users, groups, contacts and computers. And then for all four object types, you check against active directory which ones exist, which ones do not exist. And obviously the ones that do not exist in AD, those are the ones that you need to pay attention for. And you do that by recreating them. Just
recreating them. And then is recreation enough? No, that's not enough. You also had to add some add some glue to it. And the glue is the so-called immutable ID. The immutable ID is a let's call a shared attribute between AD and entra ID that connects together. Entra ID will will be able to tell you what that immutable ID is. And then after recreation of that object in
AD you populate that immutable ID you have applied the glue and then those objects will happily sync together because if you turn on the synchronization instead of deleting they will be rel again as if nothing happened. This is the goal that you want achieve. So moving forward let's go back a little also and discuss authentication mechanisms. If you have a cloud only environment, you're obviously using native
authentication. All fine, nothing here. However, in a hybrid scenario, you have three options. And the three are password hash synchronization. You're basically synchronizing password hashes from AD to enter ID. Is there a dependency? No, there is no dependency with active directory. If active directory is down, everything will happily work and continue to work in Entra. You obviously you won't be able to provision new users. Those will
have to wait. But every existing user will continue will be able to continue to work and do whatever they need to do within Entra and any other system Entra. Some organizations in the past chose the usage of pass through My view pass through authentication I call mini ADFS mini federations authentication because with PTA when ENTRA receives a authentication request it basically redirects the authentication requests to that
agent and then the agent authenticates the user to enter sorry to active directory and then the whole thing goes back again to enter and enter does whatever it needs to do but as you can see when AD is down there is no authentication provider. So because of that the whole fails. There's in other words a heavy dependency in active directory. AD down. If you're using PTA um
then your whole authentication mechanism against ENTRA is also down. Why did people choose this mechanism? The main reason is that they chose this because some security officer said oh I don't want to have any passwords in the cloud because that's insecure. It's a valid reason for many many years ago because those people were never thinking about what if things go wrong what if AD goes down what
then or ID never goes down because all these mechanisms existed exist already more than 10 years ago before attacks ransomware are or became the normal thing and now they are the normal thing it's a default thing happening every day against many organizations. So you have to take downtime into account. You also need to be resilient. You need to be able to counter that attack and do whatever
it needs to be done to first recover secure but also be able to get the punch and still continue to work. The other one is fed authentication. Most of the organizations use ADFS but they also might be using ping federate ping one ping whatever something else octa maybe um same story is true there's a heavy dependency on active directory AD down or even ADFS because norm most
of the times anything in a ransomware scenario anything connected to AD also most of the times goes down including ADFS so AD down there's no authentication it's game over are there ways is to let's say um prepare yourself for this if you're using the second and the third scenario. Yes, there is where at the first scenario you were primarily using PHS as the authentication mechanism with the
last two scenarios. If you use PHS in the background synchronizing those hashes when the bad times come for both scenario two and three I will explain it later. you just switch the authentication mechanism and enter and you can continue to work with the second one. It's a weird one because as I mentioned people chose that oh I don't want to have the passwords in the cloud but
the solution to I'll get out of this is to have the passwords in the cloud. It contradicts each other but then again what is what is your best choice? If you don't have the passwords in the cloud you won't be able to do anything until you're back again. So choose wisely. when active directory is down. Let's look at it from a synchronization perspective. If we are talking
about connect sync because when we talking about synchronization we have two solutions that will help us connect sync which is the on-prem solution and also cloud sync the cloud-based solution for Microsoft basically Microsoft wants everybody to move to clouds sync in in time. So if connect sync is still running if as soon as you think about performing the AD recovery and if AD is down then the
the the choice is really easy. You have to recover. One of the things that you do is disable the synchronization on those on-prem machines. What you should not do is disable synchronization as a whole in ENTRA because if you disable synchronization as a whole in ENTRA, you're basically telling ENTRA id convert all the hybrid identity systems from sorry all the hybrid identity uh identities from hybrid to
native. And when that happens all the data that was synchronized from AD to enter ID is going to be destroyed because it's not needed anymore. And that's exactly the same data that will help you get out of problem. So disabling as a whole is not a good idea. Don't do it. Disable the scheduleuler instead for cloud sync when AD is down. Different mechanism, different solution. The problem
is still the same is you have to disable synchronization. Imagine you have have forest with 10 domains. Then with this one you would see 10 configurations. You would have to disable all 10 of them because every configuration in enter ID for cloud sync represents a domain in a specific forest. So you have to disable all 10 as shown on screen on the right. And important is that
you might think oh let's maybe delete the configuration. Don't delete it. Well at least not yet. I will talk about this later. Don't delete it. authentication. As I mentioned before, if you're using PHS, there's no problem. It will continue to work as if nothing happened. With PTA, by the way, it will hurt if you don't have PHS in the background running or if you didn't have it
running in the background. In other words, those passwords are not the hash the the password, but the hashes are already in the cloud, then it will hurt. AD is done. Well, technically that's not entirely true because the thing that you're missing is a password. So, you could for example provision passwords for everyone. When then what are you going to do? Are you going to give everyone welcome
2025 and then distribute it? How are you going to distribute it through email? Well, they need access to email. So, it becomes a headache. it it's not impossible but let's say it's also not pretty just make sure you have phs in the background running what do you do if you do have phs in the background running you have to convert the authentication mechanism by telling entra stop
redirectory using pta start using native authentication and for that you have to the download the agent start the installation just start the installation by doing so the powershell modules become available and then you use the PowerShell module to disable PTA in the cloud and then that when that happens native uh sorry enter ID will natively take over authentication and then everything works happened with ADFS by the
way fed authentication same story no PHS it will hurt however if you do have PHS in the background like PTA you have to do some work this is more work and it will take more time because when using federated authentication. You are using a federated domain or maybe even multiple federated domains in Entra. Before an Entra ID takes over authentication, every single domain needs to be native.
In other words, you have to convert the federated domain from federated to native. And that will take time. The time that it takes depends on the amount of objects. So let's say that if you have 5,000 objects it doesn't take that much time but if you have thousands and thousands of objects because your organization is huge it will take time and then after the fact when everything
is done you have to make a choice what are you going to do I'm going to keep using PHS or am I going to move back to PTA or maybe again Federite authentication with PHS in the background. My recommendation to you is keep it as simple as possible. Use PHS as the main authentication mechanism for enter ID. Save you all yourselves all the trouble of all the
steps that you have to do in addition if you are attacked maybe again in the future. You know connect sync what do you do if it's down you need to rebuild it. So I was talking about a scenario where connect sync is available but now let's assume done. Do you have an export? Do you have a backup to restore that system? Because natively if you do the
next next ph installation and you use the default configuration, you could be in luck. But if you have heavily customized it and the customization is mainly on these so-called synchronization rules, do you have that export to reproduce that configuration? There are multiple things. The synchronization rules are not just the only thing that you need to worry about. You have to tell connect sync which OUS to sync
from. Where do you get the information? Well, you query active enter ID. This is all about if you don't have any export or don't have any backup. What do you do? query enter ID for all the hybrid objects and then check for every hybrid objects against ID if those objects exist and for all the ones that exist you get a huge list and you create the parent
of the um uh the parent object where they exist and that gives you a so-called best effort list of OUS like I said it's best effort which features the sync status everything the information is visible in Entra it's just not exposed easy to You for example you could use a AAD internals from Dr. Azure ID and by using those tools you could extract the information then you
need to then you know more which features were enabled or disabled but now let's talk about the synchronization rules again when you look at the first three options I explained to you how to let's say reproduce that data if something goes wrong the fourth one the synchronization rules that's not possible only the sync engine itself knows it. So if you don't have an export or a backup,
you have a serious problem unless you were using the defaults, but then again between the versions you might have different different default configurations. So the message here, make sure to always have an export and a therefore a backup of your connect sync server and store that backup in a secure location. The beauty of it is is that the sync server itself already creates a backup on a
daily basis. It's sitting there. It's an export. It's sitting there on the server itself. The only thing that you have to do is get it off that server, put it somewhere safe, and um basically hope never to use it, but then if you have to use it, at least you something. The immutable ID, the immutable ID, as I mentioned before, is the glue between the objects in
ID and enter ID. Where you get that from, which one? Maybe you're using something difficult. Maybe you're using something uh custom. You don't know. But again, using AED internals, you are able to determine which one was being used or if the system is still up for whatever reason, you could get the information from that system yourself. Now, regarding the immutable ID, there's one thing that you need
to remember. Many moons ago when Microsoft released sync, they used the AD object gooit as the immutable ID value. And if you go back a few slides ago where I explained to you that you have to put the immutable ID onto uh the object that you have recreated. That's something that you must be able to do. However, when you look at the object gooit, the object git
is a systemowned attribute. And when it's a systemowned attribute, you cannot manipulate it in any way. So you create a new object, it gets a new object ID. Sorry, object gooid. You can't change it to the old one. In other words, if you have the recovery and you're still using the object, you have to perform that migration step from object to the MSDS consistency. The MSDS consistency
good is an attribute in ID on objects that give you the ability to put in whatever value you want. That's exactly when you need what you need. If you get the value from enter and you have to repopulate it on the newly created object when you're performing the migration and if you're using federation, the wizard will do this for you because it needs to be uh also
changed in the so-called claimed rules within ADFS. If you're not using the wizard or some other uh thirdparty federation system, you have to do this manually. One of the things to remember is is make sure that these steps if you're still using the object that these steps are already done before any attack before any recovery because you will still need to do it eventually. Make sure to
do it as soon as possible if this. And obviously at the end this syn the the connect sync server will always ask you hey do you want me to enable synchronization the answer is always no. You have to fix stuff first before enabling synchronization. Looking at the synchronization at least for connect sync servers I looked at all four object types users groups contacts and computers and in
a normal scenario this works perfectly. But like I said, I also look like to look at the scenarios. But what if it goes wrong? What happens then? And then I found these let's say call it misconfigurations. And this what I found here by the way is based on a default configuration. So if you have customized your configuration in terms of synchronization rules for connect sync evaluate what
you see on screen and how and also how you would need to change whatever you have to make sure that everything works. So this is based on a default configuration because I also know that many have all kinds of custom stuff in in their synchronization server. So this is for the um users. This is what I found that was missing wrong or misconfigured. When we look for
groups, this is what I found. Not something drastic, but it was missing. Looking for contexts. Well, I don't know why this was so wrong, but this is what is missing. This is what's wrong. Quite a lot of few things. Context might not be the most important objects, but if it is for you, look at this one. And this is for computers. Same story. Also kind all kinds
of things missing. Now the gap analysis. How do you perform the gap analysis? You ask entra ID, give me all the hybrid Entra ID has both hybrid everything syncs from ID for example but also native objects. I don't care about the native objects because those are native those are already managed by enter ID. I care about the hybrid ones that came from active directory. And um I
need to query enter ID give me all the hybrid objects so that I can ask AD what is missing. The thing to think about is but how do I ask ID what is missing? I need to look for something. And when you look at the synchronization, many of the attributes are being synchronized from AD to enter ID. What do you use? Well, there are a few key
attributes that you could use. One is the distinguished name. The object go and the object sit. The distinguished name would be perfect, but only user objects have it. Groups, contacts, computers don't have it. So almost useless. The gooit, it doesn't tell me anything. But when you look for example at the distinguished name, it tells you the OU and the domain. It's it tells you everything. It's basically
what I want. The gooid is again like I said, it's just a number. Doesn't tell you which forest, which domain. It doesn't nothing. It's it's let's say if there's really nothing left, you could use it. But again, there's more. Looking at the object sit, that's the perfect one because the object sit contains of two parts. It contains the domain part and it contains the object part, the
RIT, the relative identifier. And the domain part is the part that tells you in which domain the object should exist or be recreated in. There's only one exception. Context don't have a a sit. So you still have to use the guid um because there's really nothing other nothing else that you can use. So by using that information you will be able to query active directory hey are
these objects existing or non-existing and the ones that are not existing you recreate with the information that you have. One of the things to to to keep in mind is when you are going to recreate the objects it's not about completely recovering the object. That is not the intention because you will not be able to completely recover the object. you are only recreating it. Let's give it
a name, a so-called placeholder to prevent a deletion in Entra because Entra doesn't know all the information that you need because when you synchronize to Entra, all those attributes that are synchronized to enter are based on the synchronization rules and the synchronization rules might sync a number of attributes, might not sync others, there might be filters. So it is not complete again it's just to recreate it
as a placeholder and anything that is missing needs to come from HR system identity management system something else but when you recreate the objects you have to ask yourself a few things when you look at the users in entra were they users in ID or in network persons in ID really five You have to look at the objects. What which one was it? The same for the
group types. Which group type was it? AD knows three group types. Global, local, and universal. Cleaning up is very tricky because like I said, there might be filters that for which data is not being synchronized to enter ID. So you need to be careful about those. Cleaning up might be that you're shooting yourself fixing relationships. Same story. Whatever Entra knows, you have to rep reproduce in active
directory. What what Entra doesn't know, it doesn't mean you have to clean it up in AD because it's very tricky because of for example filters. Where do you get the immutable from? Well, it is exposed for users but not for the object types. But however, using the deersync API, you will be able to gather information to repopulate the attribute in AD. One of the downsides of using
a internals to get that data is that Windows Defender in unfortunately considers it that as malware. So you would need to exclude the folder that you have AD internals on so that you can use it or just pick out the functions that you uh need to do that. Let's skip this one. After fixing everything, basically what you need to do is perform tests. Is everything correct as
it should be? Are there going to be deletions expected? Just out of interest, how much time did I have? Wasn't it 45 minutes? Okay, because I'm surprised it's the time is already over. Okay. Um you have to look at are there anything that's going to be deleted and unchanged is good. You might have changes but then you have to ask yourself is it expected or not. After
synchronizing everything within the sync engine itself you have to look what the outcome is. Are there pending export deletes, ads or updates? The ads are things that are going to be recreated. The deletes are the tricky ones. Is that expected? If it's not expected, don't export because when you perform the export, it's everything is going to be export. The so-called updates, it could be changes are changes
to attribute. But what is the change? A replacement, a recreation, or a deletion of some value. With small environments, this is easy to do using the GUI. However, if you have a very large very large environment, then you have to to use some automation. Then you can use this tool that you uh can find on GitHub to perform an analysis and create a report in different styles
HTML, XML, Excel. And as you can see, it provides you the current value and the new value. And then you can determine are there differences. This was connect. Let's have a look at clouds sync. Cloud sync you cannot perform all those so-called checks that I was talking about. It's basically an on or off thing. There's nothing in between. So before turning it on, you configure the threshold
to one. Meaning if there's at least one deletion, stop the synchronization. Don't even continue. Not even with that deletion. After enabling the reg the the configuration, then you restart. The restart of the the synchronization is do a full sync everything. be patient and pray everything is okay because like I said you have all kinds of checks in connect sync and then evaluate to continue or not with
cloud sync that's not the case is it going to be okay no even if I had fixed everything and I did everything perfect by the book you will still see this email come in saying hey this x amount of objects more than one are going to be deleted and in this case I fixed I had deleted 12 but I fixed therefore 12 users 12 groups and 12
contacts that's why you see the 36 and these are the things the the objects that I listed if I had continued the synchronization all these 36 would still be deleted as I mentioned even though I did everything by the book what is the solution there's a behavioral difference where connect sync allows you to connect the object object to the existing one in Entra. Cloud sync does the
other way around. It first deletes and then tries to fix it. Well, that's a little bit weird. If it's a user, it will be soft delete it, meaning you can unddelete it again. If it's a group, it's hard deleted gone forever. Recreation means you have to recreate also the purpose for that group or configure it. By the way, what is the solution here? For whatever reason, clouds
sync remembers the state of those old objects. So I found out delete the configuration in cloud sync but before deleting it create a backup not manually through PowerShell for example create a backup of the whole configuration then delete it then restore that configuration again as if you are reintroducing a new complete complete new configuration and then with that the whole state is lost and that's exactly what
you want because it will then treat every single object as if it's new and reglue everything back together magically. Don't forget to configure the threshold one because there might still be mistakes for forgot. Passwords users while in this whole scenario users might have changed their password. Check an entra in the log that is mentioned on screen to see which users changed their password and then contact those
users because as soon as AD is going to take over again you might have a mismatch and then people might will be calling the service desk obviously. recommendations. Be prepared for this. It saves you time. It saves you headache and a lot of work because doing this manually, it's almost impossible. It's too much work. Don't think only about AD. Think about everything that interacts with AD or
works with AD. ADCS, Connect Sync, Cloud Sync, ADFS, everything. Think about everything around AD. It's not just about AD itself because today it's a complete ecosystem. Think about everything that you can do if something goes wrong to mitigate any further risk to mitigate any further damage on systems. If you can control that, there might be less damage if the scenario obviously fits. But also post actions. Think
about performing the security assessments. Therefore, the gap analysis also is there a gap between AD and anything else? In this case, enter. As I mentioned multiple times already, make sure to use phs. That's the one that's going to save your behind if your active directory goes down. If you're using something else, uh it will hurt momentarily or until literally everything is back up and running again. And
that might take some time. If you haven't migrated to object GIT yet, sorry, to the MSDS consistency gooid, then make sure to do so as soon possible and automate as much as possible. Automation is the key here. Make sure to back have backups for everything that needs to be restored when needed. So, any questions? Thank you, George. Scary talk, but super interesting. So, we have two questions.
The first one is, how do you convince clients to choose the more recent but less secure version during a recovery? In my experience, management always chooses the safer option. Well, I'm going to assume that the so-called safer option is to do with the security state of AD. Um, I know it's a tough talk because also if you're working with security companies, they will very likely say choose
the most one. It might also be the one that for example two months ago. Imagine two months of changes between back then and now. All kinds. And if you have the choice, let's say from two months ago and the one from yesterday, think about all those changes in between. Everything missing, all that stuff will break. Security in this case, in my opinion, is not the most important
part. It's also the impact on the organization itself. Security is important, but that's the part that I can fix in an isolated environment. Because think about it when you perform a recovery you are not going back to production immediately you have to assess the security and fix it and that's the moment then you will fix the security to the to an acceptable level because you won't be
able to fix everything but then you also have the least changes between the backup and now thank you the other question is is there a resurgence of an open of an on-rem AD I was under impression AD is fading out. I understand this question is as is AD dead? Well, Microsoft obviously wants everybody to move from AD to Entra ID because Entra ID is the shiny new
toy that everybody wants and needs and wants to use. However, Active Directory is in place for many years already about 20 well, it became 25 this year, but it's not going anywhere. Why? Many large organizations are still using it. And before they have transitioned to the cloud, if they're even going to completely transition to the cloud, it will take years because they have a complete infrastructure on
a on based on AD on prem and they're going to migrate everything gradually to the cloud. If you're a small shop, I can imagine that they want to lose Active Directory. I hope this answer the question. Okay, thank you very
