# Entra enterprise applications and app registrations Distinguish app registrations from enterprise applications when reviewing ownership, authentication and API permissions for unattended Microsoft 365 scripts. !!!warning Source-derived reference These notes were recovered from OneNote. Configuration, permissions and operating results have not been freshly verified. Confirm the applicable authority and environment before acting. !!! ## Authentication Used For Unattended Scripts/Apps An Entra App can be found in both "Entra Registered Apps" and "Entra Enterprise Apps" An Entra Enterprise App is the service principal used to access resources in the M365 Tenant. - Think of it like a well dress user account that is only used for programmatic access to M365 services and/or resources. - It can show you which permissions are active and ready to use by the service principal. Entra Registered Apps defines the - The blue print or scope of permissions that the service principal can **potentially** use against the M365 tenant. - Authentication methods (certs and/or secrets) that can be used by to connect to the App as the service principal. Powershell scripts can sign in to M365 with a Service Principal Id (that looks like a M365 UserId) and works like a user account with a very secure login method that allows the script to run without user intervention. Entra Enterprise App contains the service principal Id and the controls to potentially limit what the Service Principal can do in M365. The below goes over the differences between a Entra Registered App and a Entra Enterprise App. ## About Entra Registered Apps There are three main parts to this: 1. Allowing select users to Own/Manage the app. 2. Setting up Authentication methods to the app. 3. Setting "BluePrint" for a range of API Permissions that the app could potentially use. 4. Entra Registered App - Setting/Selecting Ownership of the App If "John Doe" wants to manage an App Registration he needs to be an **Owner** of the registered app **OR** be a member of one of the roles listed in "**Roles and administrators**", there is no need to be in both areas. The **"Roles and Administrators"** and "**Owners**" areas operate independently of each other. | **Option** | **What John Doe can do on this App Registration** | **Best for** | |----------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------| | **Owner** (Owners tab) | Full control: add/remove certificates & secrets, change API permissions, edit manifest, redirect URIs, delete the registration, add other owners | Most common & simplest way to delegate full management of one app | | **Role in “Roles and administrators”** | Only the specific permissions of that role (e.g. you can assign a custom role that lets him manage credentials but not delete the app) | Granular control (least-privilege) | Screenshot shows location of **Owners** and "**Roles and administrators**" menu items. Link to **Registered App** for [PIPS+ Inbound Provisioning Access in Microsoft Entra admin center](https://entra.microsoft.com/#view/Microsoft_AAD_RegisteredApps/ApplicationMenuBlade/~/Overview/appId/6ea6dbde-4aa6-4875-a6e8-76bcea55c9fb/isMSAApp~/false) [Screenshot retained for review](../../review/Review-status.md#asset-cc843675368c062c07f3) 1. Entra Registered App - Setting up Authentication methods to the app An Enterprise App is the service principal used to access resources in the M365 Tenant. Think of it like a well dress user account that is only used for programmatic access to M365 services and/or resources. When you connect to M365 using the powershell, you are logging in using the credentials you setup for the service principal (aka Enterprise App). To reiterate, once powershell session has authenticated (Connect-MgGraph) using a certificate or client secret, the user for that powershell session is the enterprise app (service principal). Link to **Enterprise App** for [PIPS+ Inbound Provisioning Access - Microsoft Entra admin center](https://entra.microsoft.com/#view/Microsoft_AAD_IAM/ManagedAppMenuBlade/~/Overview/objectId/4f716a21-25ff-4922-829c-d82716008220/appId/6ea6dbde-4aa6-4875-a6e8-76bcea55c9fb/preferredSingleSignOnMode~/null/servicePrincipalType/Application/fromNav/) ## App Registrations view deals with - Setting Service Principal Permissions - Setting the authentication certificates or secrets that the Service Principal can use to login to the app. - Setting the API permissions (blue print or scope of permissions) that the service principal can potentially use against the M365 tenant. - Who can manage the Registered App - Owners - Roles and administrators ## About Entra Enterprise Apps **Enterprise Application is a service principal account** that performs accounts on the tenant. The Enterprise App settings let you set - Owners - Owners can adjust Roles and Administrators, Users and Groups etc… in the enterprise app. - Roles and administrators - Roles and administrators lets you pick who can manage the settings in the Enterprise Application. - User and groups If your App has a web login, you can choose which users are allow to login. - Security -\> Permissions (API Permissions) - Shows the permissions that are active and granted for use by the service principal. ## Example Scenario - When you need to let your colleague rotate the certificate or change the Microsoft Graph permissions - Add them as **Owner** (or scoped role) on the **App Registration**. - When you need to let them manage who can use the app via SSO or hide it from My Apps - Add them as **Owner** or scoped role on the **Enterprise Application**. ## SUMMARY TABLE OF Entra Enterprise Apps Vs Registered Apps | **Setting** | **App Registrations (Application object)** | **Enterprise Applications (Service Principal)** | **What this means for your certificate-auth PowerShell session** | |------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------| | **Owners** | People who can fully manage the **definition** of the app (add/remove certs & secrets, change API permissions, redirect URIs, manifest, supported account types, delete the registration) | People who can manage the **tenant-specific usage** of the app (SSO, provisioning, Conditional Access, user assignment, display name, logo, “assignment required”) | Controls who can rotate your certificate, change its permissions, or delete the identity your PowerShell is using | | **Roles and administrators** | Scoped Entra ID roles assigned **only** to this app registration (e.g. manage credentials for just this one app without full owner or global admin rights) | Scoped Entra ID roles assigned **only** to this enterprise app (e.g. custom role to manage “Users and groups” for just this app) | These are the people who can administer the identity your PowerShell is using (more granular than Owners) | | **Users and groups** | Does **not** exist here | End-user access control only (which users/groups can sign in via SSO and where you assign custom app roles) | **No effect** on your certificate authentication — your PowerShell runs as the app itself | ## Related guidance - [Topic overview](Introduction.md) - [Source review status](../../review/Review-status.md)