Hello there. My name is Matthew Vinton. I'm a strategic systems consultant with Quest Software. Today we're going to look at security groups within Azure Active Directory and what happens when I go away and how we can recover those using both native capabilities as well as using Quest On Demand Recovery and tell me what the differences there are.
So let's take a look in my Azure Active Directory Environment. I have a group named concur submit expense reports. So you can see this group is a security group. It is actually sourced from On Premises Active Directory. But what I'm going to be talking to you today about would be true even if it were a cloud only group. Security groups behave in the same way whether they're mastered on premises or exist only in the cloud.
This group has a couple of members, Abby Irwin and Matthew Vinton, myself. So let's take a look at what this group does. You know, security groups do not exist in a vacuum. They are typically used to secure things. And they can be used in a number of different places. Today I'm going to focus in on one place, enterprise applications. This is a very common use for security groups in the cloud is to provide access to applications and service principles that are defined within Azure Active Directory.
So as you might guess, concur is where that application-- where that group is being leveraged. So if we go into users and groups, we can see that concur-submit expense reports it's both used to assign this application as well as to assign a specific role there. And even more than that, this group is used in another place within this application. There is a conditional access policy assigned to the concur application.
What this access policy does, it says if you are a member of a certain role, we require you to use multi-factor authentication when you're logging in to access its application. So if you have your access panel open and you click on that, it's going to basically repoke you to enter your second factor because this is a sensitive application. We assign that using the same security group we used to sign the application and then sign the rule.
If we take a look in the access panel here, you can see that I have the concur application that's associated with me right here. All right. So let's go back and take a quick look at this group again.
There is not that much to it. We have the name. We have whether it's assigned, what kind of group it is. I'm going to go ahead and take a quick screenshot of this because we're going to refer back to it here in just a moment. We'll put that away for right now.
So let's explore a scenario where this group goes away in the cloud. With a hybrid group, it's actually pretty easy to lose these groups in the cloud. Most organizations don't synchronize every single user in every single group on their on premises active directory into Azure Active Directory. They'll use some form of synchronization, scoping settings that say, all right, well objects in this OU but not this OU are going to end up synchronized.
And if you forget what those synchronization settings are, or maybe you're not aware of those, it's not too difficult to maybe move a group out of an OU into an OU that's not synchronized into the cloud, or maybe you simply delete that group on premises by accident and it ends up in the Active Directory recycle bin, or if you have that set up or into a Recovery Manager for Active Directory backup, or maybe it's a cloud-only security group and it gets inadvertently deleted there during maybe a script gone awry or a identity system that maybe has gotten slightly misconfigured or something of that sort.
Now today, we have the group here on premises. And I have my environment set up so that it scopes things that are included or not included in Azure Active Directory based off of extension attribute seven. If this reads true, that will move it out of the synchronization scope into Azure Active Directory.
So I'm going to go ahead and start our synchronization. And this will take about a minute. And when that's complete, let's take a look, find our group. And our group's no longer there. So now as we would expect, places where that group was used within Azure Active Directory are also missing that group.
So if we go in here and take a look at our enterprise applications, take a look at concur, users and groups, and, ah, no application assignments found. And more than that, if we go into our conditional access policy, well, the policy still exists.
The policy is not broken because it's no longer assigned to a group, which means that even if, for instance, I were assigned access to that application manually in order to in the short term get myself access to it, I still wouldn't have the appropriate security controls in place because that was also tied to that group that is now missing.
Right. So now let's go through the typical process of how we would restore access to that manually. So we know that that group still exists on premises. So let's move that back into synchronization scope and just let Azure AD Connect and Azure AD fix everything. And the other properties, we'll set this to false now.
This will move it back in the synchronization scope. Give it just one second for the domain controllers to catch up. And I'm going to go ahead and start another manual synchronization process.
All right. Now that that's complete, let's go back and go into our enterprise application, concur, and we'll go to Users and Groups. And there's no group there. It could just be that I messed up my timing on that. Maybe I ran the connector before the appropriate domain controller had received the correct thing. So let's look for our group itself. It's probably not there.
Oh wait a minute. There it is. Take a look at this group. Well, that looks exactly the same. Concur-submit expense reports. It's assigned security group served from Windows Server AD. And look, my membership's there as well. [INAUDIBLE] Matthew Vinton. But why have I lost access to that still in my access panel? Concur's gone. No matter how many times I mash this refresh button, it's going to stay gone.
Let's take a closer look at this group. See concur-submit expense reports. Well, I'm going to compare that to my screenshot. That's the same. That's the same. Wait a minute. One of these things is not like the other, a very important part of this. Take a look at the object ID. They don't match. Matter of fact, I look at the creation date on this and they don't match either.
This is, for all intents and purposes, a brand new security group, despite the fact that the group that it's being synchronized from on premises isn't brand new. That group never changed. It was never deleted. It was never recreated. All it did was move out of scope. Now I have a brand new Azure Active Directory group.
So now to fix this manually, I have to have perfect documentation. So I need to know where and what this group is used for so I can go back into the application and I can reassign that. This group I might be able to intuit that. Concur-submit expense reports. It's pretty obvious. But in larger organizations, or maybe your group naming standards aren't as obvious, or maybe this is used in other places that I didn't think about.
So now let's take a look at what it would be like to recover that using On Demand Recovery. On Demand Recovery is a true backup recovery solutions. The first thing I'm going to do is I'm going to unpack a backup that I made before this whole issue occurred.
This takes a few minutes to unpack. What it will do is it will unpack that backup. And it's going to compare the contents of that unpacked backup with what is live in production. And then I can easily see the differences between those.
All right. Now that that has finished unpacking, let's go to the differences tab within On Demand Recovery. So this will show what is different between the backup and what's live. You can see this is a very accurate representation of what's just happened. You'll notice here that the group concur-submit expense reports was hard deleted. This means that it's gone gone. We can also see that the application rule assignment has now been removed as well because that group disappeared.
In addition, when we resynchronized to try to fix this problem, you'll see that a brand new object was created, a new concur-submit expense reports containing both myself as well as Abby Irwin. Now On Demand Recovery is smart. So despite the fact that we have tried to manually resolve this, we have a brand new group in play, all we need to do in order to restore this group and what that group is used for is to put a check mark next to that and click Restore.
Now you can see I can actually go into the individual, like for instance application rule assignment, and restore that as well. But restoring the group itself is a good way of just making sure that basically you have coverage over where that group might be used. So let's go ahead and click Restore and watch what it does.
All right. So we can see that the task is started. Now On Demand Recovery is intelligent and it's hybrid aware. So in this particular instance, it has been configured to work seamlessly with Recovery Manager for Active Directory on premises. So it knows that it is a hybrid group, a group that is, in fact, mastered from on premises, which means that it's going to look at the on prem object to make sure that it's correct, see whether there's any restorations required there.
Now again, if this were a cloud native group, this wouldn't be applicable. But if that group had happened to be deleted on premises and was still deleted on premises, this would actually then recover that group as part of this. But essentially, it's making sure the source object is correct by using its knowledge of on premises. It's going to do a quick delta synchronization to make sure that that is correct and any changes that it had to make were synchronized back into the cloud.
And then once it is assured of that, it's going to take that object in the cloud and it's going to look at the places where that object and where that group was being used to secure things. In this particular case, again, application and service principle, assignment and role assignment as well as conditional access policy. And it's going to put those values back.
So you don't have to remember where that group was leveraged in the cloud. Because we're taking backups, we know where that group is leveraged and we can fix those permissions. Even though that object is still going to have a different object ID than the original one, it won't matter because we're actually restoring the places where that group was used within the cloud.
See there object attributes were restored. Assign the concur to the concur-submit expense reports application and role as well as the conditional access policy, so at this point, this is complete. Let's take a look at what we have within Azure Active Directory. Go back down to Enterprise Applications. Take a look at our concur application. Users and groups. The application is back. The appropriate role that that application was-- that group was associated with is back.
If we go back to our conditional access policy, that is back as well. So now not only do I have access to my application again, but I also have the access policy defining my step up authentication to that application. Look, it's there and back. So all it took was one click and On Demand Recovery was able to figure out what needed to happen, whether that involved changes on premises, whether [? the ?] changes were just in the cloud, and I was able to tie the newly created security group back to the places where it was secured.
So I hope this has been useful in understanding the differences between how to recover from a security group deletion natively versus how we do it with an on demand recovery. Thank you for your time.
15:17
