Microsoft Entra ID is an Identity as a Service (IDaaS) solution, a cloud-based identity and access management service that Microsoft users can use to access external resources. Example resources include Microsoft 365, the Azure portal, and thousands of other SaaS applications. Microsoft Entra ID also helps users access internal resources like apps on in their organizational intranet, and any cloud apps developed for their organization.
To learn the differences between Active Directory and Microsoft Entra ID, see Compare Active Directory to Microsoft Entra ID. You can also refer to Microsoft Cloud for Enterprise Architects Series posters to better understand the core identity services in Azure like Microsoft Entra ID and Microsoft 365.
The following tables describe the Entra ID objects protected by Barracuda Cloud-to-Cloud Backup.
Entra ID Backup
Users
User objects are digital profiles that represent people in an organization. These profiles store important information about each user, such as their name, email address, job title, and permissions.
For example, a user object might include:
The user’s login credentials (username and password).
Their role (e.g., regular employee or admin).
Groups they belong to (e.g., "Sales Team").
Access permissions for apps and data.
User objects are like ID cards in the digital world, helping the system know who someone is and what they are allowed to do.
Backup:
The object and all attributed detailed below are backed up.
Restore:
The object is updated/created.
Limitation:
Photos backed up need to be exported and restored manually.
Attribute | Description | Backed Up | Restored | Exported |
---|---|---|---|---|
accountEnabled | If an account is enabled or not | Yes | Yes | Yes |
ageGroup | Age group defined as: Minors: 12 and under | Yes | Yes | Yes |
businessPhones | Telephone numbers | Yes | Yes | Yes |
city | Location | Yes | Yes | Yes |
companyName | Company name | Yes | Yes | Yes |
consentProvidedForMinor | Has consent been obtained for minors: granted, denied, notRequired | Yes | Yes | Yes |
country | Country/region | Yes | Yes | Yes |
createdDateTime | Date the user object was created | Yes | No | Yes |
creationType | If the user account was created as a local account for an Azure Active Directory B2C tenant: LocalAccount or nameCoexistence | Yes | No | Yes |
deletedDateTime | Date the user object was deleted | Yes | No | Yes |
department | Company department | Yes | Yes | Yes |
employeeHireDate | Date and time of hire or future hire | Yes | Yes | Yes |
employeeId | Employee identifier | Yes | Yes | Yes |
employeeOrgData | Organization data (e.g. division and costCenter) | Yes | Yes | Yes |
employeeType | Employee type (e.g. Contractor, Consultant, Employee) | Yes | Yes | Yes |
externalUserState | External user invited to the tenant invitation status | Yes | No | Yes |
externalUserStateChangeDateTime | Timestamp for the latest change to the invitation status (externalUserState) property. | Yes | No | Yes |
faxNumber | Fax Number | Yes | Yes | Yes |
givenName | First Name | Yes | Yes | Yes |
identities | Identities used to sign in to this user account. An identity can be provided by Microsoft (also known as a local account), by organizations, or by social identity providers such as Facebook, Google, and Microsoft, and tied to a user account. | Yes | Yes | Yes |
jobTitle | Job title | Yes | Yes | Yes |
lastPasswordChangeDateTime | Date password was last changed | Yes | No | Yes |
SMTP address | Yes | Yes | Yes | |
mailNickname | Mail alias | Yes | Yes | Yes |
mobilephone | Primary mobile telephone number | Yes | Yes | Yes |
officeLocation | Office location | Yes | Yes | Yes |
onPremisesImmutableId | Associate an on-premises Active Directory user account to their Azure AD user object | Yes | Yes | Yes |
onPremisesProvisioningErrors | Errors when using Microsoft synchronization product during provisioning | Yes | No | Yes |
otherMails | Additional email addresses | Yes | Yes | Yes |
passwordPolicies | Password policies for the user | Yes | Yes | Yes |
picture | Photo | Yes | Yes | Yes |
postalCode | Address postal code | Yes | Yes | Yes |
preferredDataLocation | Preferred data location | Yes | Yes | Yes |
preferredLanguage | Preferred language | Yes | Yes | Yes |
state | State or province | Yes | Yes | Yes |
streetAddress | Company street address | Yes | Yes | Yes |
surname | Surname (family name or last name). | Yes | Yes | Yes |
usageLocation | Two-letter country code (ISO standard 3166). Required for users that will be assigned licenses due to legal requirements to check for availability of services in countries. | Yes | Yes | Yes |
userPrincipalName | User principal name (UPN). The UPN is an Internet-style login name for the user based on the Internet standard RFC 822. | Yes | Yes | Yes |
userType | User types in your directory, such as "Member" and "Guest." | Yes | Yes | Yes |
Groups
Group objects are digital collections of users, devices, or other groups that help manage access to apps, data, and resources more efficiently.
For example:
Instead of giving access to an app to 50 employees one by one, you can add all 50 to a group and assign the app to the group.
Groups can also be used to apply specific policies, like blocking access from certain locations.
There are two main types of groups in Entra ID:
Security groups: Used to control access to resources (e.g., files, apps).
Microsoft 365 groups: Used for collaboration (e.g., in Teams, SharePoint).
There are two additional groups where Entra ID plays a role in their creation and synchronization. Mail-Enabled Groups and Distribution Groups are primarily managed in Exchange Online or the Microsoft 365 Admin Center, rather than directly in Entra ID.
Group objects are like "folders" for people and devices, making it easier to organize and manage access.
Backup:
The object and all attributes detailed below are backed up.
Group members are backed up.
Restore:
The object is updated/created.
Existing members are added/removed.
Limitation:
Microsoft allows the back up of all 4 group types, however, only Microsoft 365 groups and Security groups can be restored. See the table below for details.
Group Types
Type | groupTypes | mailEnabled | securityEnabled | Created and managed via the groups APIs |
---|---|---|---|---|
["Unified"] | TRUE | TRUE or FALSE | Yes | |
[] | FALSE | TRUE | Yes | |
[] | TRUE | TRUE | No; read-only through Microsoft Graph | |
Distribution groups | [] | TRUE | FALSE | No; read-only through Microsoft Graph |
Group Attributes
Attribute | Description | Backed Up | Restored | Exported |
---|---|---|---|---|
classification | Classification for the group (such as low, medium, or high business impact). | Yes | No | Yes |
deletedDateTime | Date the group object was deleted | Yes | No | Yes |
description | Optional description | Yes | Yes | Yes |
groupTypes | Group type and its membership | Yes | No | Yes |
deducedGroupType | Type of group based on several properties (mailEnabled, securityEnabled, groupTypes) | Yes | Yes | Yes |
mailEnabled | If the group is mail-enabled | Yes | Yes; note that this is the attribute indicating the mail-enabled state only, not the group itself - see Group Types table above. | Yes |
mailNickname | Mail alias for the group, unique in the organization | Yes | Yes | Yes |
SMTP address | Yes | No | Yes | |
membershipRule | Rule that determines members for this group, if the group is a dynamic group | Yes | Yes | Yes |
membershipRule | If the dynamic membership processing is on or paused | Yes | Yes | Yes |
preferredDataLocation | Preferred data location | Yes | Yes | Yes |
preferredLanguage | Preferred language | Yes | No | Yes |
resourceBehaviorOptions | Group behaviors that can be set for a Microsoft 365 group during creation | Yes | No | Yes |
resourceProvisioningOptions | Group resources that are provisioned as part of Microsoft 365 group creation, that are not normally part of default group creation. | Yes | No | Yes |
securityEnabled | If the group is a security group | Yes | Yes | Yes |
securityIdentifier | Security identifier of the group, used in Windows scenarios | Yes | Yes | Yes |
theme | Theme for Microsoft 365 group | Yes | Yes | Yes |
visibility | Group join policy and group content visibility | Yes | Yes | Yes |
isAssignableToRole | If this group can be assigned to an Azure Active Directory role | Yes | Yes | Yes |
Administrative Units
User objects are digital profiles that represent people in an organization. These profiles store important information about each user, such as their name, email address, job title, and permissions.
For example, a user object might include:
The user’s login credentials (username and password).
Their role (e.g., regular employee or admin).
Groups they belong to (e.g., "Sales Team").
Access permissions for apps and data.
User objects are like ID cards in the digital world, helping the system know who someone is and what they are allowed to do.
Backup:
The object and all attributed detailed below are backed up.
Members are backed up.
Restore:
The object is updated/created.
Existing members are added/removed.
Attribute | Description | Backed Up | Restored | Exported |
---|---|---|---|---|
displayName | Display name | Yes | Yes | Yes |
description | Optional description | Yes | Yes | Yes |
visibility | If the administrative unit and its members are hidden or public | Yes | Yes | Yes |
Roles
Roles are like job titles that define what someone is allowed to do in your organization’s systems.
For example:
If you want someone to manage user accounts but not have access to billing information, you can assign them a User Administrator role. If someone needs full control over all settings, you can assign them the Global Administrator role.
Roles come with specific permissions that determine what tasks a person can perform, helping you control access and responsibilities.
Roles are how you assign the right level of access to people, so they can do their job without having unnecessary permissions.
Backup:
The object and all attributes as detailed below are backed up.
The users are backed up.
Restore:
The object is updated/created.
Existing users are added/removed.
Attribute | Description | Backed Up | Restored | Exported |
---|---|---|---|---|
description | Description | Yes | Yes (if not built-in) | Yes |
isBuiltIn | If the role is part of the default set included with the product or custom | Yes | No | Yes |
isEnabled | If the role is enabled for assignment | Yes | Yes (if not built-in) | Yes |
rolePermissions | List of permissions included in the role | Yes | Yes (if not built-in) | Yes |
templateId | Custom template identifier that can be set when isBuiltIn is false | Yes | Yes (if not built-in) | Yes |
version | Version of the role | Yes | Yes (if not built-in) | Yes |
visibility | If the role is hidden or public. | No | No | No |
Entra ID Backup Premium Objects
The Entra ID Backup Premium tier supports the backup and restore of the following attributes for each object type, where possible.
App Registrations
App registrations are like creating a digital ID for an app so it can securely connect to your organization's systems or other services. This process allows apps to access resources, like user data or APIs, in a controlled and secure way.
For example:
If your company has a custom app that needs to access Microsoft 365 data (like calendars or emails), you’d register the app in Entra ID.
During registration, the app gets credentials (like a username and password for apps) and permissions (what the app is allowed to do).
App registrations are how you let apps "log in" and securely interact with your organization’s data, just like users have to.
Backup:
The object and all attributes as detailed below are backed up.
The owners (users) are backed up.
Restore:
The object is updated/restored (see details under Enterprise Applications).
Existing owners are added/removed.
Limitations:
For hard deleted app registrations, the following attributes cannot be restored, so they must be added by the user after restore:
Redirect URI Settings
Identifier URIs
See notes under Enterprise Applications.
Secrets and Certificates need to be created manually after restoration.
Photos for internal applications are backed up, however, they currently cannot be exported or restored.
Attribute | Description | Backed up | Restored | Exported |
---|---|---|---|---|
addIns | Defines custom behavior that a consuming service can use to call an app in specific contexts. | Yes | Yes | Yes |
displayName | Display name of the application. | Yes | Yes | Yes |
api | Specifies settings for an application that implements a web API. | Yes | Yes | Yes |
applicationTemplateId | Unique identifier of the applicationTemplate. | Yes | No | Yes |
appRoles | Collection of roles defined for the application. | Yes | Yes | Yes |
certification | Specifies the certification status of the application. | Yes | No | Yes |
createdDateTime | Date and time the application was registered. | Yes | No | Yes |
deletedDateTime | Date and time the application was deleted. | Yes | No | Yes |
description | Free text field to provide a description of the application object to end users. | Yes | Yes | Yes |
disabledByMicrosoftStatus | Specifies whether Microsoft has disabled the registered application. | Yes | No | Yes |
groupMembershipClaims | Configures the | Yes | Yes | Yes |
identifierUris | Also known as App ID URI, this value is set when an application is used as a resource app. | Yes | No | Yes |
info | Basic profile information of the application such as app's marketing, support, terms of service and privacy statement URLs. | Yes | Yes | Yes |
isDeviceOnlyAuthSupported | Specifies whether this application supports device authentication without a user. | Yes | Yes | Yes |
isFallbackPublicClient | Specifies the fallback application type as public client, such as an installed application running on a mobile device. | Yes | Yes | Yes |
keyCredentials | Collection of key credentials associated with the application. | Yes | No | Yes |
notes | Notes relevant for the management of the application. | Yes | Yes | Yes |
oauth2RequiredPostResponse | Specifies whether, as part of OAuth 2.0 token requests, Entra ID allows POST requests, as opposed to GET requests. | Yes | Yes | Yes |
optionalClaims | Application developers can configure optional claims in their Entra ID applications to specify the claims that are sent to their application by the Microsoft security token service. | Yes | Yes | Yes |
parentalControlSettings | Specifies parental control settings for an application. | Yes | Yes | Yes |
passwordCredentials | Collection of password credentials associated with the application. Not nullable. | Yes | No | Yes |
picture | Photo assigned to the App Registration, if any. | Yes, if internal. No, if 3rd party. | No. To use photos for internal enterprise applications that were backed up, they will need to be exported and added manually. | Yes, if backed up. |
publicClient | Specifies settings for installed clients such as desktop or mobile devices. | Yes | Yes | Yes |
publisherDomain | Verified publisher domain for the application. | Yes | Yes | Yes |
requiredResourceAccess | Specifies the resources that the application needs to access. | Yes | Yes | Yes |
samlMetadataUrl | URL where the service provides SAML metadata for federation. | Yes | Yes | Yes |
serviceManagementReference | References application or service contact information from a Service or Asset Management database. | Yes | Yes | Yes |
signInAudience | Specifies the Microsoft accounts that are supported for the application. | Yes | Yes | Yes |
spa | Specifies settings for a single-page application, including sign out URLs and redirect URIs for authorization codes and access tokens. | Yes | Yes | Yes |
tags | Custom strings that can be used to categorize and identify the application. | Yes | Yes | Yes |
tokenEncryptionKeyId | Specifies the keyId of a public key from the keyCredentials collection. | Yes | Yes | Yes |
verifiedPublisher | Specifies the verified publisher of the application. | Yes | No | Yes |
web | Specifies settings for a web application. | Yes | Sub attribute “ | Yes |
Audit Logs
Audit logs in Entra ID are like activity trackers that record what’s happening with sign-ins and directory changes in your organization.
For example:
If you want to see who signed in to your system, from where, and whether the attempt was successful, you’d check the sign-in logs.
If you need to know who added a new user or changed permissions, you’d check the directory audit logs.
These logs provide detailed records to help monitor security, troubleshoot issues, and meet compliance requirements.
Sign-in and directory audit logs are how you keep track of what’s happening in your organization’s systems for security and transparency.
Note:
Entra ID has two types of logs, Sign-In and Directory Audit.
Backup:
The object and the attributes as detailed below are backed up.
Restore:
User and Audit logs are captured for historical audit purposes only and cannot be restored to the tenant; they can only be exported.
Limitation:
To back up logs, the customer must have a P1 or P2 license applied to the tenant. For more information on Entra ID and the license types, see https://learn.microsoft.com/en-us/entra/fundamentals/whatis.
Log | Description | Backed up | Restored | Exported |
---|---|---|---|---|
Audit | Audit logs | Yes | No | Yes |
Sign-in | Sign-in logs | Yes | No | Yes |
Authentication Method Policies
Authentication method policies are like rules that control how users verify their identity when signing in to your organization's systems.
For example:
If your company requires employees to use multi-factor authentication (MFA), like entering a password and approving a notification on their phone, you can set up an authentication method policy.
These policies define which methods are allowed (e.g., passwords, biometrics, or security keys) and ensure users follow your organization’s security requirements.
Authentication method policies are how you decide the "how" behind signing in, making sure it’s secure and meets your organization’s needs.
Backup:
The object and all attributes as detailed below are backed up.
Restore:
The object is updated/created.
Limitation:
There is currently no support for non built-in policies.
Policy | Description | Backed up | Restored | Exported |
---|---|---|---|---|
Authentication method | Manage authentication methods, including modern methods like passwordless authentication. | Yes | Yes | Yes |
Authentication Strength Policies
Authentication strength policies are like setting the "security level" required for users to sign in, based on the sensitivity of what they’re accessing.
For example:
If your company has sensitive financial data, you might require employees to use stronger authentication methods, like multi-factor authentication with a password and a physical security key, instead of just a password.
These policies let you define the level of authentication needed for different scenarios, ensuring that higher security is used where it matters most.
Authentication strength policies are how you match the security of sign-ins to the importance of the data or apps being accessed.
Backup:
The object and all attributes as detailed below are backed up.
Restore:
The object is updated/created.
Policy | Description | Backed Up | Restored | Exported |
---|---|---|---|---|
Authentication strength | Authentication strength policies | Yes | Yes | Yes |
BitLocker Keys
BitLocker keys are recovery codes that help a user unlock and access encrypted devices if something goes wrong.
For example:
If your company uses BitLocker to encrypt work laptops for security, and an employee forgets their password or the device has an issue, the BitLocker key acts as a backup to unlock it.
When devices are joined to Entra ID, their BitLocker keys are stored securely, so admins can retrieve them if needed.
BitLocker keys are the "spare keys" to unlock encrypted devices, kept safe in Entra ID for emergencies.
Notes:
To effectively back up BitLocker keys, it is also necessary to back up Devices. However, Microsoft does not offer a way to restore Devices; they are captured solely for display purposes.
The number of nodes displayed under a Device within the user interface is the number of encrypted volumes. For example, one device with a C and D drive will display two nodes, each with their own recovery key.
The display name of BitLocker nodes for each Device consists of a combination of the GUID and a unique value generated during enumeration.
Backing up BitLocker keys may result in a noticeable increase in audit log events.
Backup:
The object and all attributes as detailed below are backed up.
Restore:
For security purposes, BitLocker keys cannot be restored to the tenant; they can only be exported.
Attribute | Description | Backed up | Restored | Exported |
---|---|---|---|---|
Bitlocker recovery keys | Bitlocker recovery keys | Yes | No | Yes |
Conditional Access Policies
Conditional access policies are like digital security rules that help protect an organization. They ensure that only the right people, using the right devices, in the right situations, can access company apps and data.
For example:
A company might allow employees to access work apps only if they’re logging in from a company-approved device or a secure network.
If someone logs in from an unusual location (like a different country), they might need to verify their identity with a second step, like a text message code.
These policies act as smart guards that balance security and convenience based on the situation.
Backup:
The object and all attributes as detailed below are backed up.
Restore:
The object is updated/created.
Limitations:
To back up logs, you must have a P1 or P2 license applied to the tenant. For more information on Entra ID and the license types, see https://learn.microsoft.com/en-us/entra/fundamentals/whatis.
Authentication Strength grant access controls cannot be restored.
If there are no session controls and no grant controls set except Auth Strength, the policy will be restored but set to Blocked Access and Reporting Only. User action is required to activate the policy.
Named Location Policies can be restored, but without their relationship to conditional access policies, if any exist.
Certain preview features that can be enabled in the tenant are not currently supported by the Microsoft API and will result in a backup failure.
Known examples:
Strictly enforce location policies (preview)
Require token protection for sign-in sessions (preview)
Policy | Description | Backed up | Restored | Exported |
---|---|---|---|---|
Conditional access | Manage access to resources based on specific conditions. | Yes | Yes (see Limitations above) | Yes |
Device Management
Device Management (also known as Intune) contains policies that control how devices are used within your organization to keep data secure. These policies enforce rules, like requiring device encryption, restricting app usage, or controlling how company data is shared.
Intune policies are how you manage and protect devices in your organization, ensuring data is secure and used appropriately.
Device Management contains two policy types related to device controls, Device Compliance Policies and Device Configuration Policies, which are defined below.
Device Compliance Policies
Device compliance policies are like a set of rules that help ensure devices and users meet your organization's security and compliance requirements before accessing sensitive data or apps.
For example:
If your company requires employees to use devices with up-to-date antivirus software and encryption, you can create a compliance policy in Entra ID.
This policy checks devices to ensure they meet these standards. If a device doesn’t comply (e.g., it’s missing antivirus software), access to company apps or data can be blocked until the issue is resolved.
Device compliance policies are how you make sure only secure, trusted devices and users can interact with your organization’s resources.
Backup:
The object and all attributes as detailed below are backed up.
Restore:
The object is updated/created.
Limitation:
Not all device compliance policies are accessible via the Microsoft API. The following list contains all supported configurations; any other combination available in the configuration creator cannot be backed up:
"Android device administrator - Custom"
"Android device administrator - Device restrictions"
"Android Enterprise - Personally-Owned Work Profile - Custom"
"Android Enterprise - Personally-Owned Work Profile - Device restrictions"
"iOS/iPadOS - Custom"
"iOS/iPadOS - Device features"
"iOS/iPadOS - Device restrictions"
"iOS/iPadOS - Software Updates (aka Edition upgrade and mode switch)"
"macOS - Custom"
"macOS - Device features"
"macOS - Device restrictions"
"Windows 10 and later - Custom"
"Windows 10 and later - Device restrictions"
"Windows 10 and later - Device restrictions (Windows 10 Team)"
"Windows 10 and later - Edition upgrade and mode switch"
"Windows 10 and later - Endpoint protection"
"Windows 10 and later - Microsoft Defender for Endpoint (desktop devices running Windows 10 or later)"
"Windows 10 and later - Secure assessment (Education)"
"Windows 10 and later - Shared multi-user device"
"Windows 8.1 and later - Device restrictions"
Policy | Description | Backed up | Restored | Exported |
---|---|---|---|---|
Device compliance | Device compliance policies | Yes | Yes | Yes |
Device Configuration Policies
Device configuration policies are like preset instructions for setting up devices or apps consistently across your organization.
For example:
If your company wants all work laptops to have specific Wi-Fi settings, a trusted certificate installed, and a default homepage in the browser, you can create a configuration profile policy in Entra ID.
These policies automatically apply the settings to devices when they connect to your organization, so employees don’t have to set things up themselves.
Device configuration policies are how you preconfigure devices or apps to ensure they are ready for work and meet your organization’s standards right out of the box.
Backup:
The object and all attributes as detailed below are backed up.
Restore:
The object is updated/created.
Limitation:
Certain policies, such as Android Enterprise and AOSP, cannot be restored once deleted. If you attempt to restore a deleted policy that is not supported, an exception will occur, causing the restore to fail with a corresponding message captured in the job log.
Policy | Description | Backed up | Restored | Exported |
---|---|---|---|---|
Device configuration | Sets of instructions that control how devices behave, enabling administrators to manage settings and enforce company policies. | Yes | Yes | Yes |
Enterprise Applications
Enterprise applications (also known as Service Principals), are a subset of App Registrations, and are like a digital identity for an app within your organization. They allow apps or automated tools to "log in" and access specific resources securely, based on permissions you set.
For example:
If you have an app that automates file sharing in Microsoft 365, it needs a way to access your files without using a person’s login. A enterprise application acts as the app’s identity.
The enterprise application is created automatically when you register an app or manually if needed. It has its own credentials (like a username and password for apps) and can be assigned permissions, controlling what it can do.
Enterprise applications are how apps securely "act on their own" in your systems, following rules you define.
Backup:
The object and all attributes as detailed below are backed up.
Assignments to users and groups are backed up.
The owners (users) are backed up.
Restore:
The object is updated/restored (see notes below).
Assignments to existing users and groups are added/removed.
Existing owners are added/removed.
Additional notes on restoring:
If the parent app registration exists within the same tenant as the enterprise application (e.g., internal to the customer), then:
If the app registration is soft or hard deleted, an exception will occur, causing the enterprise application restore to fail. In this situation, you should first restore the app registration.
If the enterprise application is soft deleted (retained for 30 days), it will be restored with the same ID.
If the enterprise application is hard deleted, a new enterprise application will be created with a new ID.
If the parent app registration is in another tenant (eg, a 3rd party app), then:
If the app registration is soft or hard deleted, an exception will occur, causing the enterprise application restore to fail.
If the enterprise application is soft or hard deleted, an exception will occur, causing the enterprise application restore to fail.
Only enterprise applications of type ‘Application’ are restored. For other types of enterprise applications, restore of child nodes will be attempted.
Owners and App Role assignments for child nodes are restored if the corresponding users or groups exist. Any assignments that are not present in the snapshot will be deleted.
During restore, if the enterprise application exists, it will be updated to match the backup. Supported attributes are listed in this article.
Limitations:
Microsoft does not provide the capability to back up or restore:
Roles and Admins
SSO settings
Permissions and consent.
Backing up photos is currently not supported.
Attribute | Description | Backed Up | Restored | Exported |
---|---|---|---|---|
accountEnabled | TRUE if the enterprise application account is enabled; otherwise, FALSE. If set to FALSE, then users will not be able to sign into this app, even if they are assigned to it. | Yes | Yes | Yes |
addIns | Defines custom behavior that a consuming service can use to call an app in specific contexts. | Yes | No | Yes |
displayName | The display name for the enterprise application. | Yes | Yes | Yes |
alternativeNames | Retrieve enterprise applications by subscription, identify resource group and full resource IDs for managed identities. | Yes | Yes | Yes |
appDescription | Description from the application. | Yes | Yes | Yes |
appDisplayName | Display name from the application. | Yes | No | Yes |
appId | Unique identifier for the associated application (its appId property). | Yes | No | Yes |
applicationTemplateId | Unique identifier of the applicationTemplate that the servicePrincipal was created from. | Yes | No | Yes |
appOwnerOrganizationId | Tenant ID where the application is registered. | Yes | No | Yes |
appRoleAssignmentRequired | Specifies whether users or other Enterprise Applications must receive an app role assignment for this enterprise application prior to allowing users to sign in or applications to obtain tokens. | Yes | Yes | Yes |
appRoles | Roles from the application that this Enterprise Application represents. | Yes | No | Yes |
deletedDateTime | Date and time the enterprise application was deleted. | Yes | No | Yes |
description | Free text field to provide an internal end-user facing description of the enterprise application. | Yes | Yes | Yes |
disabledByMicrosoftStatus | Specifies whether Microsoft has disabled the registered application. | Yes | No | Yes |
homepage | Home page or landing page of the application. | Yes | No | Yes |
info | Basic profile information of the acquired application such as an app's marketing, support, terms of service, and privacy statement URLs. | Yes | No | Yes |
keyCredentials | Collection of key credentials associated with the enterprise application. | Yes | No | Yes |
loginUrl | Specifies the URL where the service provider redirects the user to Entra ID to authenticate. | Yes | No | Yes |
logoutUrl | Specifies the URL that will be used by Microsoft's authorization service to logout an user using OpenId Connect front-channel, back-channel or SAML logout protocols. | Yes | No | Yes |
notes | Free text field to capture information about the enterprise application, typically used for operational purposes. | Yes | Yes | Yes |
notificationEmailAddresses | Specifies the list of email addresses where Entra ID sends a notification when the active certificate is near the expiration date. | Yes | No | Yes |
oauth2PermissionScopes | Delegated permissions from the application. | Yes | No | Yes |
passwordCredentials | Collection of password credentials associated with the application. | Yes | No | Yes |
picture | The photo assigned to the enterprise application, if any. | Yes, if internal No, if 3rd party | No. To use photos for internal enterprise applications that were backed up, they must be exported and added manually. | No |
preferredSingleSignOnMode | Specifies the single sign-on mode configured for this application. Entra ID uses the preferred single sign-on mode to launch the application from Microsoft 365 or the Entra ID My Apps. | Yes | No | Yes |
replyUrls | URLs that user tokens are sent to for sign in with the application, or the redirect URIs that OAuth 2.0 authorization codes and access tokens are sent to for the application. | Yes | No | Yes |
resourceSpecificApplicationPermissions | Resource-specific application permissions for the application. | Yes | No | Yes |
samlSingleSignOnSettings | Collection of settings related to SAML single sign-on. | Yes | No | Yes |
servicePrincipalNames | List of identifiersUris, copied over from the application. | Yes | No | Yes |
servicePrincipalType | Specifies whether the enterprise application represents an application, a managed identity, or a legacy application. | Yes | No | Yes |
signInAudience | Specifies the Microsoft accounts that are supported for the current application. | Yes | No | Yes |
tokenEncryptionKeyId | keyId of a public key from the keyCredentials collection. | Yes | No | Yes |
tags | Custom strings that can be used to categorize and identify the enterprise application. | Yes | Yes | Yes |
verifiedPublisher | Verified publisher of the application that this enterprise application represents. | Yes | No | Yes |
Named Locations
Named locations are a way to define specific geographic locations or IP ranges that your organization trusts or wants to monitor. They help enforce security rules by identifying where a user is signing in from.
For example:
A trusted named location could be your company’s office network.
A blocked named location might include risky regions or countries you want to restrict access from.
Named locations are used in Conditional Access policies to control access. For instance:
Only allow users to sign in without extra verification when they're in a trusted office.
Require extra security steps (like MFA) if someone logs in from outside the trusted locations.
Named locations are like setting boundaries to decide what locations are safe to login from, and what locations need extra protection.
Backup:
The object and all attributes as detailed below are backed up.
Restore:
The named location policy is updated/created.
Policy | Description | Backed up | Restored | Exported |
---|---|---|---|---|
Country named location | Used to enforce access controls based on a user's location. | Yes | Yes | Yes |
IP named location | Define specific IP ranges or countries as trusted or blocked locations for user access to resources. | Yes | Yes | Yes |