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
15:17