Are You Prepared for the True AD Disaster?

Welcome everyone to our KuppingerCole Analysts webinar, Are You Prepared for the True AD, so Active Directory, Disaster? This webinar is supported by Semperis and the speakers today are Guido Grillenmeier, who is Principal Technologist at Semperis, Evgenij Smirnov, Senior Solutions Architect at Semperis, and me, Martin Kuppinger. I'm Principal Analyst at KuppingerCole Analysts. Before we jump into the sort of big details of our webinar, a little bit of housekeeping on the first poll. So you're muted centrally, don't need to care about the audio control.

We will run two polls concretely, one right after this slide and one after my part of the webinar, my presentation. We will do a Q&A session at the end and the right side of the event, so you'll find this Q&A section and you also find a poll section where you can already look at polls. And in the Q&A section, or once they come up in the Q&A section, you have the option to raise your questions at any time. Simple point, if you have more questions, the Q&A, the discussion will be way more lively, so don't hesitate asking questions.

Recording, we are recording the webinar, we will provide recording and 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 start with one poll. And this is about, where are you in deployment of Active Directory or use of Active Directory and product deployment anymore?

And, or Azure Active Directory or Entra ID as it is called nowadays. So is it only the traditional on-premises AD? Is it only Azure Active Directory slash Entra ID? Is it both or none of them? Looking forward to your responses. And so if we have time, we'll pick up the results during the Q&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 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 look at, I would say a bit broader perspective, which is around disaster recovery and how to prepare for disaster. And it's more than backup. This is basically the main statement here. In the second part, Guido and Yevgeny will talk about how to make AD 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, Yevgeny and me about our perspectives, our findings, our experience on that. And we will also start then sort of gradually shifting into the Q&A session and pick up questions at any time. So that will be then the third part, which is a bit longer part. So we try to keep our presentations relatively short today and also have this power of conversational, so to speak, fireside chat later on. So let's start with Active Directory. And as I've said, we have Active Directory on one hand, we have Enter ID.

On the other hand, we have a lot of other systems, but Active Directory is still something which is ubiquitous. It's there, it's most organization, there's an Active Directory. But 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 is, so to speak, the future of it. I think this is something where we need to be aware of when we 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 they will not easily go away. It's Azure ID, Enter ID from Microsoft's perspective is the preferred choice. So when we look a bit back, and so for the standard strategy, around 2019, it shifted from Azure, from AD elite providing data to Azure AD to standard is synced back from Enter ID to AD. But it's also, we still have a lot of primary user authentication based on AD in many areas.

But again, here, the strategy clearly is to shift this towards Azure ID to what Enter ID, when we look at a Microsoft strategy, 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 approach is closely integrated with this. That also means that it is absolutely essential, for instance, for workplaces functioning well. So it's also an authentication service to other systems very frequently that rely on AD integrated authentication. And so disaster for AD means disaster for a lot of other systems, depending a bit on your infrastructure and how you've built this up.

But there's, in many, many organizations, there still is a dependency. And by the way, I have a very long AD history. So I've been, I started my career with, even before I started it, but I've been working with the first Windows NT systems, I've been working with the first datas, so the data versions, the beta versions of the first systems incorporating an ID.

AD, I've written various books more in the 2000, 2003 timeframe around Windows Server. So, but it's, I think there's a 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 I don't like to see, but it's there.

Yes, we have the AD integrated applications, which means, okay, that is fine because 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 authorization purposes factually in other applications. So we manage entitlements via AD groups or sometimes nowadays with AAD groups. This definitely is not a good practice. It's a bad practice without any ado here. It is a bad practice, but it's a common practice. It only will put you in trouble because 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. It 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 could be at runtime and it becomes a disaster recovery challenge. And then we have, let me look at Germany 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 has a very long life cycle. That means there are things around that are not very new.

This is where you will find easily the Windows 7 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 if you won't change within the next decade or two decades. So it will be there. There's a legacy aspect that, and this is here to stay. So to summarize, yes, there's a strategic shift, but there's an existing, we can call it legacy.

And that is where we need to think about, because there's so much still reliance on 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 quickly adapt to crisis. And this is a broader thing here.

