Resilience Entra ID

Entra ID (formally known as Azure AD) is an Identity and Access Management solution. Through a Cloud-based directory, administrators provision and manage the lifecycle of various identities from Users, Applications to Devices. Unlike Microsoft Active Directory, Entra ID extends its authentication and authorization capabilities beyond the company’s network to cover SaaS applications, on-premises and Cloud workloads using either company-owned devices or BYOD. These new features and connections are achieved thanks to web-based protocols like SAML and simplified identity structure (AD forest vs Entra ID tenant).

In this article, we will expose the cyber-resilience challenge of Entra ID, explain why native features are incomplete and present the result of a PoC conducted on an open-source tool, Microsoft 365 DSC, to backup and recover Entra ID’s data.

 

The challenge of cyber-resilience in managed Cloud services

 

With Entra ID, the directory management strategy is in line with the Cloud paradigm. It means that the various network, storage, computer, OS and application layers are handled by Microsoft, leaving the customer to focus solely on his identity data.

This fundamental difference has an impact on the resiliency of the service. Indeed, the creation of snapshots to back up the integrality of the system, which is a common practice on AD, is not native on a managed service such as Entra ID. Thus, in order to face a disaster recovery scenario linked to malicious activities, we can only rely on native Microsoft functionalities: the identity lifecycle model, RBAC administration model and import/export capabilities.

 

The incomplete soft delete model

 

To ensure resilience, Cloud services are widely using a soft delete mechanism. Its main purpose is to recover data in the event of an accidental deletion. For example, in Azure Recovery Service Vault, the soft delete is the last safeguard in the event of intentional or unintentional deletion of the vault. Combined with immutability parameters, the vault cannot be erased regardless of admin permissions.

In Entra ID, the concept of soft delete exists but is insufficient to ensure data resilience for two reasons. On the one hand, there is neither role distinction between soft-delete and hard-delete nor Recovery role, i.e. the permissions required to delete an object are sufficient to allow for permanent deletion. On the other hand, the life cycle of objects in Entra ID (create, manage, delete) is governed by the same role:

• The role User Administrator can both create and hard-delete a user
• The role Cloud Application Administrator can register an application, configure all aspects of the application and hard-delete the application
• The role Cloud Device Administrator can add a device, configure all aspects of the device and unregister a device

 

The impact of a deletion on Entra ID

 

This design makes the User Administrator, Privileged Authentication Administrator, Cloud Application Administrator, Application Administrator, Cloud Device Administrator, Intune Administrator and Windows 365 Administrator roles all the more critical, as their compromise can lead to the permanent loss of identity data. The impact of such a deletion can be a loss of access to applications and data, a loss of permissions, and an inability to administrate.

Although the deletion of hybrid users synchronized with an on-premise AD is reversible, information such as role assignment will be lost, threatening the rights and access model. This is not the case for Cloud identities, which are generally part of the Control Plane. As part of the Enterprise Access Model, the Control Plane includes the most sensitive access, leading to a global compromise of an Information System.

In a disaster recovery scenario, some assets are more critical than others and should be backed up as a priority. These include:

• Control Plane users, groups and roles assigned
• Enterprise Applications (service principals) with critical permissions over Azure or Microsoft 365
• Administrative workstations

 

Comparison of backup open-source methods

 

To reduce the likelihood of Entra ID malicious data loss risk, the implementation of a backup solution seems essential, at least for the Control Plane in order to maintain control over your Information System and rebuild. We have therefore analyzed 3 open-source methods for ensuring data backup:

• Microsoft Graph PowerShell: this is the PowerShell library for Microsoft Graph APIs. You can build your own script(s) to export and import Entra ID objects attributes that fit with organization needs
• Microsoft Entra Exporter: this is a PowerShell module that export a local copy of some Entra ID attributes (Users, Applications, Service Principals, Roles, etc.) into JSON file
• Microsoft 365 Desired State Configuration (DSC): this is a PowerShell module for declarative configuration, deployment and management of Microsoft 365 services

 

Backing up Entra ID objects with Microsoft 365 DSC

 

In this part, we will explain how we tested the open-source solution Microsoft 365 DSC and share the results and conclusions we got.

Our PoC

Microsoft 365 DSC enables the management of the configuration and state of Microsoft 365 services following a declarative approach. By defining the desired state rather than specific steps, it simplifies the management of complex cloud configurations and ensures consistency across the environment.

In the context of a PoC, the test population deployed in our test tenant is as follows:

• 30 Cloud Only Users (randomly generated by Microsoft as part of the test’s tenant creation process)
• 10 Security Groups (randomly assigned to Users)

The purpose of this PoC is to identify the benefits and limitations of the solution through a series of tested and documented uses cases:

