The role of Azure Active Directory in an Hybrid Identity environment seems hard to understand. Azure AD is not a 100% slave to Active Directory. There are objects and attributes in Azure AD that have no relationship with on-premises objects or attributes in Active Directory Domain Services.

We’ve come across many admins in organizations, who believe that they are in complete control of Azure Active Directory, while in fact, they are not. Their beliefs fall into three main categories, based on quotes we here all the time. Today, It’s time for some clarity and to show you a way to get an overview of all the objects, attributes and configured settings in your Azure Active Directory Tenant.

Main Categories for the level of Control of Azure Active Directory

When I talk to admins, there seem to be three main categories of answers on how they control Azure AD, that I feel are all untrue:

“We don’t use Azure AD.”

“I don’t synchronize my Active Directory Domain Services environment, so my organization does not exist in Azure Active Directory.”

The most dangerous category of organizations is the ‘cloud-ignorant’ organization. While admins may be right with their quotes from a technical perspective, the business side of things looks completely different.

I have yet to come across a medium-sized organization (or larger), that didn’t have an Azure Active Directory tenant. Specifically, when any person in an organization accepts an invitation to collaborate in an Office 365 service (whether it’s a SharePoint Online library, a Team or even a Power BI dashboard), an Azure AD tenant is created for all people with email addresses referencing your DNS domain name(s).

Microsoft calls these tenants ‘unmanaged’. I feel the term hits home. Because they are unmanaged from an organizational perspective, they don’t seem to exist to the IT department. This is a classic case of shadow IT. Indeed, colleagues have multiple accounts, multiple password policies and, thus, multiple passwords to remember, etc.

“We control every aspect of Azure AD.”

“I only synchronize a specific Organizational Unit (OU) with user objects, so these objects, plus the occasional bootstrap account, are the only objects in my tenant. We control every aspect of these objects centrally.”

In a Hybrid Identity environment, Azure Active Directory is not a 100% slave of Active Directory Domain Services. Many attributes for objects in Azure AD don’t even flow from AD on-premises, because they don’t exist there. cloudMastered is a perfect example of such an attribute, because it’s writeable from Azure AD, possibly switching a previously synchronized user to a cloud-only user. (Yes, it will be matched in the next synchronization cycle)

Other attributes like the license type, the usage location and Azure multi-factor authentication information are stored in Azure AD for the objects. When you delete a user object on-premises, but reanimate or restore it, it doesn’t magically restore these settings too, when you restore it after 30 days.

The real fun begins when organizations migrate to Windows 10 1703, or up and use a recent version of Azure AD Connect (version 1.1.486.0, or up) with Express Settings.
This setup creates an Azure AD-based object for each of the domain-joined devices, by default, resulting in Hybrid Azure AD-joined devices. Perfect for Conditional Access, but it does mean that organizations have device objects in Azure AD that they are unaware of. Without Intune, both objects may become out of sync, causing all sorts of unexpected results when organizations start using Conditional Access.

“We only manage Azure AD objects for our organization.”

“We’re a straight-forward organization. We only managed the objects for our own organization, so we won’t have to worry about regulations like GDPR in Azure AD.”

If only…

Remember the unmanaged Azure Active Directory tenant for the cloud-ignorant organization? As an organization with Azure AD, you can also invite people from other organizations. The B2B objects to govern this guest access are created in your Azure AD tenant. If anything were to happen with your tenant, you’d be responsible for these objects.

Getting to know your tenant inside out

As I was talking to the people at Quest the other day, they showed me a a way their Quest On Demand solution can be used, to show all the information in your tenant.

Note:
The solution we use today is not free. However, the use to sum up the objects, attributes and configured settings is within the limitations of the 30-day trial license and does not impose a future state where organizations need to purchase licenses.

Requirements

To use this tool, you need the following:

• Administrative access to your organization’s Azure AD tenant. If you suspect an unmanaged tenant is present, sign up for a free Power BI trial, create an account and log on with this account to the Azure Portal. In the portal follow the steps to claim the tenant using DNS verification.

Steps

Follow these steps to get to know your tenant:

• Navigate a browser window to Quest.com/AzureADrecovery.
• Indicate you have read and accept the license agreement and click Create a Trial Account or use the Sign In for your Free Trial and use an existing Microsoft Account to sign-in.
• In the Welcome to On Demand screen, create an organization when prompted for one, when Quest doesn’t have an organization associated with your account. If you are trying to connect to an existing Quest On Demand organization, make sure that your email address is added.

• In the On Demand portal, scroll down, until you reach Azure AD Recovery. Click on the button Start By Adding A Tenant.
• This is the Tenants subsite of Quest On Demand. Click the + Add tenant tile.
• Sign into your Azure AD tenant with an account that has administrative privileges in the tenant you want to add. Perform multi-factor authentication and/or privileged identity management approval, when prompted.
• After signing in, click Accept to provide admin consent for the tenant for Quest on Demand – Core to Access the directory as the signed-in user and Read directory data.
• The Tenants sub site will now show a tile for your tenant below the default + Add tenant tile. Your tenant will show with 1 as the value for Consent granted. Click on the tile for your tenant.
• Scroll down a bit. For the Recovery module, click on the link Grand Consent.
• Sign in again, and Accept additional permissions for Quest On Demand’s Recovery module.

• The Tenants subsite of Quest On Demand will now show the tile for your tenant with 2 as the value for Consent granted.
• From the Quest On Demand main menu, select Backup and Recovery.
• In the Backup and Recovery subsite of Quest On Demand, click on the blue Go button for Recovery for Azure AD.
• In the Recovery for Azure AD subsite, click on Create Backup from the top action bar.
• Then, go to Backups using the top navigation bar. You can already see the number of users, groups, service principals, contacts and links as statistics for the backup.

• Unpack the backup, using the link in the task bar above the backup(s).
• Now, in Objects you have a list view of all objects in the Azure AD tenant.
• When you select the selection box at the top of the objects list, the Export button lights up. This option allows you to download a zipped *.csv file with the contents of the Azure AD tenant.

Steps to leave Quest on Demand

Before the trial ends, you’d want to stop using Quest On Demand Recovery for Azure AD. Because you’ve registered a service principal for the service, we need to undo it. Follow these steps to do so:

• Sign into quest-on-demand.com
• Go the the Tenants subsite
• In the right top corner of the tile for the tenant you want to unregister with Quest On Demand, click on the three vertical dots. Click Remove.
• Click OK to acknowledge that removing cannot be undone, removing a tenant disables all module functions related to the tenant, active backups and provisioning actions will be cancelled and audit event data will no longer be collected.
• Close the Quest On Demand website.
• Open the Azure AD Portal and sign in with with an account that has administrative privileges in the tenant you want to remove from Quest On Demand.
• In the left navigation pane, click on Enterprise Applications.

• From the list, click on Quest On Demand – Core. Click Delete in the top navigation bar. Click Yes to confirm. Close the pane to return to the list of enterprise registrations.
• From the list, click on Quest On Demand – Recovery. Click Delete in the top navigation bar. Click Yes to confirm. Close the pane to return to the list of enterprise registrations.
• Sign out.

Concluding

As an organization, don’t think Azure AD is a pure slave to your on-premises Active Directory Domain Services environment.

Use a trial license for Quest On Demand Recovery for Azure AD to gain insights in your Azure AD tenant. At the end of the trial, either revoke access to your tenant or happily continue to use their product.