That is, 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 this for me, the most important point, it's about tests and exercises. Because recovery frequently struggles when it comes to sort of the real concrete case. Because yes, there might be, 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 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 for resilience management, there are five building blocks. So it goes beyond BCM, business continuity management. It goes beyond the disaster recovery. But these are essential aspects. So we need 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 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 all the other critical systems. So when you do a business impact analysis, you spot several of these critical systems. But on-premises AD, without any doubt, is 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 are in trouble. So with that, I end my part of the presentation. And Gita and Yevgeny will follow on that. But before I hand over, there's the second poll for today, which is, what do you plan with Active Directory?

So is it, you never used it? You already retired it? Do you plan to retire it in the next three years? Or you expect this to run way longer? Looking forward to your responses.

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 really curious on the answers, because planning to get away from Active Directory, I think that's on everybody's mind. But actually making it happen, that is more challenging. I'm going to start sharing. Can you give me one second? Absolutely. There's one more agenda slide, which says, right now it's time for Gita and Yevgeny. And they will talk about how to make AD disaster recovery.

So yeah, my name is Gito Grillenmayer, Principal Technologist for Semperis. 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 going to talk about what you've already introduced. And we're not going to talk about our products much. But actually, what are the other things that need to be thought about during a recovery? And you touched based on quite a few of those already. Quickly over to Yevgeny before we go into our session.

Yeah, hi. I'm Yevgeny Smirnov, Senior Solutions Architect with Semperis. And after Gito 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 Gito and Yevgeny, the stage is yours. I'll be back then for discussion and Q&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 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 we come across is still where Active Directory is the leading directory and then syncs into Azure Active Directory. And of course, that's now called Entry 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 Entry 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 continuity planning to ensure that you can recover Active Directory quickly.

And to give you a sense of what it actually takes to plan out and also justify in front of management why should you prepare for efforts around Active Directory recovery, you just need to understand how you depend on it. 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 through a tabletop exercise with clients to understand their recovery time objective and recovery point objective quickly here. I'm 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 have gone down? And typically, if the business is, of course, thinking of their applications, not the 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. 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 where you've got another cluster. When one server fails, the failover goes to the other cluster.

Hooray, I basically have split seconds failover time. In a disaster that is ransomware bound, you will basically have the situation that nothing is there. You're needing to recover from scratch. So it's critical to understand your own dependencies. This table that I'm happy to obviously share with the slides, also the workbook that we've created, it's just a helper there. This is a table with an exercise of doing that analysis with a real company, not naming the name here, of course.

But 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 acceptable to have an RTO for three hours, like the 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 did you get that function for email service back?

There is no acceptance, really, for longer than three hours. And, of course, typically, no loss, like last transaction is what every business wants. But in a true disaster, you have to go back to your real backups. And that's typically something around, worst case, 24-hour 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 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 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 starts that you need core infrastructure.

So your first question is, of course, well, where are you going to 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 have 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 say costs for cloud services doesn't matter. Costs for downtime is much more. We're going to 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 you actually do your backup. Kenny is going to 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-forest, well, multi-forest too, but multi-domain forest, bring it back within hours, not days, of course, not weeks. But that really depends on 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 downtime that has occurred to you. Domain dominance might have been gained by the intruder. You don't want to keep all administrative accounts in your environment. There are remediation steps that go beyond the technology of tooling or scripting that you do.

You will need to do extra steps to ensure that you actually trust your Active Directory back, and then you can start bringing back applications, can start reconciling other IAM 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 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. That has a question of its own. Are you going to recover from a backup, or are you going to rebuild from scratch?

Now, Vignini is going to take on that topic and explain a bit more on those thoughts. Thanks, Guido, because my 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 cannot 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 route to take. However, Martin talked in the introduction about Active Directory groups being used as 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 GUID or a SID, a security ID.

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 of having lists of applications in place, and then in trying to provide the correct authentication and authorization to every application that you're 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 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 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.

If you're not using AD integrated DNS for name 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 hardware, if that's maybe some Unix-based infrastructure, chances are that infrastructure might be left standing in an attack. But you still will have to reconfigure that to accommodate for your disaster recovery scenario where names may change, where IP addresses may change, where service records may have to be created, and so on. So know how to access that infrastructure as well.

