Welcome everyone to our co call Analysts webinar. Are you prepared for the true ad? So Active Directory Disaster. This webinar is supported by St. Paris, and the speakers today are Guido Meyer, who is Principal Technologist at St. Paris YIs, OV Senior Solutions architect at St. Paris and me Martin Kuppinger. I'm Principal Analyst at Kuppinger Call Analysts. Before we jump into the sort of speak details of our webinar, a a little bit of housekeeping on the first poll. So you're muted centrally, don't, you know, need to care about the audit control. We were run two polls concretely, one right after this slide and one after my part of the, the webinar, my presentation. We'll do AQ and a session at the end and at the right side of the events where you'll find this q and a section. And you also find a poll section where you can already look at polls and in the q and a section or when, once they come up in the q and a section, you have the option to raise your questions at any time.
Simple point, if you have more questions, the q and a, the discussion will be way more lively. So don't hesitate asking questions. Recording. We are recording the webinar. We will provide a recording and the slides for downloads relatively soon after the webinar. So that's it basically. And before we look at the agenda and dive into the subject of today's webinar, I'd like to, to start with one poll. And this is about we, where are you in, in deployment of active director or use of active direction product deployment anymore and or Azure Active directory or enterra ID as it is called, as it's called nowadays. So is it only the, the traditional on-premises id? Is it only Azure Active directory slash enterra id? Is it both or none of them? Looking forward to your responses. And so, so if, if we have time, we'll pick up the results during the q and a session. And anyway, the more responses we have, the better it is for a poll.
So we run this for whatever, half a minute. So thank you for, for participating in this. And then I think we can close the poll and have a first look at the agenda. So the agenda of today is split into three, or you could argue four parts. The first part I'll, I'll look at, I would say a bit broader perspective, which is around disaster recovery and, and how to prepare for disaster. And it's more than backup. This is basically the, the main statement here. In the second part, Guido and GK will talk about how to make 80 disaster recovery work. So how do you really get it to a point where you can deal when something goes wrong with how you can deal with it. In the third part then we will start with a discussion between Guido and me about our perspectives, our findings, our experience on that.
And we will also start then sort of gradually shifting into, into the q and A session and pick up questions at any time. So that will be then the third part, which is a bit the longer part. So we try to keep our presentations relatively short today and also have this power of conversational, so to speak, fireside chat. Then later on. So let's start with active directory. And as I've said, we have active directory. On one hand we have id, on the other hand we have a lot of other systems, but active directory is still something which is, it's there, it's in most organizations there's an active directory. But, and I think this is the important point to look at. One thing is it's not the strategic approach for Microsoft anymore. Microsoft clearly focuses on Enter ID and Azure id and so active directory is there, it's supported, but it's not what, what is so to speak the future of it.
But I think this is something where, where we need to be aware of when you talk about active directory. But it's there and I think this is very important from a recovery perspective, and I'll touch on them and it will not easily go away. It's Azure AD enter ID from a Microsoft perspective is the preferred choice. So when we look a bit back, and so from the standard strategy around 2019, it shifted from Azure from AD and lead providing data to Azure ID to standards sync back from enter ID to ad. But it's also, we still have a lot of primary user indication based on AD in many our areas. But again here the strategy clearly is to shift this towards Azure ID to what Enterra id. When we look at the Microsoft strategy, you your organization, you might have a different strategy. You may have a strategy that has a bit of a separate, and here's the big, but it's not that easy.
So it is, we have it, it's here to stay. And in many organizations it is the primary authentication service. Also, because I'm still quite frequently, workplace strategies are built around, we have a Windows system we authenticate against on-premises ad and our workplace approaches closely integrated with this. That also means that it is absolutely essential, for instance, for workplaces functioning well. So it's a also authentication service to other systems very frequently that rely on ad integrated authentication. And so disaster for ad means a disaster for a lot of other systems, depending a bit on your infrastructure and how you fill this up. But there's, in many, many organizations there still is a dependency. And, and by the way, I, I'm, I have a very long ad history, so I've been, I've started my career with or know even before I started it, but I've, I've been working with the first Windows and T systems.
I've been working with the first betas, so the beta versions that the beta versions of the first systems incorporating an id, ADF written been, I've written various books more in the 2000, 2003 timeframe around Windows server. So, but it's, I think there, there's the change. We need to be aware of that, but it also means we still have a lot of dependencies. And so if AD fails, I would even say the majority of organizations, this is a disaster beyond the ad disaster. Another point, and this is something which, which I don't like to see, but it's there. Yes, we have the ad integrated applications, which means okay, that that is fine because then, then you only can use, so to speak, ad to work. But in many cases, AD is also used to say, okay, I have an ad group and this ad group is used for, for authorization purposes factually in other applications.
So we manage entitlements. Why ad groups are sometimes nowadays with AAD groups, this definitely is not a good practice. It's a bad practice without any, I do here it is a bad practice, but it's a common practice. It only will put you in trouble 'cause no one feels responsible for the group. Someone changes the group for his application or her application and other applications suffer from that, et cetera, et cetera. Doesn't make sense, but it's done. So again, there's a dependency and this could be just a deploy time, so things are right or it can be at run time and it becomes a disaster recovery challenge. And then we have let you look at Germany and, and several other countries, we have a lot of manufacturing organizations. So we talk about ot, operational technology operations. Technology unfortunately frequently builds on technology that say has a very long life cycle.
That means there are things around that are not very new, that this is where you'll find easily the Windows seven and before systems, even much older ones sometimes this is where you have a dependency in many, many areas on Microsoft active directory, on premises, which won't change quickly, which won't change quickly in that case, even with, which won't change within the next decade or two decades. So it'll be there. It there's a, a legacy aspect in that and this is here to stay. So to summarize, yes, there's a, a strategic shift, but there's a existing, we can call it legacy. And that is where we need to think about because there's so much still reliance on, on the active, the on-premises active directory that we need to have very, very good answers in place. And this is why we need to think about how can we deal with that.
And where I'd like to start with, and to keep it a bit short, that is we need to think about really business resilience management. So the ability to, to quickly adapt to crisis. And this is a broader thing here, that is, we, we need policies, we need a business impact analysis to understand which systems are most critical and why could they fail. What can I do? Then this is the emergency planning, this is about the organization, it's about a continuous improvement and it's, and this is the, for me, the most important point, it's about tests and exercises because recovery frequently comes, struggles when it comes to, to sort of the, the really concrete case. Because yes, there might be a, there's a backup, there might be a paper which says, okay, this is the way we do it, but no one has tested it or the last test is long ago.
You need to do that regularly, continuously, you know, need to know how it is because it's not only ad recovery, there are dependencies. So what do you recover in which order? All these things need to be tested. So for this business resilience management, there are five building blocks. So it goes beyond B, c, m, business continuity management. It goes beyond the disaster recovery. But these are essential aspects. So we need to, to understand how can we keep our business alive? And when AD fails greatly, then a lot of systems that keep our business alive fail greatly. We need to bring them up quickly. That means we need to have a crisis management, we need to have also a response soon. We need to talk when it goes wrong. But we specifically need to look at the IT service continuity. How can we make this work?
How can we ensure that we know when AD fails we are back very, very fast, which is by the way, true for our all the other CRI critical systems. So when you do a business impact analysis, you'll spot several of these CRI critical systems, but on premises ad without any doubt as part of that. And that means we need testing simulation education, not just running a backup. We need more, we need to know how to act when things go wrong. So plan simulations, education, all these things proven tested. If we don't do that we'll, we are in trouble. So with that, I am my part of the presentation and GI will then sort of follow on that. But before we, before I hand over, there's the second poll for today, which is what do you plan with active directory? So is it, we never used it, you already retired it, you plan to retire it in the next three years or you expect this to run way longer. Looking forward to your responses, we again let it run for some 30 seconds, so don't be shy to provide your response here.
Those are excellent questions, Martin, and I'm, I'm really curious on the answers because you know, planning to get away from active directory, I think that's on everybody's mind, but actually making it happen, that is more challenging. Yeah, I'm gonna start sharing
Gi gimme one second.
Absolutely.
So there, there's one more agenda slide, which does, right now it's time for Guido and Gini and they will talk about how to make ad disaster recovery.
So yeah, my name Guido Meyer, principal technologist for St. Paris, and we basically support all of our clients and prospects in that whole concept of protecting identities both on-prem and in the cloud. And today we're gonna talk about what you've already introduced and we're not gonna talk about our products much, but actually what are the other things that need to be thought about during a recovery? And you touched base on quite a few of those already quickly over to Evgeni before we go into our session.
Yeah, hi, I'm OV senior solutions architect with SIM Paris and after Guido introduced what we do well, yeah, I'm in that organization as well, helping customers and prospects design, evaluate, and implement solutions for active directory protection and disaster recovery.
So Guido and the beginning stage is yours. I'll be back then for discussion and q and a.
Sounds great. So starting to share my screen, you should all see it now and well, we've just introduced ourselves. The topic is, is clear. I'm going to jump to the next slide. This slide basically just summarizes partially of what Martin has already said. How active directory still is and most likely will remain in the center for most companies in their whole identity infrastructure. Most of the synchronization, most companies that that we come across is still where active directory is the leading directory and then sinks into Azure Active directory. And of course that's now called ENTER id. And here you can see that of course we can modernize our slides also quite nicely to make it clear that we also support that newest technology. The point is, it's just the name change, the underlying architecture is exactly the same, nothing has changed. And depending on how you've integrated with intra ID for authentication, you may even be more dependent on your active directory in case you have an outage such as, let's say you're using federation services to access cloud applications, those federation service, let's think of Active directory Federation service ADFS.
Well it requires an active directory that's operational, that's running before you ever get to your cloud resources. And so even your cloud resources or access to those applications could be impacted if your on-prem ad is down. That's why it's so critical as part of the business, continuing continuity planning to ensure that you can recover active directory quickly and to give you a sense of what it actually takes to to, to plan out and, and also justify in front of management, why should you prepare for efforts around active directly recovery? You just need to understand how you depend on it. Yeah, you need to go through a plan of your own understanding your business and its dependencies. And what I have done quite often in the past is go and practice, go go like through a tabletop exercise with clients to understand their reto recovery time objective and recovery point objective.
Quickly here, just showing the definition without going deep in this, but what the business would like from you, how quickly can you recover a service that might've gone down? And typically if the business is of course thinking of their applications, not underlying infrastructure, and they have a particular recovery time objective, which quite honestly is always more or less instant. Yeah, they don't want any outage. And then there's of course how much data are they willing and allowed to lose? And again, typically the answer of the business is, well, no data. Yeah, but we have to be really clear that in a true disaster, what you'd like to achieve regarding RPO or RTO is quite different from what you're able to achieve. Because we're not talking about a failover situation, you know, where you've got a another, you know, in a cluster when one server fails, the failover goes to the other class.
At Hooray, I basically have split seconds fail over time in a disaster that is ransomware bound, you will basically have the situation that nothing is there. You, you are needing to recover from scratch. So it's critical to understand your own dependencies. This table that I'm happy to, you know, it's obviously shared with the slides also the workbook that we've created, it's just a helper there. This is a, a table with an exercise of doing that analysis with a real company. Not naming the name here of course, but this, these are real life exercises where of course the business answered for each of these different services, how much time can they survive until the service is back? And of course in what form? But just take the email service as an example here, which is, which is acceptable to have an RTO for three hours, like a recovery time objective to get mail, at least the mail function, the so-called dial tone function back.
That doesn't mean that you have your old mail data that takes longer, but that you get that function for email service back. The is no acceptance really for longer than three hours. And of course typically no loss, like last transaction is what every business we wants. But in a, in a true disaster, you have to go back to your real backups and that's typically something around worst case, 24 hour and a data loss. Now we could go through this list bit by bit with many more examples. The point that I had to make clear to the business that even before anybody can get to the recovery of be it mail, be it file service, be it even joining new systems, recreated systems to a domain, access to virtual desktops and all of that, before any of that can happen, the active directory had to become, had to come back.
And the active directory of course also has some requirements like hardware to run on or virtual machines to run on. So it's, it's still one of those first elements that you need to think about before you can ever even start the recovery of those other business services. So it is typically one of your most critical services to bring back and what that could look like, and again, not so much on the technical level regarding every step of the recovery, but what does it look like overall generically a disaster recovery plan for your business? It always thoughts that you'd need core infrastructure. So your first question is of course, well where are you gonna build that picture? A ransomware attack where everything has been wiped out? Do you have capacity in your environment to quickly spin up new virtual machines in a cleaned network? That network of course needs to exist.
Those virtual machines need to be built from a trusted source. You don't take something that might've been lying around on a file server that's affected. So even the source needs to be trusted. You have to ensure that that new core infrastructure is built cleanly could be in the cloud. That's actually what many companies do that they do plan to recover that first instance after such a ransomware that they, that they say costs for cloud services doesn't matter. Cost for downtime is much more, we're gonna plan with the cloud, but that also needs to be practiced. Of course the next step in such a recovery plan is typically always bringing your active directory back. And now it depends on how do you actually do your backup, Ken, you gonna talk a little bit more about that on those dependencies, what that actually means. But ideally you are prepared to bring your active directory, even if it's a multi force.
Well multi force too, but a multi-domain forest bring it back within hours, not days, of course not weeks. Yeah, but, but that really depends on how much have you, how well have you prepared, how much have you practiced it? And of course are you trying to do it manually or do you have some good tooling there that supports you only after your active directory is there, you'll actually first before going on with the recovery of those applications, you're going to remediate things that have caused very often the, the downtime that has occurred to you. You know, domain dominance might have been gained by the intruder. You don't want to keep old administrative accounts in your environment. There are remediation steps that go beyond the technology of tooling or scripting that you do. You'll need to do extra steps to ensure that you actually trust your active directory back and then you can start bringing back applications.
You can start reconciliating, other IM applications could be the synchronization to the cloud to enter id, but also maybe some other stuff to SAP or whatnot. But only then the recovery of a business applications will actually be possible. And ideally slowly your business will be able to run again. So it's that critical time of your active directory recovery that actually determines the overall time of your business recovery. And of course that has a question of its own. Yeah, that has a question of its own or you're going to recover from a backup or you're going to rebuild from scratch in the beginning is gonna take on that topic and explain a bit more on those thoughts.
Thanks Guido, because my control control bar disappeared the second you freed the sharing to me. So I've been in both situations in real life incident response and of course the question whether we are to recover our existing infrastructure, our existing directory, or maybe even rebuild from scratch. It's a question that is always getting asked, not just because of bad preparedness state of the organization, but there are some cryptographic secrets in an active directory forest that can be rotated after the fact. So a rebuild from scratch does hold some appeal for many organizations that have been profoundly breached by threat actors. However, if it were only about the user identities in a directory doing interactive log on to some Windows machine, that would be a viable, viable route to take. However, Martin talked in the introduction about active directory groups being used is authorization mechanism. All those dependencies propagate into every single system that is bound to active directory. You have all the permissions, you have all the authorizations. Some applications will handle user profiles internally, but have them linked to IDs that are generated from active directory, like a good or AC, a security ad. So if you decide to rebuild from scratch, then you have tons of cleanup operations to do, which will of course not make your recovery of connected applications any faster.
And it could be a corporate extinction event even trying to go down that route. It starts with having lists of those identities in place. It starts with having lists of applications in place and then in trying to provide the correct authentication and authorization to every application that you are recovering. Having said that, it becomes relatively obvious that being prepared for recovering an existing forest in spite of some cryptographic material, maybe still being available to the attacker after the recovery could put your business in a far better situation for that overall business resilience posture scenario than trying to rebuild from scratch. But the preparation for active directory recovery starts way before an actual event or actual disaster recovery exercise. You have to know your active directory topology, what domains are in my forest? What size sites have I to serve? Where are domain controllers located? Where is authentication authorization actually required by my application?
Especially in those OT scenarios where there is shop floor automation that is bound to ad in very distant part parts of your organization. Disaster recovery passwords, this is always a big topic. Do not store your disaster recovery information exclusively on systems that are bound to ad provide a storage for these password vaults that is independent of your ad. Or the best way would be to make it independent from your infrastructure altogether. Know your name resolution topology and if you're not using ad integrated DNS for named resolution in your forest or in your organization as a whole, then also know how you can access the systems providing that resolution. Because if that's third party, third party hardware, if that's maybe some unique space infrastructure, chances are that that infrastructure might be left standing in, in, in an attack. But you still will have to reconfigure that to accommodate for the your disaster recovery scenario where names may change, where IP addresses may change, where service records may have to be create a new and so on. So know how to access that infrastructure as well.
Reduce the number of o operating system versions. Like Gida said, providing machines from clean source is essential to a speedy disaster recovery in, in a cyber situation, which means the more different operating system you systems you have in your domain controller, zoo or park, then the more, the more clean sources you will have to utilize to rebuild them. Always take a backup of at least two dcs per domain, not because it has any technical advantages to have more than one, but because if you, if you have one, then one can fail on recovery. If you have two, one of them can fail also, but then you have the other one. So take, never take a single backup of a critical resource.
Ideally you will not introduce reinfection just by doing the recovery, by having backed up all the malware that your attacker introduced, introduced into your domain controller operating systems. This would be the case with the classic system state backup, what Microsoft recommends for doing forest recovery. But their guidance is tailored to the situation where your data center went down due to flooding or a airplane crashing on your data center. If a si in a cyber disaster recovery, you can't trust the operating systems not to contain malware and other misconfigurations that may have been introduced by the attacker. So ideally you have a process in place or a tool or both that allow you to recover to clean operating systems instead of reusing the backed up ones.
Know the Microsoft Active Directory Forest recovery, even if the tools at hand allow you to not use that directly and manually, you still find the white paper under the hyperlink here, although docs are being renamed to learn as we speak, but this URL is still valid and will remain so for a couple of years know the steps that the forest recovery requires you to do in order to have a consistent functioning working forest. Because the other steps, the forensic analysis of what the threat actors may have done in your environment, those steps are not covered by this guy's guide. You will have to do those steps in any case. So at least know the functional steps that a forest has to go through to become fully recovered in the, in, in the sense of technical functionality and consistency. And last but not least, you, you've seen Guidos Guido's business impact analysis slides.
It helps a lot to understand how long your forest recovery will actually take even if you exercised the process many times. And even if your tool is able to fully support that process, it still can be hours in a, in a larger environment or maybe even days if the forensic analysis and clean cleanup take take longer than maybe expected or hooped. And in all that time, the other applications can't start with their own recovery. So by providing the other application owners with the estimate how long 80 forest recovery according to to the plan that you have put in writing and test it, you will help them plan their own recovery steps in accordance to that timeline.
So what steps will a forest have to go through to become a fully supported recovered forest? There is a plethora of steps if you print out that guide, which you should do if you intend on using it for manual disaster recovery, which I can't recommend, but should you be planning on using that guide in practice, you will be holding over 90 pages of paper once you've printed it out. And there are hundreds of steps to be done and most of them require the, some sort of result verification and health verification. And once you go through all of these, you still haven't done forensics and cleanup. So try and use a process that helps you parallelize that helps you condense the time needed to run through these steps to a minimum. Of course, as always in it, if there are steps that can be done in parallel, then you should use scripting automation or professional ad recovery tools such as those provided by Semus. And with this I would like to give back to Martin.
Thank you very much for the insights. It's, it's really fun. You know, I'm, I'm not that close anymore, let's say, let's say to to really working hands-on, on the active directory world. But there are so many things I remember I resemble from, from the past and I, I just can can fully agree with you. Before we dive into our conversation, just a quick look at the agenda, we are right now going to the Q and A session. Please enter your questions. We have a few here already, but we will pick up the questions whenever it's appropriate and move forward that way. And I think there surely will be be a couple of questions because it's one of these topics that are always, I believe very interesting and and very compelling. So yeah, so when, when we look at this entire thing, so you, you talked about days and I think what I liked with your presentation was really this dependency aspect as well because I think this is something we, we really need to be aware of and, and these dependencies then, then go further and further than you.
I just did some work on, on SAP automation recently, and again there is it, you need, you have massive dependencies because the operating system needs to be up that so that the database can be up so that, and then you have clusters, et cetera, which nodes up and down first and all that stuff. It, it's tricky and it needs to be well sought and planned and it needs to be still what I'm believe it's needs to be tested and it needs to be automated. And I think this is really where, where from my perspective also tools, tools come into play. And so I, I'm, as I've said, I think we are, we are all on the same page here a bit. And I like Guido, I like your, your your hints on the RTO and RPO and, and by the way, when you look at the material, the, the German BSI, the IT security government agency provides on business impact analysis, you will find even decks that help you creating this and, and that are working along the same terms.
So it's really proven and, and I think we need to be aware. The, the problem is the disa the biggest problem is the disasters when you're not well prepared, that's it. 'cause then it's where you lose endless time. And when, when I hear just I think this week and, and, and the state of rittenberg in south of southwest Germany, another, another town became, so the the, the administration became the local government, so to speak became victim of ran ransomware attack. Yeah. And then they're talking days, they're talk and, and I, I would dare to say most of these are aren't well prepared and we can't do it. And this is well spent money. I believe
That's the reality that we see in any incident response that we're also involved in Martin. And you, you've, you've basically highlighted it quite a few points there already, how people can better prepare. It's the one thing is raise awareness. Yeah. But without testing, doesn't matter how much awareness you have if you don't test your plans and ensure that they run smoothly. And that starts with who actually are the people that make decisions. Yeah, it's, it's a, a, a huge thing to, to get in touch with the right people at the right time to actually move forward. Who gives the goal that somebody can spend thousands of dollars either on new hardware or on, on utilizing systems in the cloud to ensure that recovery process can begin. But before that, what, how we ensure, you know, what does the insurance give us as part of, you know, activities that need to be followed for forensics, you need to keep a lot of systems still down and in the state that they are, you can't just overwrite them and recover back on some existing systems just because you want to, if you want to ensure that you know that, that you abide to the insurance requirements and, and those things.
So you have to know in which, in which mode of operations does such a recovery activity even begin? And most don't go through that exercise. And it begins with even calling the insurance to understand that you have the right number and the right contact to understand that they will now help you and they give you the goal to continue with other technical recovery steps.
Yes, I think that that's a very fair point. And so given that we have already a couple of questions here, I'd like to grab one of the questions. Yeah. So what were the most surprising moments for you in past instant response cases that included active directory recovery?
I'll, I'll give one example then
The stories from the trenches as you would call
The stories from the trenches. If, if actually I've just answered that. If, can you start on this one because there's, there's plenty that we can speak about and we could fill a whole program. But you go first and and I'll take the next one.
Yeah. Well the most, the most surprising incident response in my career was where every, every monitor was read and every system was down. And when we got called in to, to actually do incidents, res incident response and disaster recovery, we found a situation where systems were heavily compromised. And then once we looked, once we looked further and tried to raise some people from operations, they were all completely calm and relaxed because everything was working. And then it turned out that, that the system that actually got compromised was a development environment and the security operations forgot to switch monitoring from the development environment to the live environment. And the live environment wasn't affected at all. So there wasn't actually a, there was, that's a positive surprise wasn't the case to, to, to, to, to start raising people in the middle of the night. Yeah.
But it was the best case scenario. Yeah. I would dare this
Case. Yeah, absolutely. I'll give you another example. That's, that's, that's let's say more for what, what, what's out there in reality, A company completely wiped out all of their VMware infrastructure and of course all of the snapshots and the, the backups on systems that were dis spaced also the replica of that was completely gone. And the company only had those dis space, active directory backups. So they fought for two days. They basically didn't have anything. And we, we can also only support if a backup is available. And for two days the, apparently the one person that knew that they actually did also have a domain controller running as infrastructure as a service VM in Azure was known. And, and then they, and they realized, oh that thing, once they realized it did have actually a different backup, you know, VM level backup from Microsoft, which saved their butt literally because that one was the one that was able to be used for recovering.
And in this case, again, they were luck lucky in many census 'cause they only had a single domain forest. You can recover that from that single backup. And then we cleaned it, got the malware out through our tooling. But you know, it's still surprises, there'd be many more, maybe just highlight one where the client was not yet completely taken down and we actually recovered the active directory in isolation to harden it, clean it and bring it back into production to, to basically get rid of the intruder by having active directory cleaned and hardened back into production. Of course at, at a high speed process doing that. But finding a a, a surprise such as everybody was able to reset everybody's password. That's nothing that you want in a secure environment. No,
But, but by the way, I think one thing we also should be very aware of, and that goes beyond ad but includes also some versions of how, how you run it, having it in the cloud not, doesn't mean you don't need a backup, you don't need a recovery approach. I think there, there was, which goes beyond or a bit outside of, of ad recovery, but I think which is a good sample there, I think three years, four years ago there was a fire in a, in a data center of a French infrastructure as a service provider. And the interesting numbers I've heard is that 90% of the, their tenants didn't have a separate backup. So they just thought, okay, if it's there in this data center, I'm safe. And that is I think something we should be always aware of. You, you need, I, I personally believe you need a backup of these things outside of that provider so that you have sort of a double security.
And this is I think also very important to keep in mind but maybe and I think fits, fits well also into what you're currently talking about. There's a question that is about, is a backup of the compromised state of AD and systems good to use as forensic forensics instead of keeping the live one down in the state to investigate. I think that's one part of the question. The part I'd like to add you, you touched it to a certain extent is what does it mean in preparation? Because if you don't use your current systems, you need other systems.
Yeah, that's actually quite commonly done that that, especially if we're talking about virtual machines, you can take, take a copy of that VM disc and and have that for your forensic analysis. If it's physical system, yes, I think it's quite acceptable to have backups. You just need to understand are you in a position to take fresh backups of those systems that then allow you to reuse them. And how far has that intruder gone? Especially when we're talking about physical system. Have they built back, back doors into the firmware, injected back doors into the firmware of that physical system? So I would, I would say in general for most forensics it's actually event log information that that gives most data and active directory of course there's plenty of things of of places to hide from intruders. So yes, it also needs to be analyzed in detail and, but it's not uncommon to utilize backups for that if you're in a position to take good backups.
Okay, so, so maybe we look at the second poll the results quickly 'cause I think this is also very interesting to see. So we had a good number of participants, probably it's biased because we have a webinar that's about active directory. But anyway, if we could bring up the, the results of the second poll, not sure whether it's already visible then, then it's interesting to see that three, three out of four don't have plans to retire or they to to retire ad within the next three months. Three years, yeah. And or so at the end of day a lot will have it around and it'll remain critical as with that. So very simple, if you are not prepared then you still need to have it most organizations for probably couple of years. And so you need to invest in this because even while you add other things, you shift workloads away. As I've said, it's critical for many workloads. Latest when you have OT probably it's more thinking in decades than in years. So thank you for displaying this and maybe let's switch back to our conversation. So what,
What, let's add a thought on that Martin, let's add a thought on that poll result because I think it's, it's important for the participants to realize that Microsoft has sort of at least make made each of us feel that active directory was totally given up. The last force function level that was introduced came with the release of the operating system. 2016 little changes were added in, you know, in through updates, security patching in also around 20 19, 20 22. But there is hope for, you know, 2025 is a new version coming. So Microsoft hasn't give up, has not,
Anyway we, we don't have super much time anymore so I, I'd like to pick at least three of the questions we already have in here and ask for very more concise responses. So the first one is, is there a major difference the resiliency of AAD or enterra id ID versus on-prem ID from a real world incident perspective. So how ransomware resilient should enterra Id be regarded.
You wanna take that?
Yeah, well it all depends on how much, how much access the threat actor actually is able to to acquire. And because there is, with cloud services in general, there is this shared responsibility dilemma. So in case, in case the actor is able to actually hard delete your objects or change, change the environment in a way that it becomes unusual, then the cloud provider will not help you. They will tell you that they can't, we don't know if they can or, or not, but they will not help you because it's outside of their part of the shares shared responsibility.
Yeah, very important. If you use something in the cloud, look at a contract and understand what is provider responsibility and what is tenant respons responsibility and care for your tenant responsibility. There's one more question we can take otherwise we, we really run out of time and that is, it was a bit directed to me but you may add on this, which enterprise this, this enterprise features missing or par partially missing in enter ID compared to AD like operation organizational units, ous, is it really time to shift beyond the difficulty of the migration? How do you see this evolve? I believe it's, it's more a matter of what are your use cases, it's a matter of transition. What do you do here? And and notably the concepts are different but it's, for instance you can use custom attributes so you can to sort of a record add information like that.
The idea, the structure is different because, because we know that ad still relied on the ld a idea which goes back to DAP, which is really stone age and very inflexible as we also know for for many use cases. So it's, it's legacy and AD enter ID goes more into a graph approach of way more flexible approach overall and has a different, a bit of a different target by the way. It's really an an identity system and to me there's no doubt that Enterra ID must be owned by the IM department, not by the infrastructure department from that perspective. Anyway, something short to add here.
Yeah, well I think important is that that enter ID is more or less a flat directory, but Microsoft has of course with administrative units and even restricted administrative units, try to try to give some level of structure in, in the sense of delegation of duties to different teams in enter id. That's often the reason why organizational units were built in on-prem active directory. But it's different and of course it's different protocols. So even if you want to just shift stuff across, it's an application modernization story. So you can't just take your legacy business apps, even if you wanted it, if they still require krus or a worst case NTLM authentication for your users, intra ID won't help you. Yeah, so it's for modern apps, that's where in ID comes in. It has new challenges from the recovery perspective and that might actually be a subject for a totally separate discussion.
Exactly. I think that's exactly the case by the way, stories for trenches around ot. I recently talked to the customer, he said here, you know, I would be happy if I only had NTLM. I still have some LMM protocols around in that environment. So this is really, things are moving slower here. So I quickly share my screen again just for a, for a minute. So before we end, I I just want to very quickly highlight, we have two next year, our European Identity Cloud conference coming up. Again, the most relevant identity gathering in Europe at least. So don't miss this. And that also brings me then to, to one more slide, which is this one which is about saying thank you, thank you to all the attends of this and call webinar. Thank you to St. Paris for supporting this and call Analyst webinar. And thank you spec specifically to you and ney for all your insights. We probably could have talked for, for another hour, easily, probably longer. So we are a little bit, little bit limited in time for the webinar. I hope it was interesting to everyone joining us today and hope to have you back soon at one of our, another next upcoming webinars. Thank you.
Thanks for having us. Thank you very much. Thanks for having us.
