Good good morning or afternoon or whatever your time's zone. I'm Dan bloom, a senior Analyst with Kuppinger Paul and welcome to active directory, da disaster recovery webinar. I'm joined by Darren Mar Elliot head of product at St. Paris. We'll be talking about a active directory forest recovery product as well, but I'm gonna start out with a quick overview of Kuppinger call and then of the state of the industry as regards the problem that we have with active directory security.
First about Kuppinger call we're research and advisory firm located in Munich, Germany founded in 2004, we provide research and advisory services on security, identity management, identity governance, risk management, and all areas, really where those security and identity disciplines intersect. The digital transformation that companies are going through. Our business areas are research where we provide vendor neutral, current independent advice advisory, or, or consulting services where we answer questions, provide short consulting engagements to help your organization solve problems.
They may have gain insight into the research and the industry, and then events. We have two upcoming Kuppinger call events or series of events, really the consumer identity world very soon in September 19 through 21. I'm Seattle, the USA, and then October 29 through 31 in Europe and November 22, 20 through 22 in Singapore. So three consumer identity summits, and, and then there will be two cybersecurity summits starting in Germany and then in the USA beginning in November. So those are our events. And let me just give you some guidelines for this webinar and I'll dive into the good stuff.
So you are muted centrally, so talk or rattle around your office, as you wish we control the mute and unmute features. We'll also record this webinar. So if you have to miss a bit or you just want to go back and listen some more or send it to a colleague, the podcast recording will be available tomorrow.
Finally, we'll close with a Q and a session, and you have a little questions panel in your go to meeting control center, where you can enter your questions at any time. So please ask us some questions if it makes it all more exciting at the end. So we're looking forward to your questions when we got them, we're gonna cover thus an agenda three part agenda. Part one will be me, Dan bloom, going through some of the reasons that threats to ad or an increasing and why that's a problem and some good practices.
And then Darren will discuss possible disasters that could harm active directory and how to recover in ad four seamlessly. And then we will have the Q and a.
So going into my content here, active directory is still critical enterprise infrastructure. I say still because the industry is really moving in a big way towards identity as a service solutions, but there's still a lot of functions that are retained in house, such as the, the core HR data is often maintained in house. Sometimes the security policy requires that credentials or keys be maintained in house.
And sometimes there's also some core private networks or private data centers where some of the critical systems are inhouse or legacy systems and active directories, the core identity system, the core identity infrastructure in house for these networks. And even, even if you're using an I a solution, you still probably depend on ad to populate the cloud based directory accounts.
So as your ad is typically populated from the premise based ad and for example, and then also if there's a requirement to maintain credentials in house, then you're going to authenticate users from your premise based ad installation or at least 90% or, or so of the world's organizations do so. So should ad be compromised or corrupted? The whole enterprise hybrid cloud dare I say is in deep trouble.
The threats to active directory are increasing.
Why, why is that? Well, if you read the newspapers or watch the news, you know, of course that cyber attacks and breaches are increasing generally in the cyber crime community is always becoming more active and getting new skills for every advance we make on the defense team. And often that kill chain, if you like to the target customer database or whatever the attackers are after leads through the active directory. And it's unfortunately quite easy for attackers to exploit enterprises.
Once they get a foothold within the firewall through some sort of domain account or credential or computer access, they can then use readily available exploit tools to plan their attack and then move laterally into the enterprise. Some of these tools are tools like power plate and bloodhound, which are used to discover who has what privileges, who has access to critical ad objects.
And these tools are actually I'm told available in GitHub because they're used by ethical hackers and penetration testers, but these and similar tools are also available to black hats. So to speak.
Now, ransomware prose is a new threat, which I'm going to discuss in just a minute, but first let's map out the intrusion timeline on a sample active directory kill chain. For those of you, by the way that aren't familiar with the term kill chain, it just means like a T path. It was actually popularized in the, in the white paper by Lockheed Martin some years ago. And what it shows here in the yellow going to red bar is that a lot of exploits or attacks follow a familiar trajectory.
Some, some are different if they have different sorts of markets, but if you were going after a credit card database or something like that, likely the attacker is going to begin by recon.
They're going to identify the domain users on LinkedIn or searching Google. They're gonna find names of executives and things like that. And then they're gonna try fishing or malware tax, or they may just discover a PC and a botnet. That's already been compromised. It's within your domain. And you could become a target of opportunity that could happen as well.
Once you get into the red there under delivery, now your users or computers are starting to get targeted. Maybe some malware compromises, the operating system, maybe the user is fished and they provide their name and password to a fake website. Now the attacker has domain credentials and possibly a computer with access to the domain, and they can use those credentials in that computer to start to move in through the perimeter.
And they can begin to access the active directory as any user can do in order to authenticate or to look for other users or to perform the normal function that a computer performs in a windows network.
And that's when they can use these sorts of tools like the power plate or the bloodhound to browse users and computers, and to identify servers, to find roles and privileges in the active directory. So they may use that to find where's a juicy target that we could compromise for financial gain or whatever the motive may be, or they may use that knowing the target, how do I get closer?
How do I get access to a system administrator account or domain administrator account so that I can actually access the data on this credit card database or whatever the target is and exfiltrate it. And the, the terrible thing is if an attacker can actually get domain administrator access, that's like having the keys to the kingdom. This is probably not news to many of you, but they can change any permissions. They don't have, they can reset passwords.
They can add people to groups.
And even without a domain administrator account, if they have a privileged account, they will have access to some groups. They will be able to reset some passwords and they will be able to move laterally. And a lot of times that movement is pressed or accomplished by writing data to the active directory. And the good news is that there's things we can do to detect that, but what's going to happen. If a cyber attacker does go through this kill chain and positive reach, it could bring the network to its knees.
Once they have access to a domain administrator account or system privileges on a domain controller or something like that, it could be game over as far as protecting your target resource, your crown jewels at that point, the best you could do is detect. So you wanted detect these things early.
Now, ransomware is sort of the new kid on the block of malware exploits, at least within the last couple years with the pet yard and the not PA. Yeah. And other ransomware exploits, how that factors into the ad security picture is that ransomware may use the same privileges that a financially motivated credit card database attacker would use to accomplish a different aim, targeting different targets.
What the ransomware would be interested in was having the enough active directory privilege that that would start to locate all the workstations or servers on the network or any particular ones they want to target. And then they could also potentially be able to use additional services reports that would be available to everyone. And through those have access to additional libraries of vulnerabilities or exploits they could use to spread the ransomware malware. A ransomware could also encrypt one of the domain controller, solar storage devices.
And, and that would, of course invoke the need for forest recovery pretty fast, but even more sinister than that, ransomware might try to subtly corrupt the active directory, let the corruption be replicated. And then only those hackers know how it was corrupted and you have to pay them for the solution. Let's hope that doesn't happen, but that would be almost the worst of the worst. So hopefully with all this sinister talk of kill chains and exploits and so forth, you're motivated to look at this eye chart of active directory protection matrix.
The, the fact of the matter is that most enterprises have complex overprivileged and fairly challenging to protect active directory environments. And they have many of these security issues, which not only contribute to domain risk, but also contribute to the risk of the resources in the domain. And there isn't time to go through every item on this list.
Some of them may come up in Darren's discussion.
So I'll leave it as a takeaway, but real fast, the issue of having too many domain administrators needs to be remedy by the good practice of consolidating domains, reducing the number of administrators, hardening the settings, and then detecting changes. And the, the control of inappropriate administrator privilege delegation or granting needs to be managed through the good practice of strict policies, processes, and workflows for admin privileged allegation.
But you can decree these policies and create these POS processes, but a domain administrator can override all because it's essential to the functioning of any network and to a windows network to have certain people with high administrative privileges. So you could say there's only gonna be five domain administrators, but any one of them could add additional ones. You could say that the only person that's gonna gonna be granted access to the administrative rights of the credit card database is John Smith.
But the domain administrator could add additional persons to the group that gives John Smith those privileges. So it's important to have backup monitoring and change control tools in place to detect any violations of these policies.
So the recommendations and conclusions coming out of all, this is that first you need to develop your strict standards for ad configuration administration and deployment.
This is an area where you wanna be type a or B not type C, and then you need to use the ad protection matrix that I provided in the previous slide to give you some guidance on that and look at other information sources because I'm sure there's, you know, still more levels of detail to be dealt with. And then remember I said, the deviations from whatever your policies or processes may be, are going to occur. They are inevitable given the nature of the network either by malicious act of an insider or an error.
So you need to monitor closely to detect those deviations in order to make those policies and standards and processes stick. You're gonna need to deploy active directory, audit tools, active directory, change control, and orchestration, and to deploy a means of ad recovery.
And, and that I think gives us a great transition to Darren. Who's going to talk about the St Paris active directory forest recovery. And so control will be going over to him and you'll hear him shortly. Thank you so much.
Thanks so much, Dan, appreciate that. And let me just go ahead and share up my screen here so everyone can see it and thanks everyone for joining.
I, I, I really enjoyed what Dan was talking about because I think it, it definitely underscores what we're seeing as well in that ad has become kind of the soft underbelly of corporate networks. Now that the perimeter is pretty much every single host on the system on the network, you know, active directory has traditionally not been managed as tightly as some of the areas that Dan has talked about.
And, and I know that people are, have been getting the message for the last few years, but as recently as a couple days ago, I just blog about a, an opportunity where if a, if a user non-privileged user happened to have right access to the domain object in active directory, that they could easily escalate themselves to admin level domain, admin level access.
And so, as we can see, there's a lot of best practices that need to go into managing active directory before we can consider it sort of a safe, a safe environment again.
So anyway, let me kind of dig in here. I just wanna go through some of my slides and talk a little bit about who we are, and, and then just talk about some best practices around ad backup and recovery. So some Paris is a identity protection company. We help organizations in, in a lot of these areas that we've been talking about cyber breaches ad or directory services failures, either on premises or in the cloud. And really what we're focused on is helping customers at both ends of that spectrum with respect to active directory.
So at the high end of the spectrum, and what we're talking about today is the, at some Paris 80 force recovery solution, which allows you to recover the large things that go wrong in active directory.
So domains, domain controllers, and then of course, an entire forest. And at the other end of the spectrum, the ability to track changes to see as Dan was mentioning, who's putting users into domain admins and be able to revert those changes when they're unwanted or unexpected.
So we're covering kind of both ends of that spectrum and just a little screenshot obligatory screenshot of both products. So let's talk about kind of the two possible failure scenarios, at least.
I mean, there's probably more than two, but I like to categorize them this way. The first is logical corruption of ad. And this is where you have essentially something that you've done in active directory, or that has been done to active directory that renders the service itself unavailable, even though the domain controllers, the windows operating system running on those is still viable. So this could be a schema update that's gone wrong.
It could be a domain functional level or forest functional level update that you didn't mean to have happen, or you, or you had you planned for it, but it ended up breaking some legacy applications. So these are, these are kind of, let's call them, you know, sort of logical events to active directory that affected as a service or affect its ability to serve identity to your organization. And then the other kind of side, the other side of the equation here is physical corruption of ad.
And this is when both ad and the domain controller are non reusable, which is a, a polite way of saying that they're completely booked. So this can, this can range from one of your DCS to, as we've seen with some organizations, all of their DCS being rendered unusable.
And, and in that example, it's, it most often been a malware, some sort of ransomware attack that's targeted the domain controllers, or maybe it didn't even target the domain controllers, but it happened to find domain controllers along the way and was happy to encrypt those.
So I think that's probably the worst case scenario. And the reason I call out these two different types of, of, of sort of failure scenarios is because you're going to handle them in, in different ways in your disaster recovery planning for ad. So the first illogic corruption scenario is a lot easier.
Well, let's say it's relatively easier to have to think about, because you only have to think about getting ad back as a service when you have physical corruption of ad, which is the second case. You have to think about both getting an operating system up on as many DCS as you can, and then orchestrating the recovery of active directory as a service on top of that. So obviously those are, you know, that's kind of a level of complexity above the logical corruption scenario.
Now, the reality is you really do have to plan for both of those things because there it's it's possible that either of those could happen in your environment.
So what is different about active directory backup versus just backing up a file server?
Well, active directory is a special beast and it requires a sort of special attention. The most obvious reason why it's different is because it is a multi-master distributed database.
It is, you know, changes can originate on any DC in your, on any read, write DC in your environment. And they get replicated around using a very, fairly sophisticated and robust replication mechanism. So this is, this is a, you know, sort of, but this is 18 plus year old technology, and it's been optimized to be highly distributed, highly robust, but because of that, multi-master nature. It can't simply be restored using standard processes like snapshots or disc images.
I actually had somebody just yesterday that I was talking to asking me if I could help them with an active directory issue they had where they, they were in a lab environment and they actually did a, a system I'm gonna get the term wrong, but it's, it's that feature in windows where you can basically roll back to a previous state in time.
It's like the, the system restore or whatever that that feature is called. And it completely borked their small two domain controller active directory because of various issues that came up broke.
The trust that they had to their child domain broke the secure channel communications between the domain controllers and between clients and the domain. Just a simple example of why it's not sufficient to simply do snapshots of ad if they're virtual and try to revert those. And I think this is a well known fact, and there's some technology in both of the main, well, all of the main hypervisors today that, that help you work around this, but you still have to be aware of it.
You still have to sort of be careful, and it's still not an optimal way to recover active directory, which I'll talk about in a little bit. And the other, the other challenge here is let's say you're in that second failure scenario that I talked about, which is physical corruption.
You have to get systems up and running as fast as possible. If your active directory is down in the organization, chances are that all manner of sea level type individuals are screaming at you. And standing next to you asking when it's gonna be up.
And the last thing you want to have to worry about is do I have the right hardware and software versions to get back to functional level and, and active directory, or at least backups in general are very sensitive to that sort of thing. And the, the other challenge there is if you've had a malware attack, let's say the malware has been in your environment for a while. You don't know if any of your backups are still actually valid. They might actually be corrupted. So you might be restoring servers from backups that are actually still containing the malware.
So you've got a lot of challenges there in that environment and alternative hardware, you know, the ability to take a physical DC and restore it to a virtual DC is, is not something that's typically supported in the basic hardware, basic backup solutions.
And then there's, you know, not withstanding getting the operating system and the active directory database restored. There's a lot of ad specific, excuse me, specific stuff that you have to think about when you're doing a recovery.
Again, you have this multi-master replicated environment, it could be global. In other words, you could have ad sites and site links spread across the globe. You might have different FMO roles on different servers, whatever the case may be. You have the global catalog, you have to worry about, you have DNS. You have to worry about all of these parts and pieces are very ad specific.
And again, it's not served by a simple backup and recovery.
So let's talk about some critical PA practices to think about.
And I, you know, when I'm talking about these, I'm talking just in terms of a basic ad backup solution. So what you want from a backup perspective is you want to be able to have at least two trusted backups for each domain. And there's an article that I reference here, but the idea is you need to have two viable backups in every domain that you're trying to recover in your forest. The reason for that is if one backup is bad, then you have a fallback position, but you need, let's just, you know, the bottom line is you need at least one that's viable.
Hopefully you have, you have more than one that's viable, but the point here is that you never know with backups, if they're viable or not. And so you wanna make sure that you have a couple, at least a couple.
The other thing you need to account for is the number of DCS to back up. So in this scenario, what, what we're trying to think about is how do I get back to the service level that is required to service my applications and users might my tier one, you know, most organizations have a concept of tier one applications, right? So these might be your books and records.
If you're a financial services company, they might be your ordering system. If you're a retail company, whatever that tier one application or set of applications are, chances are they're relying on ad. And so you need to think about how many DCS do I need to back up to be able to get back to that minimum level of service as quickly as possible. And secondarily, where are those DCS located at? So chances are, if you have regional locations, regional data centers, multiple data centers across the globe, you want to be backing up DCS in those data centers first and foremost.
And then the, the, the next point here is that a full forest backup is more than just a collection of DC system, state backups. And I, I alluded to this previously, there's a lot of other parts and pieces in active directory that you have to think about. Another thing you wanna think about is backup retention. How long do you keep your backups? So the backups, obviously you don't wanna have backups lying around that, exceed your tombstone lifetime, because if you try to restore those, you're gonna have a world of pain in terms of lingering objects and all sorts of other issues.
So you, you wanna make sure you don't keep backups around too long DSRM or directory services, repair mode passwords. So when you are in the process of repairing ad of bringing ad back from backup, you need to boot into DSRM mode, and those have their own individual passwords. Where are those held? How do you keep those secure backup encryption keys? So when you're backing up ad, you are making an offline copy of your debt. And that means that every account and all of their secrets are available offline in that backup, you darn well want to be able to encrypt backups.
And so where do you keep the keys? How do you do key management in those cases?
So some tips on selecting the DCS for restore. So when we're, we've got our let's, let's assume we've got our backup scenario taken care of what are you gonna do around restoration? How do you think about restoration? So you wanna keep the Delta of the backups that you're recovering from to a bare minimum.
And what, what I'm talking about here is let's say you take a backup of DC one today, and a backup of DC two tomorrow, and a backup of DC three a week from now, you that's probably too long of a spread to then come back and restore all of those in a single recovery event. You're gonna get all sorts of issues potentially with USN rollback. And so you wanna try to keep those backups as close to each other as possible. The other thing is thinking about physical versus virtual.
Most of you listening to this are probably living in a world where you have either all virtual DCS or maybe a mix of physical and virtual is your virtualized environment dependent on ad.
And this is a more general point here, if you think about, and, and this is an exercise you really need to go through how much of your infrastructure your supporting infrastructure is dependent on ad, and will it still function if your ad is completely unavailable. So if you're using ESX with vCenter, can you log into vCenter without ad being available?
So those are important questions that you need to ask and, and account for DNS servers, either ad integrated DNS or not, they must be accounted for. Obviously we all know that DNS is sort of the underpinning of active directory functioning correctly. So you're gonna be recovering DNS as part of your ad recovery scenario. If you're using ad integrated DNS, or if you're not using ad integrated DNS, you need to make sure that you fix up whatever you're in external ad DN, whatever external DNS you're using for active directory, as you're doing your recovery.
Otherwise, you're gonna get situations where you have, you know, Phantom records of DCS that no longer exist trying to service requests from customers, and you're gonna get into all kinds of issues. So these are some of the things to think about when you're choosing what DCS to restore, where they get restored. Let's dive in a little bit more specifically on some of these, so name, resolution, and this is obviously DNS. So you have to think about the DNS servers that are hosting your ad integrated zones. So those are servers they're, they're probably gonna be domain controllers.
Well, they are gonna be domain controllers. You need to make sure that if you have a DNS server, that's being referenced by a bunch of clients, that that's one of the servers that you're bringing back. Do you have forwarders configured or conditional forwarders? Do you have delegations and stub zones?
Do you have, what are the DNS servers that are being referenced by the machines? So you need to make sure that those are those DNS servers are made available and that are cleaned up as you're doing your forest recovery. The other thing to think about is replication. Topology.
When you're restoring DCS from multiple ad sites, you wanna make sure that there's a direct site link between the sites involved. You don't wanna have to see or have to deal with replication latency between site links. If you're trying to recover your DCS, you want to have a direct site link involving all the DCS that you're restoring. So if you have three data centers, they should be all on the same site, link you.
This is a, a one that bites us all, but you need to account for firewalls and DMZs. You need to make sure that the domain naming master is accessible from all domains in the forest. So that has to come up in the right order, that FSMA role. And then if you have manual customizations that could complicate things. Microsoft has a last time. I looked somewhere in the order of 70 plus page white paper that talks about the manual way of restoring a forest. And a lot of this stuff involves keep keeping and maintaining scripts over time to make sure that this all gets done in the right way.
There's also this notion that you could potentially gradually recover your forest, maybe one domain at a time. This is problematic in any large organization because a number of things will happen. So one is that your GC rebuild will fail out of the box because it won't have all the domains available to actually do GC rebuild. If you're missing partitions in the GC, then assuming you allow by changing occupancy level settings, you allow the GC to rebuild with only partial partitions. Then you're gonna miss universal group memberships from those partitions that haven't come up yet.
And so you could affect access to objects because of the, depending on whether those resource, those universal groups have been set with allow or deny position permissions on those resources. As you can tell, there's a lot of things you have to think about here.
So, you know, the other approach is to do per site recovery, but then you get into scenarios where maybe you have DCS in one site from the corrupted domain, and maybe it's still, maybe it's a logical corruption.
So it's still functional. And you're trying to restore to a different, in a different site with, you know, into a new forest or essentially a restored forest. You can't let those things talk to each other because you're gonna get all sorts of issues with that. And then you have issues with making sure that users are only talking to the site.
That's, that's, that's being recovered rather than the old site. So as you can imagine, this can cause just no end of support nightmares. So what do you need to include in your forest backup? So I've been talking about all this thing, all these issues that you have to worry about. So a forest backup obviously has to be more than just a system state backup the backup or the solution has to know about your forest topology.
It has to know what your domain control or IP addresses are you your, if you have to assume, if you're using ad integrated DNS, the DNS is not available during the recovery process.
So you're gonna have to be able to talk via IP address.
Instead, you need to know the disc layout, the hardware specs of your DCS. You need to know DNS server configurations. You need to know about your rid 500 accounts and their, and their passwords DSRM passwords. I mentioned this earlier, and then any unique or custom DC settings or configurations that you might have. So let me just talk a little bit about the Paris solution and how we sort of compare to some of the other ways of doing this.
So again, we are an active directory aware backup process. You probably implied this from all the information I was giving you about the things that you have to think about from a recovery from total failure, you have to assume, or you at least have to have a plan in place that says that I have not a single active directory server left.
And how do I recover from that? And you may even have lost your backup solution and your backup and recovery solution. So you have to have a plan to recover from that as well.
So along with that, and, and I sort of implied this earlier is your backup and recovery solution can't rely on active directory in any way. That means DNS. That means authentication. That means potentially certificate services. If you're relying on your CA, which is tied to ad to be up and running, that that's not gonna work, you have to be able to restore to alternate hardware. This gives you the most flexibility in terms of getting back as quickly as possible.
Even if hardware or virtual machines have been corrupted, name resolution is absolutely critical and you need to be able to do automated DNS restoration and then recovery time objectives. So this is where, you know, it's a little bit of, of having a good solution and then having a good plan in place to make sure, as I was talking about earlier, you bring back the right DCS in the right order to get back to that minimum level of service, we call it the mini forest, but it's getting back to a fully functional ad as quickly as possible.
That's able to service your tier one applications and to be able to do that in a parallel fashion, to be able to do that leveraging distributed backups. So you're not having to drag large backups across wha links to get them to DCS. So all of that basically is, is where some Paris's ADFR solution shines.
So what we have is comprehensive backup solutions. So first and foremost, you have to back up ad, we can schedule the backups. They're encrypted, they're compressed backups are cashed on DCS.
If you get into that first case of corruption, logical corruption, where the operating system is still viable, but the backup, but the ad is not. Then the best case scenario is you don't have to drag a backup across the wire. You can just recover from the local backup, but if that's not the case, we have backups that are distributed automatically to distribution points that can be close to the DCS so that you can grab a, a backup from as close to a, you know, sort of logical network perspective as possible. Our backups are validated.
So that, what that means is that, you know, remember when I talked about having at least two DCS per domain backed up, we make sure that the backup completes successfully that it's uploaded to a distribution point successfully, and that you have enough backups to re, to be able to recover a full forest. And then our BA role based access control in the product.
You know, you don't want anyone to be able to perform a forest recovery. So obviously you wanna be able to control who can do that, and we have that ability within the product.
So just a quick screenshot of the, this is sort of the three different options that you have in the solution, either an individual DC restore interesting, but not the big problem. When you're getting into recovery partition recovery, I can recover either a whole domain partition, a config partition, an arbitrary application, partition like DNS, and finally a forest recovery. This is the big Kahoona.
This is I have, you know, no active directory functional, and I need to be able to run a forest recovery. And this is just a quick screenshot that shows the forest recovery. And I think what I'm gonna do now is I'm gonna drop into a quick demo just to kind of show you what this looks like. So I'm in the ADFR server and I'm gonna log into the recovery panel. So I'm gonna, I'm gonna do dessert before I do the main dish.
And so this is the three options that I talked about, and if I click on forest recovery, I can choose a backup set that I wanna revert my forest back to.
And I have a three domain forest here, and I have one backup, one DC backed up in each forest. What we're gonna do is go ahead and analyze this. And the analysis process determines what I need to do to get back to an ad functional ad forest as quickly as possible. So you'll see here that I'm gonna restore from backup in at least one DC that I have backups for in each forest. So that restore from backup is, you know, what that's gonna do is it's gonna remotely orchestrate doing a DSRM boot logging in and restoring from backup from the backups that we have.
Once I've got all those DCS from all those domains in, I'm gonna fix up DNS, I'm gonna fix up the global catalog and do a global catalog rebuild.
I'm gonna do metadata cleanup, and I'm gonna have a full mini forest back as quickly as possible. And then once that happens, I'm gonna go through a process where other DCS, where my agent is installed are gonna get automatically repro promoted back into the new forest. And we have the ability to do a promote from IFM installed from media that gets generated while I'm doing my restores from backup.
So that further reduces the time that you have to worry about getting back ad back up as quickly as possible. And just a quick little view into the administrative side of the problem.
So what we're gonna do is log into the administrator console and the thing to keep in mind here, if I can cite my password correctly, the thing to keep in mind here is that this server is not joined to ad of course I don't need ad credentials to log in. And the communication between the server and the agents running on the DCS does not rely on any ad authentication.
It's an internally generated certificate based authentication. So here we are, I have my backups that have been validated. I can configure backups, encrypt backups, set them for different schedules, and I can automatically distribute backups to management, to distribution points. And I can manage that all from the central console. So a lot of ability to flexibly handle backup and recovery within active directory, and again, without requiring any intervention from you, the user, once you click that recover button in the recovery console, it's off to the races.
And depending on how large your forest is anywhere from minutes to hours to get back to a fully functional forest, even a global forest that has DC spread all over the world. That's my presentation. These are some contact details for us at some Paris and me and on Twitter I'm group policy guy. And thank you so much, Dan.
I'm gonna, I think I'm gonna hand it back to you.
Great. Thank you so much, Darren, for great presentation here. Let me just take care of a little housekeeping and we'll move into the Q and a. So we talked about the coming events and here's a few items of related research. There's also going to be a re a short executive view document coming out on the some Paris DS protector product, which wasn't on here, but should be in your plans for your reading list. And let's now move into the Q and a.
So I've got a few questions, but I could use a few more, otherwise we would have to end early, but let's see where we are. My first question is how to cover a privileged identity and account management PI Pam solution in a act in a domain controller, active directory recovery. So this would be a solution like a cyber, a or AFI or beyond trust, a lot of different products, support, privileged access management, password, vaults, session management, and administrative session logging and privileged user analytics.
And those sort of features.
I think that there were a few clues in Darren's presentation. One of them would be that your Pam solution, like all other critical solutions should have some level of robustness, their ability to operate in the event that an active directory outage occurred. I know that some of them are fairly self-contained, you know, they operate kind of like a bastion host and they basically copy all of the users out of the directory and rather than rely on the directory, always being up on real time.
Of course, when they do that, they get complaints for being too proprietary and not, you know, inter-operating well with your network. So it's sort of a trade off. I don't know if you have any other thoughts on, on that one, Darren?
Yeah, I think thanks Dan. It's I think it's a good question. So there's a couple things to think about. One is that when you're in forest recovery mode, chances are, you're not really thinking about Pam solutions, PIM Pam solutions. So most of the operations that I talked about, at least in the some Paris product are happening independent of active directory at the point that you're recovering it.
But the thing that you have to think about is if you're recovering active directory from a backup that's, let's say a couple days old, or maybe even a week old, you may have, you may be unsynchronized or not synchronized with your PIM a solution once ad is back up and running. So if the PIM a solution has gone in and changed passwords on accounts within active directory, for example, and you're, and you end up recovering your active directory back to a prior state, they may be out of sync.
And so I think you have to work with your PIPA vendor to figure out how you manage things in that condition. So how you, obviously, the frankly, the PIPA solution is probably not the first thing you're worried about when you're trying to recover ad, but once ad is back up, you want that up as quickly as possible. And so I think that's, that's gonna be the question to ask,
Well, there's another factor to this too, Darren though.
What if you were using the PIPA solution to keep the backup keys and other, I think, I think you said there were various bits of privileged information that needed to be used to support forest recovery. Certainly if using some Paris, it probably would be all over the place and you'd have a lot of the emergency brake glass information that you needed for different systems sitting in that PIPA vault safe, and, and you better be able to get into it even if active directories down.
Yeah.
It's a good point, Dan, actually, with our solution, you don't have to worry about that because we basically take control of that process through our agents. So we, for example, DSRM passwords are reset by us, by our agent when we're in recovery mode. So a lot of those secrets are being controlled by us in that case, but the point is at least at least for recovery mode, but your point is, is well taken.
If you're not using a solution that manages that for you from a recovery perspective, then you need to make sure you can get to those DSRM passwords or whatever the accounts that you need to get access to, to be able to perform your recovery.
Right. And if there are tier one systems that require, you know, 365 by 24, 7 availability at all times, and even, even if you had a fast forest recovery solution, like St Paris in place, you'd probably wanna be able to maintain some level of operation on those systems during the short outage.
And yeah, absolutely. And, and that's when you'd be going into the privileged access management system for whatever great glass information you required to get access to those tier one systems. So it needs to be up even if active directories having an outage in that scenario.
Yeah, for sure.
So just a few things to think about another question came in here, which is what is the recommended retention period for ad backups? I'll leave that one for you, Darren. I know you mentioned tombstones and some considerations during your back.
Yep. Yeah. So you certainly don't wanna keep them past your tombstone lifetime, which in, in most modern ad's is probably 180 days. I would say that it's really gonna be driven by your own SLAs.
I mean, you may not wanna keep them past a month if you're, if you're, if you can't afford to go back in time a month in terms of all of the ad changes that have happened. So it, it really ends up being driven mostly by your recovery plan or your, your SLAs.
Great. So another, another question that came in was can, can you talk about types of ad production, a corruption and what that means for availability?
Obviously I would say, you know, different types of ad corruption are, are going to affect one domain, maybe the whole forest, maybe part of the domain and anything that depends on that is going to be compromised in terms of availability. But do you have any thoughts on that one, Darren?
Yeah, I mean, I, I kind of laid out at the two sort of two ways that I think about it, which is logical corruption and physical corruption. And I think it's, there's probably some more subtlety in that, right? Because oftentimes it's not that AB is completely unavailable.
I mean, you, you could consider somebody going in and accidentally deleting an OU with 50,000 users in it to be a, a sort of a form of logical corruption. And that case, a lot of things are gonna break, even though ad is still up and running. And in that case, you may still need some kind of recovery solution, like the partition recovery capability I talked about in our product or whatever the case may be. You need to get back to ad being functional, even though it's still running. So I think you have to sort of think about some of those logical cases and the, the different gradations of them.
I mean, DNS being broken is a, is as far as the idea is concerned is an, is a service level affecting event. So making sure you have a good handle on DNS backups and DNS recovery, if somebody went in and deleted a zone accidentally, that's obviously going to cause massive disruption of ad. And we've actually had customers that have been in that situation and used our DS protective product to be able to recover from that. But the point there is that there's lots of parts and pieces in ad that, you know, I mean, let, my, my favorite group policy changes, right?
If, if somebody makes a group PO I mean, I've seen this happen on numerous occasions, somebody makes a group policy change that basically knocks everyone off of their workstations. That's for all intents and purposes, that's an 80 outage, even though eighties up and running. So I think you have to think about a lot of those different scenarios.
Yeah. Okay. I found a bunch more questions here.
Actually, there's one here. I'll just read it to you, Darren, and, and maybe you can decipher it. It it's first, it says holding FSM O rolls because of windows ransom, where hits your network, your backups might not be accessible. I think we're getting at there.
Yeah.
I'm, I'm not quite sure. So SMO roles are something you have to think about. And I mentioned that a little bit in, in some of the criteria that, that I mentioned in, in backup and recovery. So you wanna make sure that your you're backing up DCS with FSMA roles or at the, at the worst case scenario. If you're doing this process manually, you need to make sure that you've got like the domain naming FSMA backup and running as quickly as possible. If not the first thing you do in terms of ransomware attacking your backups, that's absolutely the case.
So regardless of what you're using for backup solution, you have to back up your backups, right? So you have to have your backups accessible offsite or off network in some other solution to make sure that if everything is corrupted is, is, is ransomware attacked and or corrupted that you have at least an offline copy of your backups to be able to bring back your environment with. So that's a good question.
So you have somebody running to the safety deposit box, every
That's right.
Directory domain controllers on
It's good. Old tape backups, never fail.
Yeah.
Is it, is it necessary to back up all domain controllers in a domain or at least all domain controllers holding FSM O roles?
Yeah.
So, I mean, again, this kind of goes back to whichever solution, whatever solution you're using with. So, so let, let me just take it into two pieces. So it's definitely not necessary to back up all domain controllers in a forest. I would say that you back up the domain controllers that you wanna bring back the fastest, because it's going to be fastest to bring back from system state backup as compared to having to repromote domain controllers.
So, so I would say it obviously at least one domain controller per domain, and potentially one domain controller per major location and by major location, I mean place where there are users and, or tier one applications that require it and probably more than that, depending on capacity. So that's really the ends up the deciding factor.
And, and, and we, you know, that's part of our process when we're working with customers and our solution is it's not just a matter of the solution.
It's also a matter of planning that recovery design.
And, and then the FMO question again, kind of depends on what solution you're using with our solution. We're we are gonna make that decision based on what was in place previously. And if we're not, if all the FMO roles aren't recovered, we will recover them to the DCS that are being restored. But if you, if you are, if you're doing it yourself, you do need to think about making sure that if you're not backing up all the FMO role holders, then you wanna make sure that you have a process in place for seizing those roles when you rebuild the new forest.
Great.
And, and I think this is the last one it says, is this ad backup stored on the windows server operating system?
So assuming he's talking about our solution, then the answer would be, yes, it's stored and encrypted on a, just a, basically a standard file server, whatever that happens to be, it can be the management server itself, or it can be a distribution point that I talked about that's distributed on the network.
And again, you know, you wanna make sure that at least, at least your most recent, if not a most, couple recent backup sets are also backed up and offline, but yes, those are stored on just standard windows servers.
Excellent.
Well, I think we've come to the end of all the questions here, and I wanna thank you again, Darren, for joining us, and also thank everyone in the audience for joining us today. As I mentioned at the beginning, a recording will be available tomorrow. If you want to go back and look at some of the slides and an executive view document by myself on the some Paris DS protector product will be available probably within a few weeks. So that's something else to look out for on our site. I hope to see you at one of our upcoming events and future webinars and have a great rest of the week.
And thanks again for coming. I'll call it a day and goodbye for now.
Thanks everyone.
