How Microsoft 365 Admins Can Manage and Protect Entra ID Apps

Dec 30 2024 - Discover the essential strategies for managing and securing Entra ID App Registrations and Enterprise Applications in Microsoft 365, covering key features, best practices, and security measures.

Entra(This post belongs to a series)

entra id

microsoft graph

12 min read

Entra ID is at the heart of Microsoft cloud services for identity and access management, supporting platforms like Microsoft 365, Azure, Power Platform, and Dynamics 365. It also integrates with custom applications, including Microsoft 365 Copilot and other AI tools, which are increasingly popular.

For Microsoft 365 and Entra ID administrators, the proliferation of applications can clutter the IT environment with orphaned apps or expose security vulnerabilities. This guide covers the basics of Entra ID administration and offers strategies to manage and protect these critical services.

Which Portal?

You can manage Entra ID via the Azure Portal or the Entra Portal. Key links include:

App Registration

App Registration within Entra ID is the starting point for all applications that will integrate with Entra ID. The application can focus on just your tenant or can be exposed to work with other tenants and/or personal Microsoft accounts as well.

In a multi-tenant scenario, we start out with an App Registration in your tenant. However, when the application is used by another tenant and consent is granted, it will appear as an Enterprise Application within that tenant. The App Registration won’t appear in the consuming tenant. That just lives in the original location.

Note: Entra ID also supports authentication via other identity services such as Google and GitHub via Business to Consumer (B2C) services, but we won’t get into that right now.

Sample App

Let’s create a new App Registration for a sample application. The sample application will be single tenant. We’ll just use this to help walk through our scenarios.

Once the App Registration has been created, we can start to configure it based on how it’s intended to be used. Before we get to that, let’s call out some important pieces of information.

Application (client) ID
- This is the client ID that is used within an application or application integration (e.g., Power Automate)
Directory (tenant) ID
- This is your tenant ID
- This would be the same for all single tenant applications in your tenant
- Frequently used as a configuration string when authentication is applied

Before we go too deep into the App Registration process, let’s talk about the Enterprise Application.

Enterprise Application

As noted in App Registration section above, when an application is granted consent, it becomes an Enterprise Application. An Enterprise Application is also known as a Service Principal.

https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals#service-principal-object

The client ID for the App Registration and Enterprise Application are the same value. However, they are two separate entities which have different configurations.

If changes are made at the App Registration, such as adding additional scopes, those are not intrinsically applied to the Enterprise Application. Those changes would have to follow the same process of granting consent to approve of the required changes.

In a production environment, you’ll most likely have more Enterprise Applications that App Registrations. Those Enterprise Applications could be to configure Single Sign On (SSO) with other vendors and possibly via SAML. There are many application vendors now that integrate with Entra ID via the App Registration via Multi-tenant as we’ve noted earlier.

Consent is the action to approve of an application and it’s associated with scopes. There are User and Admin level consent which dictate what level of scopes can be approved. Further, the tenant can also restrict access to user consent and even an approval process for any application consent.

Consent can be made directly in the portal within the App Registration > App Permissions section.

It can also be done via the browser: https://login.microsoftonline.com/{organization}/adminconsent?client_id={client-id}

This link provides instructions to configure user consent settings (requires Privileged Role Administrator): https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent?pivots=portal#configure-user-consent-settings

This link provides instructions to configure Review admin consent requests (requires Cloud Application Administrator): https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/review-admin-consent-requests

Once consent is granted, the application will be able to interact with the defined scopes. If the application is multi-tenant, then the consuming tenant will have to grant consent as well.

With the Enterprise Application, you can see the permissions that have been granted. You can see the permissions that have been granted and the status of the consent.

Authentication

The Authentication section defines which platforms, and thus what endpoints will be exposed, that will allow for authentication. In this example, we’re going to expose a “Web” endpoint.

This goes beyond your natural assumption here of a custom website, as this is frequently used by other services such as:

Microsoft Teams Copilot Integration
AI Bots like SharePoint Agents
Microsoft Power Automate

As you can see below, we’ve added a redirect URL for our sample application. When authentication occurs for this application, this is a valid redirect URL that Entra will send back messages to during authentication.

This is typically:
https://login.microsoftonline.com/<TENANT_ID>

The application will know to send authentication to Entra and provide the Application (client) ID along with the redirect back to the application to complete the action.

Let’s say you were going to use Microsoft Copilot Studio to build a new Copilot agent and want to integrate with Entra ID. Following Microsoft’s documentation for this (Microsoft Copilot Studio Authentication), you’d configure the Redirect URI to point to:
https://token.botframework.com/.auth/web/redirect

You can add additional redirects.

API Permissions (Scopes)

At this point, the Sample application has enough to handle delegated access for user authentication. This is because the default of Entra ID for new App Registrations includes adding a Delegated scope for User.Read.

API permissions within App Registration is how we tell Entra ID what type of access to resources are allowed via this Application (client) ID.

By clicking the “Add a permission” button, we can select which service/application we want to define a scope for. In our example here, we’ll click on Microsoft Graph.

Now we’re presented with two options: Delegated & Application

Delegated Scope

Delegated means the application can work with the Microsoft Graph, but only doing so on behalf of the user. Thus, when the application authenticates a user and then access Microsoft Graph resource (which we’ll define next), it will do so based on the level of access that the associated user has. After selected “Delegated”, we’ll see this:

Let’s say our application wants to access SharePoint Lists, here are two scopes that can provide this:

What if the application has these Delegated scopes, but the user doesn’t have access to any SharePoint lists or has licensing?
In this case, the application will make their associated API calls but will either return an empty or failed response.

Application Scope

Application scope is another ball game. Essentially, you’re giving the application access to all the information available within the boundaries of the scope you select.

