Name: North America Identity Recovery Lunch & Learn
Uploaded: 2025-07-17T18:46:03.673Z
Duration: 30 min 12 s
Description: North America Identity Recovery Lunch & Learn

Transcript for "North America Identity Recovery Lunch & Learn": Hello. Welcome, everyone. My name is Waisau. I lead identity security for PMM here at Rubrik. I I joined a few months ago to bring our identity security products to you all, and we've been amazed to see how receptive folks are to it. I'm just so very lucky to get to work with an awesome solution that we'll be covering today. So thank you for joining our demo session on identity recovery. Over the next forty five minutes to an hour, we'll go through some discussion on what is identity recovery and then kick it straight into the demo. I'll try to get to some of the q and a live, but what will, we've historically seen is a lot of engagement there. So we do try to get to all the questions in the limited time that we have. So feel free to drop your thoughts into the q and a as well, which you'll find at the bottom of the screen. I love to see the activity, and it really helps us to know where your head is. So, ask away. Let's open up the dialogue. We're all going to be learning from each other today and hopefully have a bit of fun. So, whether you're sharing some active challenges you see or using the reaction emoji option to show some love, it's all welcome. Right. Let's jump into it. Today, we'll set up the conversation by briefly discussing what's going on in the threat landscape, in particular with how it affects identity. Then we'll jump into a discussion on Rubrik identity recovery, and the bulk of the session today will be focused on the demo lab. My friend Kev will show how it looks and works, and, of course, we'll get to your questions as well throughout the end throughout and at the end of the demo. So identity is under attack. This is something you probably already know, and it's why you're here. Now, typically, if something happens, it probably happens through a compromised credential or an attack vector that is related to identity. A major reason Rubrik started to look at identities is because we protect the data. And what we often saw time and time again is those who are after critical data usually walked right into the environment as a user or an admin, you know, whether they were using stolen credentials or it was insider misuse. This speaks to, you know, a bit to the evolution you'll see with Rubrik and really looking forward with how to keep our customers safe and resilient. And by resilient, I mean protect it protecting, our customers, but also ensuring your environments don't go no don't go down. And if they do, they're down for as little time as possible. So as far as what we've seen, on a macro level, there's just a ton of stats around this. An example would be a report from IDSA from last year that shared ninety percent of businesses experienced an incident related to identity in the previous twelve months. That means most organizations had to deal with something or someone causing issues via an via an identity vector. But we're here, and we've got another one here from Security Boulevard that speaks to the sort of more malicious nature, with fifty percent of businesses having experienced an AD attack in the last couple of years. And with Rubrik, we've seen we've been in the data protection and data security space for quite some time focusing on cyber resilience. And the fact is data is available to users. And so if an attacker wants to get access to it, the easiest way, the most widespread attack surface with some of the most vulnerabilities is going to be a user, And so an identity, essentially. So they're going to find ways to compromise that user, gain access to that user's identity. And that means they're gonna do anything that the user can legitimately do. And if they're able to get privileged access or admin credentials, escalating privileges or moving laterally throughout your systems, it can really create some issues, to put it lightly. So now let's take a look at active directory, for example. I still hear folks say, you know, you don't need to back up your domain controllers because they back themselves up. And I can see why they might say that. It is a highly distributed service. You typically have multiple domain controllers per site, and you typically have multiple sites. Everything is multi master replication. So if something goes bad, we just take one domain controller out of play and deploy new domain controller. Then everything just replicates, and we're back up and running. Right? But as you already know, attackers are always getting creative and finding ways to use what you have against you. So that very highly distributed, highly replicated architecture is actually super useful for an attacker too. Because once we can compromise one domain controller, we can effectively compromise the entire domain. And from there, potentially, the entire forest. So once they've done that, they've effectively taken relatively small amount of effort and have taken down your AD. So once they've done that, they've effectively taken down your AD with a relatively small amount of effort. And once AD is down, we all know what happens next. Not very much from business perspective. Right. So now that we've shown what happens when attacker takes down your AD and it goes from a highly redundant, highly resilient solution into a very bad day in the office, let's take a look at what solutions we have at our fingertips. We have a ton of customers who are backing up AD. They're protecting it as, you know, native snappables with Rubrik today, which is great because it gives you the ability to recover that domain. And we also see customers backing up active directory domain controllers as virtual machines. Again, all great. But when it comes to recovering forests, it can get very, very complex. So we looked into what customers have to do for active directory forest recovery or ADFR. We looked at Microsoft documentation and found that it was not only, you know, 20 plus recommended steps that you see the screenshot here for, but, these are manual steps that you need to take in order to manually stitch everything back together and somehow get it all working again. So here we'll we just got a quick view. There's 29 pages of documentation for how to get through this, whether it's looking at how we need to reconfigure DNS because everyone does DNS differently or synchronizing DFSR replicate sys falls or dealing with changes to the red pull. Depending on what you need to do, you will need to manually go through the documentation and figure it out and try to follow all of those Microsoft best practices while you're at it. And you'll need to ensure you're doing it doing all of it in order because if you don't and you do it in the wrong order, potentially, everything's broken again. So you're starting back from square one. You're recovering from backup again, so on and so on. And let's not get started on large domains or large forests with many, many root trees, and child domains. So to say it simply, it's complicated. So if we think of identity services like AD or ENTRE, they're the keys to the kingdom. And so if your identity services are compromised, like the example I gave earlier, everything is down. You can't authenticate against Exchange, against SQL, and users no longer have access to the resources or data they need to do their work. And so your business is effectively unable to function. IDPs are literally the tier zero of tier tier zero applications. So let's cover a few challenges with existing solutions today that really informed the solution you'll see in the demo today. So if you're using a point solution where they take, the backup and put it on SMB share, they then might back it up with another backup vendor. But if the backups are written onto a natively shared file system, they're exposed, which means they can be compromised. So now you're dealing with the prolonged downtime and the financial loss of that downtime, and then we think back to trying to recover. As I showed earlier with the Microsoft documentation, this can be incredibly time consuming, manual, and difficult to manage. Lots of opportunities there for errors. One step in your very long checklist, and you may be back at square one. And with existing solutions today, you'll likely have multiple tools involved, which I'll expand on soon. But, effectively, you are dealing with many tools, more overhead, as well as the cost associated with it, resource management, dealing with sort of all the downstream effects of that. And when we look at the recovery options available, it may be limited in that you can only recover specific objects in active directory, or maybe you can only recover users and roles within Entre ID, or maybe you need separate tools for both of these things. Or if you have a hybrid environment, you can only recover one and not the other, leaving you sort of in a bad situation still. Right? Now we dig deeper on why legacy or point solutions may not be the solution to solve for this. Let's look at the life of a typical I'm admin, and let's take active directory again as an example. I'm admins are doing their job, following best practices, and doing sort of all the things they are expected to do with ensuring users are onboarded, applying all the right policies, but he needs to recover because something has gone down. So they go to a point solution like Simparis and work with them. And what they do is they take your AD back up and write it to an SMB share. Great. So now you're working with the storage team who needs to provision that SMB share to you as well. But that SMB share is vulnerable because it could potentially be seen by anyone on the network. And that means everything you need to recover active directory can be as well. So everything from usernames and passwords. Right? And then you need to make sure you've got a copy of it offline. So then you involve a different storage platform. Imagine needing to manage these downstream dependencies and work through them for a recovery. And if you think about it, if an attacker is able to compromise active directory and all of these are dependent on AD, it's not a far cry from something, in this recovery process breaking as well. So with Rubrik, we built a solution for identity recovery that solves for all of these issues. Rubrik takes the need for these multiple vendors, tools, and dependencies out of the picture. Our solution is natively immutable with a logically air gapped storage appliance that includes all of that backup software, which means it's all built into a single platform. And that means one person potentially could just manage it all. So and if you've got a globally distributed organization, you'll likely be taking backups from, let's say, Singapore, Berlin, Sydney, New York, Dublin, you name it. And you're not going to want to be pulling all of that to a single location. So it's great that we can deploy clusters wherever and manage them as a single entity. Now how does, that help with Rubrik identity recovery? Well, this gives us, the ability to quickly and confidently recover a clean copy of your identity services. So we can take all of these 20 plus steps per domain and throw them in the trash. We orchestrate that and make it a five step process, which Kev will show later in the demo. And Rubrik gives us this easy to use shopping basket style type of approach. So we just need to recover a single object or just a few objects. We can just go down that list. We can check off the list and add them to the cart, for all the things I need to recover from this recovery point, from this point. And with that, we'll recover them into active directory or or Entre for you. And with the single platform, we can cover both AD and Entre. Everything from users, groups, roles, enterprise apps, app registrations, as well as conditional access policies. And something worth mentioning is the ability to go super granular. So let's say you have a user and you have you notice odd behaviors with that user of the last few weeks. You can go and, compare all of the individual attributes of that user between a backup from a week or two ago, and what it's doing, now. You can see everything that's changed. You can roll those individual attributes as well. So you can roll back those individual attributes as well. So before we head into the demo, I'll quickly just cover the benefits of leveraging Rubrik identity recovery. So before Rubrik, we had exposed backups. But with Rubrik, you've got immutable backup and orchestrated recovery. And, you know, that complex process, for recovering, that we talked about earlier with the many tools, vendors, and teams, Now it's just a streamlined tool and process with Rubrik. And then being able to take all the tools and get the solution with one single platform means a lower TCO as well. And, of course, the ability to cover hybrid environments is key. If AV and Entre is down and you cannot orchestrate recovery between both, you may still be down. With Rubrik, you get all that from a single source. Great. So now let's kick it over to Kev who will go through the demo and show you the solution in action. Alright. Thanks for the intro, Waisau. So you've seen some of the capabilities that identity recovery has and how it can really help when it comes to the protection of active directory and EntraID. Now I'm going to show you what it looks like in product. So first things first, let's take a real quick look at Entra ID. While this product was previously known as Azure AD, this is in fact a completely cloud native identity provider, not just a copy of active directory running in the Azure cloud. Rubrik protects ENTRE as a fully managed service. Once onboarded, we assign an SLA domain from this screen here, and this ensures that all supported objects in the domain or tenants are protected. Here, we just have a single domain that's replicated from an on premises active directory domain using Entre Connect. This is a pretty common configuration, but it may be that you have multiple domains within a single tenant. If I needed to change the SLA domain, I can do so by clicking here. If you're unfamiliar, SLA domains are how Rubrik defines protection policies. I'll be covering SLA domains in a little more detail in a couple of moments. If I click into this domain, I can see this summary view, which shows me that the SLA domain assigned protected objects. As you can see, right now, we have a reasonably small number of users, groups, and roles, as well as a number of enterprise apps and app registrations. Coming soon, we'll also be able to protect and recover conditional access policies. If I wanted to recover, I just needed to need to select a point in time from this calendar view over here, and then select to recover. Again, right now, granular recovery is the only option, but watch this space. You'll note up here this message telling you that user sync from active directory cannot be recovered using Entra ID. If you had objects that were synced, as we do here, you'd recover them first into Active Directory, and then once synchronized into Entre using Entre Connect, we can recover the Entre specific attributes from backup. This is in line with the Microsoft process, but rest assured, we're working hard to make this easier for you. You can see that we have this super simple shopping basket approach. Simply select the objects that you wish to recover. Let's grab some users, some groups, some roles, maybe a couple of enterprise apps and app registrations for good measure, and then click next. By default, we'll recover the app registrations with the enterprise apps, but if you have a use case to recover only the apps, you can absolutely choose to do so. Likewise, you can choose to recover only the app registrations. We can choose to either roll back or update the relationships for the objects during the recovery process. The difference here is whether you want to retain the existing relationships or recover to the relationships at the point in time that the backup was taken. When recovering users, by default, Rubrik will generate a random password for each user, which we don't store. The workflow here would be that you would then use whatever password reset process is in use within your organization, maybe a help desk call. As an alternative, you can specify a password for each user, but this is generally discouraged from a security perspective. We will also force multi factor authentication for the password reset process. Again, you can choose not to do this, but it is highly discouraged. So that's how easy it is to recover objects and their relationships in Rubrik. Users, groups, rules, enterprise apps, and app registrations right now, conditional access policies, and more coming in the not too distant future. As I say, watch this space. Okay. Let's switch focus a little. I did promise that I talk a little bit more about SLA domains, so let's see how we build those out. An SLA domain follows a declarative model to replace what you might previously have needed multiple products, or at the very least, multiple policies to handle. We start by defining which type of object this SLA domain should protect. Working in this way means we're able to build a single policy that can be used to apply protection across on premises, cloud, and SaaS workloads. SLA retention lock is an optional extra protection that can be applied to protect against the idea of a rogue administrator or an administrative account compromise by preventing a single user from being able to reduce the retention period for an SLA, which is a common tactic used by adversaries to help guarantee a payout. This can tie in with Quorum authorization to provide a four eyes type of work flow similar to what you see for the nuclear codes in the movies. We define how often to take a snapshot and how long to retain them. We can also define whether we want to archive backups off to more cost effective storage or to rip replicate them to a separate Rubrik's secure vault cluster for disaster repair recover repurposes. Okay. So that's the TLDR on SLA domains. Next, let's take a look at active directory. So from this main view, we can see that we have a couple of standalone domains, and then we also have this forest, which I'll select. Rubrik automatically discovers the relationships between the domains within a forest. We can assign the SLA domain at the forest level here, but at the same time, we know that AD can be a globally distributed service. It may be desirable to set different SLAs for different sites so that you can protect each site with a local route Rubrik secure vault. When it comes to recovery, Rubrik's security cloud orchestrates across these different Rubrik's secure vault to recover as required. Clicking into a specific domain controller, we can see the assigned SLA. We can see the FSMA roles it holds, and any extra server roles, such as DNS. It shows us the operating system and the details of all of the users, groups, computers, group policies, etcetera, that are protected. These can all be recovered on a granular basis if required. Let's be honest here though. We're here to talk about forest recovery, aren't we? To do this, I simply select the forest and click recover forest. This launches a simple five step wizard to gather all of the required configuration details, and Rubrik orchestrates the entire recovery. No manual stitching required. We obviously need to select the closest point in time to recover into. Next, we decide whether to recover in place, which would simply roll back the existing forest to the selected point in time, or we can recover to alternate Windows hosts. This workflow might be more useful in a cyber attack when you can no longer trust the existing environment, and you're standing up your minimal viable business in an IRE or an isolated recovery environment. In order to stand these things up, identity services are fundamental. So let's go down that route. Regardless of whether this is in place or to alternate hosts, there are some other things fundamental to active directory, DNS being the first. You may be running only AD integrated DNS, and if that's the case, you likely want to stick with this default setting. If, however, you're using an external DNS provider such as Infoblox, for example, you can enter the upstream server details here. Finally, we can just leave the DNS server settings that are already configured on our recovery hosts. There are three more things that we might need to configure here. As with DNS, time is fundamental to Kerberos, which is in turn fundamental to Active Directory. We can recover the Windows time service on the recovered DCs to the configuration in the snapshot, or simply point to the point the recovered servers to another time source if this is more appropriate. We will also, by default, rebuild the global catalog and reset the Kerberos ticket granting ticket service account password, though you can opt out of both of these if you need to. Cool fact. The password history for the k r b t g t password is two, so we actually need to reset this password twice in order to ensure that no old DCs can replicate with our recovered setup. Of course, we do that. Our next step is to define where we want to recover each DC to. Remember, we selected to recover two brand new servers. We can see that we've selected the DC with all the relevant FSMO roles here, but we can also choose a different domain controller in the domain by selecting edit DC selection. Select a new host that's been registered with our SC. Since we don't require domain admin privileges to take the backup, we do need the credentials for an account with domain admin privileges to complete the recovery. These credentials are used only for the recovery and are then purged. We then do the exact same for each other domain in the forest. I'm gonna use the magic of cinema to speed through this for you. One other thing to highlight here. We recover a single DC per domain in line with Microsoft's guidance. By default, we automatically clean up the metadata for any other DCs in the domain from the recovered AD instance. However, you can select to leave the metadata in place if that's what you need. We show you a summary of what you've entered into this wizard. Review this, and when you're happy, click recover to begin the process and go get a coffee. Depending depending on a number of factors, including how large a forest is, how much data needs to be recovered, the network latency between recovery sites, etcetera, this process can take some time. The important thing to understand is that once set, you can walk away while Rubrik orchestrates the entire recovery process. Again, I'm gonna use the magic of cinema to speed through this process for you. Imagine you're drinking a coffee. The first step in the process is to reboot all of the recovery hosts, placing them into directory services restore mode as required. We then first recover the forest root domain. As you can see here, there's a lot of steps that need to be taken to properly recover each domain. These are all in line with the Microsoft documentation. Everything is done by the book. If you're manually performing these steps, you're looking at over 20 steps to recover each domain in your forest. Forest. You get a single step wrong, it's likely you're back to the beginning starting all over again. Once the forest root domain is recovered, the process continues for all of the tree and child domains in parallel. Once all domains in the forest are recovered, each domain goes through a health check to ensure all is good starting with the forest root domain. Once those health checks complete, the forest is fully recovered, and you can look to start deploying more domain controllers to recreate your desired a t a d architecture. The final thing that I wanted to show you is object attribute comparison. While the orchestrated recovery of entire forest is clearly awesome, this is probably my favorite aspect of identity recovery. What this gets you is an easy way to compare the state of an object at a point in time with the live status in active directory. If I select a point in time, then browse to an object, I can select to compare attributes. This takes a second or two, and Rubrik is actually making a live API call to active directory requesting the current state of this selected object. And then it calculates a diff view so that we can see exactly what's changed between the backup and now. Kathy here seems to have had a bunch of things changed. She's now based in Osco? Changes to email address, phone number, remote access capabilities, logging squids, all of this looks no bueno. The nice thing is that that we don't necessarily have to restore the entire object from backup, and we can just select and roll back specific attributes. We can either overwrite attributes or merge with the existing attribute values. Think of group memberships, etcetera here, for example. This screen covers exceptional handling. If an object had been deleted and recreated, it might have the same name, but a different security identifier, for example. We also automatically recreate any missing parent objects, such as deleted or used by default. We're not recovering an entire user object here, but if we were, we could force a password reset as part of the recovery process in line with good security practices. Review this summary. Once you're happy, click recover to begin the process. The recovery process can be tracked on the events page, which you can link to from this pop up down here. Once the recovery is completed, you can also download a report showing exactly what has been recovered. Okay. So that's Rubrik identity recovery in action. Advanced Entre ID object recovery, Active Directory forest recovery, and Active Directory object attribute tracking and recovery. If this has piqued your interest, we'd love to speak to you. Scan the code on screen now, and one of our team will reach out to discuss your needs. And on that note, I'd like to say a big thank you on behalf of Rubrik for giving us your time for this Rubrik live webinar. We know that your time is valuable. We always aim to make these events as useful to you as possible. We hope to see you again soon.