Hello. My name is Matthew Vinton. I'm a strategic systems consultant with Quest Software. Today I'd like to talk to you about applications, service principals, and how to recover them. Before we dive into the how to recover them, let's actually talk a little bit about what they are, and what they do, and what kind of problems they can cause if they're missing.
So applications and service principals are one of the things that it can be a little confusing. And part of that is because of different terminology. I'm using the technical terms, application and service principal. But if you take a look in the Azure Active Directory portal, you'll see that we have no mention of service principals anywhere over here to the left.
We have enterprise applications, app registrations, application proxy. All those sound like they could have something to do with applications. But what does what, what's recoverable and what isn't, and what do they do?
So service principals are basically an instance of an application. They are the specific aspect of an application in your tenant. They're defined here under enterprise applications. So enterprise applications are service principals. You'll notice here there's a great big long list of these. We have Salesforce. We have Quest on Demand, which is one of our products. Has a service principal.
Each of these service principals has its own object ID. And it also refers to an application ID. The application ID, the actual application itself, is kind of like the template that the service principal is generated from. So those templates are listed right here under app registrations. We go there we can see that there are applications defined with an application ID.
But this is interesting because if you remember, enterprise applications have a long list of service principals underneath of it. And there's only five applications listed here. For every service principal, there has to be an application for it to form out of it. And in fact, the application defines a lot of the pieces of a service principal.
One really important thing to keep in mind is that applications, the route, the template for the service principals can either be specific to your tenant and defined in your tenant or they can be defined in someone else's tenant. So you see here Salesforce is defined here within this actual tenant in the specific organization. There's a bunch of interesting things defined here-- certificates, secrets, all that good stuff.
But alternatively, on demand for instance, these application IDs are actually defined in Quest's tenant. And the service principal is based off of that. You can see here we have on demand group management. So this application ID exists in Quest's tenant, not your tenant.
Now what do service principals do? Why are they important? And what happens when they go missing or are changed in a way? So service principals can do several different things. But two very common aspects of them are publishing a single sign on application into the Azure application portal. So that, if we take a look here for Salesforce, that's how that's defined.
This Salesforce is all about provisioning an application with single sign on defined. It's disabled in this particular case. But with single sign on, it would be typically SAML would be set here. And there will be users and groups associated with that.
The users that would be a part of this group will actually see this and have access to that. There could be conditional access policies associated, which is specific controls over how that application is authenticated to. You know, maybe it requires two factor, something of that sort. So this is basically the single sign on presentation of the application that's defined in your environment.
Or another example. Again, I'm going to pick on Quest on Demand here, is Quest on Demand group management. This service principal provides access to our application to your tenants. So it has permissions associated with those. It also has users and groups associated with those as well for end user presentation. But its primary purpose is for these permissions here so that you can consent to these permissions and our software as a service application can work on your behalf.
If we take a look here inside our dashboard, look at Tenants, Go, you can see group management has been granted consent. That consent grant is basically an application that gets defined in here, a service principal that gets defined in here, and then the appropriate permissions are associated with that.
All right. So let's go ahead and let's delete some of these and see what it's going to take to get these recovered. So I'm going to delete the service principal. Now remember I can't delete the application for Quest on Demand group management but I can delete the service principal.
Now if I go back here to our application registrations, I'm going to go ahead and delete this Salesforce application. So this is basically the template. And when I do that, it not only deletes the template but it also deletes the Salesforce service principal. Remember those have a symbiotic relationship. You can't have a service principal without an associated application. If that application disappears, it's deleted like I just did, it also takes away the service principal.
Let's talk about what it would take to get this back-- to put these back the way they were. Applications actually end up in the recycle bin but not service principals, which means that I could go and undelete the Salesforce application but I would still need to recreate from scratch the Salesforce actual service principal, which is actually probably equal or greater amount of the actual configuration since that's where we're signing up permissions from. That's where roles are defined.
That's where the SAML configuration actually occurs. In addition to that, when I deleted the service principal for On Demand Recovery, if I take a look
13:08