Reduce the number of operating system versions. Like Guido said, providing machines from clean source is essential to a speedy disaster recovery in a cyber situation, which means the more different operating systems you have in your domain controller zoo or park, then 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 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 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 into your domain controller operating systems. This would be the case with a 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 an airplane crashing on your data center.

In the 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 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 sense of technical functionality and consistency.

And last but not least, you've seen GIDO'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 larger environment, or maybe even days if the forensic analysis and cleanup take longer than maybe expected or hoped. 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 a forest recovery, according to the plan that you have put in writing and tested, 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, and you will be able to once you've printed it out. And there are hundreds of steps to be done, and most of them require some sort of result verification and health verification. And once you go through all of this, 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 SEMBRIS. And with this, I would like to give back to Martin. Thank you very much for the insights. It's really fun.

You know, I'm not that close anymore, let's say, to really working hands-on on the Active Directory world. But there are so many things I remember, I resemble from the past. And I just 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&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 a couple of questions, because it's one of these topics that are always, I believe, very interesting and very compelling. So, yeah, so when we look at this entire thing, so you talked about these, and I think what I liked with your presentation was really this dependency aspect as well, because I think this is something we really need to be aware of. And these dependencies then go further and further than you. I just did some work on SAP automation recently.

And again, you have massive dependencies, because the operating system needs to be up so that the database can be up, and then you have clusters, et cetera, which nodes up and down first and all that stuff. It's tricky, and it needs to be well-thought and planned, and it needs to be, still what I believe, it needs to be tested, and it needs to be automated. And I think this is really where, from my perspective, all the tools come into play.

So, as I've said, I think we are all on the same page here a bit, and I like, I like your hints on the RTO and RPO. And by the way, when you look at the material, the trial and BSI, the Bundesamt für Sicherheit und Informationssicherheit, IT security governmental agency provides on business impact analysis, you will find even decks that help you create this and that are working along the same terms.

So, it's really proven, and I think we need to be aware. The problem is, the biggest problem is disasters when you're not well-prepared, because then it's where you lose endless time. And when I hear just, I think, this week in the state of Baden-Württemberg in southwest Germany, another town became, so the administration became, the local government, so to speak, became a victim of a ransomware attack. And then they are talking days, they are talking, and I would dare to say most of these aren't well-prepared, and we can't do it. This is wealth and money, I believe.

That's the reality that we see in any incident response that we're also involved in, Martin, and you've basically highlighted quite a few points there already, how people can better prepare. It's, the one thing is raise awareness, yeah? But without testing, it 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 a huge thing 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 utilizing systems in the cloud to ensure that recovery process can begin, but before that, what, how are you insured, 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 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 you abide to the insurance requirements 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'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. So what were the most surprising moments for you in past incident response cases that included Active Directory recovery? I'll give one example. The stories from the trenches, as you would call it. The stories from the trenches.

Actually, I've just answered that. Evgeny, you start on this one, because there's plenty that we can speak about. We could fill a whole program, but you go first, and I'll take the next one.

Yeah, well, the most surprising incident response in my career was where every monitor was read and every system was down, and when we got called in to actually do incident response and disaster recovery, we found a situation where systems were heavily compromised, and then 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 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 case to start raising people in the middle of the night. Yeah, but it was the best case scenario, I would have to say. I'll give you another example that's, let's say, more for what's out there. In reality, a company completely wiped out all of their VMware infrastructure and, of course, all the snapshots and the backups on systems that were disk-based.

Also, the replica of that was completely gone, and the company only had those disk-based Active Directory backups, so they fought for two days.

They basically didn't have anything, and we can also only support if a backup is available, and for two days, apparently, the one person that knew that they actually did also have a domain controller running as infrastructure as a service VM in Azure wasn't known, and then they realized, oh, that thing, once they realized it did have actually different backup, 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 lucky in many senses because 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 it's still surprises. There'd be many more. I'll 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 basically get rid of the intruder by having Active Directory cleaned and hardened back into production, of course, at a high-speed process doing that, but finding a surprise such as everybody was able to reset everybody's password.