Taking the same scenario as above, we’re instead going to define an Application scope for those same two items for lists.

Now the application can interact with ALL Lists in the tenant, regardless of the signed in user has access to them or licensing.

How can the application interact with the defined scopes, regardless of delegated or application, beyond just authentication? This leads us into our next section.

offline_access

Let’s not overlook the offline_access scope within Delegated and Application levels. By granting this, you’re letting the application know that it can request an access token (and later use the refresh token) to act on behalf of the user even if they are not currently interactively logged in.

There are valid scenarios for this, of course, but we should ask why before just allowing any application to do this.

Certificates and Secrets

When an application needs to interact with the scopes that have been defined for it, regardless of delegated or application, it needs to call the associated endpoint but first it also needs to authenticate.

At this point, I won’t cover the many ways how this is done within the application, but instead focus on what it will need.

Navigating to the “Certificates & secrets” section of the App Registration, we can create a new secret to be used by the application. Secrets are basically a password. Unlike a user with a single password, you can create many secrets and certificates for a single application.

After you create the secret, the value of that secret will be available but only for a short period of time. After that, you won’t be able to get that value again! Make sure to copy and paste it into the secure location you plan to manage it in.

Ownership

Assigning ownership for a given App Registration shouldn’t be taken lightly as it allows those users to configure the application in a way that may go beyond what your organization intends. That said, the App Registration doesn’t mean much until consent has been given which requires additional roles (e.g. Global Admin or Application Administrator) to approve.

https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions#object-ownership

The Manifest

All of your hard work in configuring your application is also available in Json format. You can update the manifest directly, for options that are permissible. This is also a good way to do a many copy of the configuration as a backup and before you make changes.

https://learn.microsoft.com/en-us/entra/identity-platform/reference-microsoft-graph-app-manifest

Conditional Access

Security is a layered approach. Even if you’ve ensured that the application is limited in the scopes that are available, protected certificates and secrets, and the application is well developed with testing, we can further secure it via Conditional Access.

Conditional Access is often scoped at the user and device level. However, the application itself can have its restrictions applied via Conditional Access.

For the users and devices, the Enterprise Application can be explicitly defined within a typical Conditional Access policy.

Since the application itself can interact directly via Entra ID, it needs something special which is called, “Conditional Access for workload identities”. This is only usable for Enterprise Applications that originate in your tenant (thus you have an App Registration for it in your tenant) and yes it requires a “Workload Identities Premium license”.

Note: At the time of this posting, the price is $3.00 (USD) per workload identity/month.

By leveraging Workload Identities, it can put additional requirements such as locations to ensure that the application is running in a location that you approve. As an example, you can ensure that only developers in specific countries and/or IP can interact with the application. And in production, the application is only calling from an approved external IP (e.g. .NET Aspire based application running in US East 2 via dedicated IP).

You’ll then have access to Risky Workload Identities within Entra Identity Protection.

https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk

Operation Activities

This post wasn’t intended to be a deep dive in all the capabilities of the App Registration and Enterprise application configuration with Entra ID. Based on what we’ve done already, let’s look into what we could or should be doing as an IT administrator for Entra ID.

Trust by Verify: Certificates, Secrets, and Tokens

As an IT administrator, or perhaps in security/compliance, you should request access or a screenshare to see that certificates, secrets, and token management is being applied as required. A little supervision is required to ensure risks are mitigated.

As you’ve seen in an earlier screenshot, you can see when the secret was created and when it expires. We shouldn’t depend on the application to alert us when it’s about to expire.
We should have a process in place to ensure that the secret is updated before it expires and that the old secret is removed from the application. We should also have a process in place to remove the secret from the application if it’s no longer needed. Especially if the application is no longer in use or not in active development.

Monitoring Access

As users and the application authenticate into Entra ID, you can check the Signin logs to either in Entra ID or via Azure Log Analytics workspace (if you have this configured. Which you should). When you do, you can filter based on the Application (client) ID and then assess from there.

Using PowerShell along with Azure Log Analytics workspace, you can create a report that can be sent to you on a regular basis. This can be done via a scheduled task or Azure Automation. This can be a good way to ensure that the application is being used as intended and not being abused.

Questions to Ask

When working with users and developers in your organization looking to integrate with Entra ID and they request the creation of a new App Registration, here are some questions to ask:

Do you need a certificate or secrets? If so…
- How and where will they be stored
- Who can access the certificates secrets
- How are they accessed by the application
Will the application directly handle access and refresh tokens? If so…
- How and where will they be stored
- How are they accessed by the application
Will the application require Application scopes? If so…
- Why is Delegated scopes not good enough
- How does the application protect and control the information

Guidance

Make sure to add “Internal notes” within “Branding and properties” to reference any of the following (max 1024 characters):

App: Copilot Studio for HR
Source: GitHub URL
Azure Tags: AspireProjectSales
Ticket: (Ticket number of request for this)

If you have an application that only requires any of the following, you would be ok to have a single App Registration:

Public URI’s
Delegated scopes

If you have an application that has any of the following, you should create two App Registrations. One for development and testing, and the other for production. It would require updating production as required but reduces the risk in security.

Localhost URI’s
Application scopes
Certificates & secrets

Additional Guidance:

Certificates should be used over secrets as much as possible
For backup and diagnostic reasons, automate your export of the App Registration Manifest via PowerShell or manually copy.
Restrict access for users to consent to applications to prevent shadow IT

Conclusion

Effective management of Entra ID applications ensures a secure, organized IT environment. By implementing robust security measures, auditing practices, and proper configuration management, Microsoft 365 admins can minimize risks and maintain compliance.

If you’re an ISV, MSP, or enterprise IT team looking to optimize your Entra ID application management, reach out to me! I can help you develop a comprehensive strategy for securing and managing your Entra ID applications.