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