That's nothing that you want in a secure environment. No, but by the way, I think one thing we also should be very aware of, and that goes beyond AV, but includes also some versions of how you run it. Having it in the cloud doesn't mean you don't need a backup. You don't need a recovery approach. I think there was, which goes beyond or a bit outside 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 data center of a French infrastructure service provider, and the interesting numbers I've heard is that 90% of 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.

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 I think 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 systems good to use as 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 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 especially if we're talking about virtual machines, you can take a copy of that VM disk and have that for your forensic analysis. If it's a 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 use them, and how far has that intruder gone, especially when we're talking about a physical system?

Have they built back doors into the firmware, injected back doors into the firmware of that physical system? So I would say, in general, for most forensics, it's actually event log information that gives most data an active directory.

Of course, there's plenty of of places to hide for intruders. So yes, it also needs to be analyzed in detail, but it's not uncommon to utilize backups for that if you're in a position to take good backups.

Okay, so maybe we look at the second poll, the results, quickly, because 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 results of the second poll, I'm not sure if it's already visible, then it's interesting to see that three out of four don't have plans to retire ADVS in the next three years. So at the end of the day, a lot will have it around, and it will remain critical as we said. So very simple.

If you are not prepared, then you still need to have it, most organizations, for probably a 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. Maybe let's switch back to our conversation. Let's add a thought on that, Martin.

Let's add a thought on that poll result, because I think it's important for the participants to realize that Microsoft has at least 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 through updates, security patching in also around 2019-2022. But there is hope for 2025. There's a new version coming. So Microsoft hasn't given up.

Anyway, we don't have super much time anymore. So I'd like to pick at least three of the questions we already have in here and ask for very concise responses. So the first one is, is there a major difference in the resiliency of AAD or Entry ID versus On-Prem ID from a real-world incident perspective? So how resilient should Entry ID be regarded?

Yeah, well, it all depends on how much access the threat actor actually is able to acquire. Because with cloud services in general, there is this shared responsibility dilemma. So in case the actor is able to actually hot delete your objects or 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 not, but they will not help you because it's outside of their part of the shared responsibility. Very important.

If you use something in the cloud, look at the contract and understand what is provider responsibility and what is tenant responsibility and care for your tenant responsibility. There's one more question we can take, otherwise we will run out of time. It was a bit directed to me, but you may add on this. Which enterprise is this enterprise features missing or partially missing in Entry ID compared to AAD like organizational units or use? Is it really time to shift beyond the difficulty of the micro-creation? How do you see this evolve? I believe it's more a matter of what are your use cases.

It's a matter of transition. What do you hear?

Notably, the concepts are different, but it's, for instance, you can use custom attributes, so you can sort of record, add information like that. The idea of the structure is different because we know that AAD still relied on the LDAP idea, which goes back to DAP, which is really Stone Age and very inflexible, as you also know, for many use cases. It's legacy. Entry ID goes more into a graph approach, a way more flexible approach overall and has a bit of a different target. By the way, it's really an identity system.

To me, there's no doubt that Entry ID must be owned by the IAM department, not by the infrastructure department from that perspective. Anyway, something short to add here? I think important is that Entry ID is more or less a flat directory, but Microsoft has, of course, with administrative units and even restricted administrative units, tried to give some level of structure in the sense of delegation of duties to different teams. In Entry 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 a different protocol.

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, if they still require Kerberos or, in worst case, NTLM authentication for your users, Entry ID won't help you. So it's for modern apps. That's where Entry 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 from trenches around OT, I recently talked to the customer, he said, you know, I would be happy if I only had NTLM. I still have some LM protocols around in that environment. So this is really, things are moving slower here. So I quickly share my screen again, just for a minute. So before we end, I just want very quickly highlight, we have June 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 down to one more slide, which is this one, which is about saying thank you. Thank you to all the attendees of this webinar. Thank you to St. Paris for supporting this webinar. And thank you specifically to you, Guido and Evgeny, for all your insights. You probably could have talked for another hour easily, probably longer. So we're a 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 next upcoming webinars. Thank you. Thanks for having us. Thank you very much.

Thanks for having us.