Most organizations recognize that Entra ID recovery is vital to mitigating the risks of business disruptions. Unfortunately, however, many recovery strategies fail to adequately cover Entra ID. Those with a cloud-only IT infrastructure often assume that the native Entra ID and Microsoft 365 tools are sufficient to ensure fast recovery of any accounts, groups or attributes that might be accidentally or deliberately deleted. And those with a hybrid IT infrastructure may think that native tools combined with an on-premises Active Directory (AD) backup and recovery solution are sufficient.
The reality is far more complex. Read on to learn exactly what native tools and on-premises solutions do — and do not — cover, as well as how to get the enterprise-level Entra ID recovery capabilities you need.
How robust is your Entra ID recovery strategy?
Management, employees, partners, contractors and customers all expect you to be able to quickly get the business back up and running, no matter what happens. In a hybrid world, that means ensuring that users have access to the Office 365 applications and data they depend upon to do their jobs every day. Let’s consider a few real-world scenarios that could disrupt that access — could your Entra ID recovery strategy handle them?
1. How quickly could you restore business operations if a key security group got deprovisioned?
Suppose you have several Active Directory OUs with security groups that are being synched to Entra ID to grant certain users access to specific SharePoint Online sites. You also have a rule that whenever a security group exceeds its attestation period, it is moved into a deprovisioning OU to await final decommissioning. Now suppose a security group — one that enables a key team to access critical data, naturally! — misses its attestation deadline and is therefore moved. As soon as Entra ID Connect detects that the group is no longer in scope, it will remove the security group in the cloud. Therefore, the associated users will lose access to the sites they need.
How can you correct the issue? You can move the security group back into the proper OU, and Entra ID Connect will dutifully create a new security group in Entra ID with the same name and membership as before. But it will be assigned a new ID, so the process will not restore the users’ access to the SharePoint Online data! To do that, you’ll need to consult your documentation about which SharePoint Online sites the group needs to have access to (or scramble to figure it out if you don’t have those records) and then manually re-apply the new group to those sites. All the while, any business processes that rely on the critical SharePoint data will be at a standstill.
2. How fast could you restore a user’s account — and their access to cloud resources?
Most organizations have processes for deleting inactive user accounts. These accounts are usually identified by auditing the environment and using lists from the HR team that include employees who have left the company and contractors whose projects have ended.
But sometimes, an account deletion is a mistake: The employee isn’t really gone; they were just on an extended vacation or short-term disability. Or the contractor’s project wasn’t cancelled after all; the paperwork just got held up. Even worse, maybe the deletion script ran amok, or your company got infected with malware, and multiple accounts that are still needed are now gone. All the affected users are immediately unable to do their jobs. They can’t log on to any IT systems to read email, access documents or even see their meeting schedule.
What can you do? If you have a solid on-prem backup and recovery solution, you can restore the accounts, along with all the attributes that were stored in AD. Then you synchronize the user account to the cloud using Entra ID Connect. Everything’s great, right?
Not so fast. As you’ll quickly discover, while the user will once again be able to access on-prem resources, they won’t be able to use any of the Office 365 data or applications they depend upon every day. They can’t work with critical documents stored in SharePoint Online or One Drive, and even if your retention policies preserved their email in Exchange Online, they can’t connect to their mailbox to read it. Why? Because the Office 365 license information associated with their account is stored in a cloud-only attribute — it was never stored in your on-prem AD, so no on-prem solution can possibly restore it.
That’s not all. Their Azure AD role memberships are gone, so if the user was an Application Administrator or a Helpdesk Administrator, for instance, they can’t perform their management tasks. Their conditional access policy rules, settings and password reset configurations — which are an important part of your access control strategy — are also gone. Any custom attributes are gone too, so they can’t get into essential third-party SaaS applications like Salesforce and G Suite.
3. How long can you afford to be without Salesforce and your other SaaS applications?
If your organization is like most, many of your critical business processes rely upon SaaS solutions like Salesforce, ServiceNow and your own custom applications. To control which accounts can access a tool, you integrate it with the Microsoft identity platform, register it in the Azure portal, and configure it to your specifications. But what if an application is deleted, either by mistake or deliberately by a malicious insider or malware? Losing access to Salesforce would be a gigantic problem for many organizations. And your custom cloud applications are probably essential to critical business processes as well.
You can certainly register the application in the Azure portal again. But you’ve lost all the configuration work you’ve done. In particular, you’ve lost the original service principal for the application — the identity it used to access Azure resources — along with the roles you assigned to the service principal restrict the application’s access to resources. You’ve also lost all the user assignments, so you’ll have reconfigure exactly who should have access to the application. None of this critical information is stored in the Recycle Bin when the application is deleted, and there’s no way for you to proactively export it ahead of time in case you need to restore it. So, without a robust Entra ID recovery strategy, restoring the functionality that business users need is going to be a long, tough haul.
4. Can you troubleshoot issues with conditional access policies?
Entra ID conditional access policies are a powerful way to enhance security. For example, you can require an extra form of authentication if a user from outside the corporate network attempts to access a sensitive application, as well as simply block access from certain IP addresses. But suppose you discover that the authentication controls you want for a certain application are no longer in place. Where does the issue lie? Is the application no longer associated with the proper conditional access policy? Has the policy changed? Has the security group that controls who the conditional access policy applies to been changed?
The Recycle Bin offers no benefit here, since it is for deleted objects only; improper modifications to objects are not stored in the Recycle Bin and therefore cannot be recovered from it. Without a comprehensive Entra ID recovery solution, you’ll need complete, current documentation of the configuration of all your Entra ID objects — which is virtually impossible to create and maintain using manual methods.
The underlying challenges for Entra ID recovery
These are just a few examples of scenarios in which your organization could suffer prolonged business disruption for lack of a robust Entra ID recovery strategy. To understand the core issues, let’s dive down into the characteristics of Entra ID that are relevant for recovery.
While the core processes of authenticating a user and authorizing them to access the correct resources in Entra ID are quite similar to those in on-premises AD, there are important differences. In particular, Entra ID does not have equivalents to Group Policy, discretionary access control lists (DACLs) or hierarchical objects like organizational units. Moreover, Entra ID has objects and properties that simply do not exist in on-premises AD, including the following:
- Roles — Roles enable users to perform specific tasks such as adding or changing users, resetting user passwords, managing user licenses, and managing domain names. Examples of roles include Application Developer, Cloud Application Administrator and Directory Reader.
- Licenses — A user cannot use a licensed service until their account has been assigned a license. If that license attribute is lost, the user cannot access those services until it is restored.
- Multifactor authentication (MFA) settings — MFA settings control whether a user must provide an additional form of verification, such as a code from their cell phone or a fingerprint scan, during sign-in. MFA is deployed using conditional access policies.
- Conditional access policies — These policies provide additional control over access by requiring MFA under certain conditions or enforcing other restrictions. For example, a policy might block or grant access from specific locations or require the use of organization-managed devices for certain applications.
- Dynamic group definitions — These complex, attribute-based rules automatically adjust a user’s group membership. For example, if a user transfers from the Sales department to Marketing (and their Entra ID user object is updated accordingly), a dynamic group definition could automatically remove them from the groups associated with Sales and add them to the groups associated with Marketing.
- Applications and service principals — Applications and service principals define how non-Microsoft 365 applications interact with Entra ID. They are used for external applications that need access to Entra ID data, and they are also used to provide single sign-on (SSO) for federated applications. Service principals rely on applications to act as a defining template for their configuration. Every service principal has an application somewhere, either in the same tenant as the service principal or in another tenant.
Why the Recycle Bin is insufficient for Entra ID recovery
The Recycle Bin is a convenient tool for recovering certain types of recently deleted objects, but there are many reasons why it’s not sufficient for Entra ID recovery, including the following:
- Not all objects get put into the Recycle Bin when they are deleted. Certain types of objects are soft deleted, which means they do get put into the Recycle Bin, such as user accounts and Microsoft 365 groups. But other objects are hard deleted — they are not put into the Recycle Bin and therefore cannot be recovered from it. These include security groups, distribution groups, service principals, conditional access policies and devices.
- Deleted objects remain in the Recycle Bin for only 30 days. That’s far less than the 180-day default for the on-premises AD Recycle Bin. After 30 days, the objects are permanently deleted.
- Critical information isn’t stored in the Recycle Bin. Many Entra ID objects have complex configurations or specific interactions with other systems. Those details are not captured by the Recycle Bin and cannot be restored from it.
- You can’t restore specific attributes. If an object has been changed rather than deleted, the Recycle Bin cannot help you restore the object to its previous state.
- You can’t restore in bulk without PowerShell. There is no simple way to restore multiple objects at one time without using PowerShell.
- Finding what you need to recover can be challenging. You need to know which users or groups were deleted in order to restore them, but there is no Entra ID change log or comparison report to help you determine which objects have been changed or deleted.
Why on-premises tools are insufficient for Entra ID recovery
Many organizations use a hybrid model in which they synchronize their on-premises Active Directory to the cloud using Entra ID Connect. They often believe that the recovery strategy they have in place for their on-premises Active Directory will also cover Entra ID due to the synchronization, thereby making up for the limitations of the Recycle Bin.
However, this optimism is unfounded. Entra ID Connect is a one-way sync, so cloud-only objects and attributes can’t be backed up or restored by your on-prem solution.
Cloud-only objects
Cloud-only objects are often quite critical to business operations. They include:
- Entra users
- Microsoft 365 groups
- Entra ID security groups
- Dynamic security groups
- Dynamic Microsoft 365 groups
- Service principals (enterprise applications)
- Devices
- Application registrations
- Conditional access policies
- Named locations
- Tenant-level settings
- Administrative units
These objects are never present in on-premises Active Directory, so an Entra ID recovery tool is needed to restore them. As you can see from the list, quick recovery is essential, not just for business continuity but for security and compliance as well.
Cloud-only attributes
The cloud-only attributes of hybrid objects include the following:
- Office 365 mailbox link
- assignedLicenses
- memberOf
- Roles
- appRoleAssignments
- usageLocation
- conditionalAccessPolicyMemberOf
- Custom attributes
So, when an object is deleted from the on-premises Active Directory (or excluded from Entra ID Connect synchronization), exactly what happens to the associated hybrid cloud object? It depends on the type of object:
- Hybrid user objects will be soft deleted from Entra ID. If the on-premises user object is recovered or brought back into synchronization scope, the hybrid user will be restored from the soft- deleted state. If the user object has aged out of soft-delete status and been permanently deleted, Entra ID Connect will create a new hybrid cloud user object based on the on-premises user object.
- Security groups will immediately be hard deleted from Entra ID. If the on-premises group is recovered or brought back into synchronization scope, Entra ID Connect will create a new hybrid cloud security group based on the on-premises group.
In either case, when Entra ID Connect creates the new user object or security group, that object will lack the cloud-only attributes of the deleted object, such as roles, conditional access policies and licenses. This can have serious consequences, such as costly disruptions to users and business operations.
Reduce your AD attack surface.
What’s needed for true enterprise-level Entra ID recovery
As we have seen, using native tools for Entra ID recovery works well if the scenario fits two fairly rigid guidelines:
- You want to recover an Entra ID user, Microsoft 365 group or Entra ID application that was deleted (not modified).
- No more than 30 days have passed since the object was deleted.
For all other Entra ID recovery scenarios, you need a comprehensive backup and recovery solution that handles both deletion and modification scenarios:
- Object deletion — It must record the configuration of all types of Entra ID objects and recreate them when you request their recovery.
- Object modification — The solution also needs to back up and restore the individual properties of objects so you can easily and precisely revert errant changes as well as outright deletions.
To minimize business disruptions, the Entra ID recovery solution also needs to overcome the other shortcomings discussed earlier. In particular, it needs to:
- Handle hybrid environments. Active Directory and Entra ID are intertwined, so it’s essential to have a solution that can provide insight across the IT ecosystem and orchestrate the entire recovery.
- Make it easy to find the objects or attributes you need. The solution should make it easy to review all changes that can be recovered and select exactly what you need to restore.
- Restore objects completely. For true Entra ID recovery, you can’t be left with recovered objects that lack cloud-only attributes or whose new object ID is not recognized by any of the services that need to use it to secure information or provide access to application. Instead, the Entra ID recovery solution needs to restore not just objects but access. For example, if a group is recreated with a new object ID, the tool should configure the SharePoint site to use the group’s new object ID, re-enabling secure access to the data.
Summary
Entra ID provides authentication and authorization for the critical Microsoft 365 and other resources your organization depends upon every day, so it needs to be fully accounted for in your backup and recovery strategy. Native tools were never intended to be a comprehensive AD or Entra ID recovery solution, and even the best on-prem solution cannot protect the cloud-only objects and attributes it never sees. Be sure you have true enterprise-level recovery capabilities across your entire IT environment.