Users
Use cases		Findings
What happens if we delete a user and then restore a backup?	Does the user return with all the data that was attached to them? Does their password come back, or do they have a new password? Do their information return or not?	Not all the attributes related to deleted users are retrieved. However, their password is replaced with a default password. In case of inconsistency, a non-blocking error occurs in the script, preventing the user from being set with attributes that point to non-existent object. If the user has the “Ensure” attribute set to “Absent”, then they will not be retrieved.
What happens if a user is deactivated but, in the backup, they are active?	Do they get reactivated?	We cannot know the state of users (active or deactivated) from the backup. Depending on the situation, we can set the “Ensure” parameter to “Absent” or “Present” to ensure consistency between our tenant state and our export. When set to “Absent”, the user will be considered as deactivated and not be deployed during the restoration process. When set to “Present”, the user will be considered as active and be deployed during the restoration process. If we attempt to recover a user marked as ‘Absent’ and they do not exist on Entra ID, we simply get a confirmation of their non-existence.
What happens if a user is active but, in the backup, they are deactivated?	Do they get deactivated?
What happens if we add a user, and the backup doesn’t contain this new user?	Does the user get deleted? Do their data remain intact?	There is no impact observed on the new user.
What happens if we make a backup without changing the user?	If nothing changed, what happens? If only an attribute of the user (like a group) was deleted, what happens? If an attribute of the user (like a group) was added, what happens? If an attribute was modified (like a password), what happens? If a group they belonged to was deleted, what happens? What happens with the licenses assigned to a user if a backup is made before the modification? What happens if we modify a user’s role before making the backup?	Because the username is used to associate attributes with the user, if it changes, the user cannot be found from the backup (unless it is also changed there). The attributes from the backup overwrite the existing ones. Everything else remains untouched. Therefore, if an attribute is not included in the snapshot, it will stay as it was.

 

Groups
Use cases		Findings
What happens if I delete a group and then restore a backup?	Does the group return with all the data that was attached to it? Are the members of this group reintegrated? Does the snapshot save who belongs to which group? Are all groups saved in the snapshot? Does the snapshot save the rights within the group?	Only the security groups and Microsoft 365 groups with the right confidentiality label are backed-up. The snapshot contains the members of the group and the owner but does not save the rights within the group. It is necessary to redo the snapshot as the newly created group no longer has the same ID as the previous one. It won’t be recognized by the snapshot which will consider that the group does not exist.
What happens if I back up a group that already exists but has modified attributes?	What happens if the name has changed? What happens if a user has left the group after the snapshot? What happens if there are new users after the snapshot?	The backup overwrites the old attributes except for the name.
What happens if a group exists in the tenant but not in the backup?	Does it get deleted or impacted after restoration?	There is no impact observed apart from the information defined in the configuration file.

 

The process required configuring a service account with the right permissions (User.ReadWrite.All, Group.ReadWrite.All) in Entra ID to interact with Microsoft Graph API for data export and import.

These permissions enabled the service account to retrieve the necessary configuration and data from Entra ID and later re-import it.

Result of the PoC Microsoft 365 DSC

As a result of these tests, we were able to gather conclusive information on the solution’s benefits and limitations. On the positive side:

• Granular Configuration Selection: The solution allows precise targeting of configurations for backup, enabling users to select specific settings.
• Recovery without deletion: During recovery, current users and groups are retained, preventing accidental deletion.
• Overwrite of Outdated Attributes: Backed-up attributes replace the old ones.
• Language of the Data Storage: Data is stored in JSON format, making it easy to manipulate and modify backup files.
• Automation Capabilities: Once the necessary tools are installed, the solution is easy to automate.
• Monitoring and Alerts: Microsoft 365 DSC can be used to monitor data consistency and receive alerts in the event of suspicious changes
• Snapshot Versions management: It enables easy maintenance and administration of multiple snapshot versions
• Detailed Logging Functionality: It offers the possibility to generate highly detailed logs, providing records of all operations for enhanced oversight.

Despite these advantages, the study revealed several limitations:

• Incomplete Data in Backup: The backup process does not capture all attributes, leading to potential loss of important information.
• Backup Size Limit: The backup size is capped at 11MB, which may be insufficient for larger configurations or datasets.
• Deactivation Status Not Captured: Snapshots do not store deactivation statuses for users, potentially re-enabling disabled users during recovery.
• Unencrypted Data and Credentials: Security concerns arise from data and credentials being stored unencrypted, posing risks to sensitive information.
• Object IDs’ Loss: During imports, object IDs are lost, causing recreated objects to have new IDs, which can lead to duplicate entries in subsequent imports.
• Privileged Service Principal: The service principal involved has elevated privileges, increasing the risk of security vulnerabilities if not properly managed.

It is important to note that this tool does not really support “restoration” as it is possible to re-create objects, but it does not ensure service restoration and continuity. The reason being that it currently cannot restore links between new ID objects and applications, which is an issue native to Entra ID.

Our opinion about Microsoft 365 DSC

Microsoft 365 DSC is a great tool when it comes to basic uses and documentation as it is simple to use and to deploy on test environments. It is also quite efficient as a monitoring tool thanks to its version control and detailed logs. However, it is not adapted to large environments because of the limited scalability, the poor user experience and security issues related to configurations and credentials. It can also lead to inconsistencies or duplication as object IDs that can be referenced elsewhere are unrecoverable.

Additional solutions may be required such as scripting for handling configuration files and ensuring the consistency of the modifications, as well as well-defined encryption and backup processes. Therefore, we recommend always carefully evaluating the specific needs, planning additional developments and mainly using the solution for supervision and testing purposes.

Given the limitations of Microsoft’s open-source tools, it could be worthwhile to explore what third-party vendors, such as Semperis or Quest who are pure players on the subject, have to offer. These alternatives might address some of the challenges related to scalability, reliability and security, providing options that better suit larger environments. It is important to remain open to these possibilities and evaluate them based on the specific requirements of your organization.