Plugging the Gaps Azure AD Connect Leaves in Your Cloud Disaster Recovery Strategy

So instead of using Azure AD Connect, you have to restore the user object from the Azure AD Recycle Bin. Sounds easy enough, right? Well, keep in mind the following limitations: • It’s hard to figure out what you need to restore. There is no native change log or comparison report to help you determine which Azure AD objects have been changed or deleted, so how could you figure out exactly what you need to restore? • You can recover only recently deleted objects. The Azure AD Recycle Bin keeps deleted objects for a maximum of 30 days. If it has been longer than that since the user was deleted, you’re out of luck. • Some objects cannot be recovered at all. A hard-deleted object bypasses the Recycle Bin, so you can’t restore it using native tools no matter how recently it was deleted. • You can’t restore in bulk without PowerShell. An outside attacker, an errant script or a malicious insider can easily cause a massive number of incorrect changes or deletions in your Azure AD. But there is no native way to restore multiple users at one time without using PowerShell. Moreover, sometimes the object itself isn’t deleted; rather, the object’s Office 365 license type or extension attribute is improperly changed or deleted. In those cases, you’re really out of luck. Since cloud-only attributes are never recorded in your on-premises AD, neither Azure AD Connect nor native tools will help you restore them. Finally, there is no way to restore specific attributes that have been modified in a user object. Office 365 groups Users often create Office 365 groups to establish sets of people they want to collaborate with and a collection of resources for those people to share, such as a mailbox and calendar in Exchange Online, team sites in SharePoint Online and notebooks in OneNote. If one of these cloud-only groups is deleted by mistake, affected users will want it back quickly. You can’t restore the group using Azure AD Connect, since it never existed in your on-premises AD. The Azure AD Recycle Bin stores deleted groups for 30 days, but restoring Office 365 groups is a complicated 3 process. You can use PowerShell or the Exchange admin center to restore the groups, but you can’t restore individual attributes or groups. Similarly, if a malicious user clears the membership and deletes the group, you can restore the group to its membership only at the moment of deletion, with no way to get the membership back natively. You would need to know which users were deleted, but again, there is no Azure AD change log or comparison report to help you determine which Azure AD objects have been changed or deleted. Azure AD groups and group membership Organizations also create Azure AD groups to manage access to resources efficiently and in keeping with best practices. Unfortunately, if an Azure AD group or its membership is deleted, you’ll have to recreate it from scratch. Azure AD groups and group membership are not moved to the Recycle Bin when they are deleted; therefore, they cannot be recovered with native tools. Azure AD B2B and B2C accounts Azure AD offers two special kinds of user accounts to help you support your external customers and partners: business-to-business (B2B) and business-to-consumer (B2C) accounts. Organizations often have thousands or even millions of these accounts. By design, however, B2B and B2C accounts are not Microsoft Azure Enterprise accounts, and therefore they are not part of the Azure AD Connect synchronization. These accounts have different purposes: • Organizations use B2B accounts to authenticate users from partner organizations. For example, suppose the U.S. branch of a multi-national organization has moved to a hybrid AD environment, but its Canadian counterpart has not yet adopted Azure AD. To enable the Canadian employees to access the company’s cloud applications and documents, the U.S. organization creates Azure B2B accounts for them. • B2C accounts enable you to invite users of your mobile and web apps into your Azure AD using any supported social identity with direct federation, such as A hard-deleted object bypasses the Recycle Bin, so you can’t restore it using native tools no matter how recently it was deleted. their Facebook, Microsoft or Google+ account. B2C accounts are already extremely popular in a wide range of verticals, including finance, healthcare, insurance and retail. For instance, a company may allow customers to use their LinkedIn credentials to log on to its Azure AD. The company creates a B2C account for customers that enables them to access particular applications and data. If a B2B or B2C account is deleted, that user won’t be able to log on and access the resources and data they need. You can’t recover the account using your on-premises solution, since it never existed in your on-prem AD. Instead, you have to restore it from the Azure AD Recycle Bin, subject to the same limitations discussed earlier. If a B2B or B2C account is deleted, that user won’t be able to log on and access the resources and data they need. You can’t recover the account using your on-premises solution, since it never existed in your on-prem AD. Instead, you have to restore it from the Azure AD Recycle Bin, subject to the same limitations discussed earlier. Other cloud-only user accounts In addition to synchronizing user objects from an on-premises AD using Azure AD Connect, some organizations create Azure AD accounts using either an external directory, such as a virtual directory, or their identity management solution. Or they create cloud-only user objects that help employees connect to SaaS applications like Concur and Salesforce through Azure AD. On-premises backup and recovery will not cover those user accounts and their properties. Objects synchronized from sources other than on-premises AD Some applications, especially those created in house, do not work with AD natively, either by design or by function. They write directly to Azure AD outside of its native synchronization process. Examples include software for multifactor authentication that writes into Azure AD to enable user access, and applications that write data to an extended Azure AD environment to validate users. Without synchronization from Azure AD, these objects fall outside of the coverage of on-premises backup and recovery. TENANT-TO-TENANT MIGRATION Another little-considered use case often arises during tenant-to-tenant migration; for example, because of organization and role changes during a consolidation, merger, acquisition or divestiture. Some companies look to Azure AD as part of their backup and recovery strategy. 4 Consider a company undergoing a consolidation. It has dozens of tenants and must move users among tenants because of changes in employee roles and reporting structure. But it also sees the wisdom in allowing for contingencies during the consolidation, such as the need to restore some users to their former level of application access or to offer multiple temporary levels of access to certain users. Or consider a company undergoing divestiture of an entire line of business and spinning out a tenant with hundreds or thousands of user accounts. It would be prudent, good practice to retain a final backup of the accounts. Some companies have dozens or even hundreds Azure AD tenants for their various business units, managed by different administrative teams. If they rely on Azure AD as a failsafe during migrations and something goes wrong during their tenant-to-tenant migration or consolidation, they will find that native tools are not well suited to the task of disaster recovery. ENTERPRISE-QUALITY BACKUP AND RECOVERY FOR HYBRID ENVIRONMENTS Having reliable backup and recovery for both on-premises AD and Azure AD is critical for
Please complete the form to gain access to this content