What is Azure Active Directory?

I hope you’ve had a chance to read my recent series of blog posts on Active Directory (AD). If not, I encourage you to take a few minutes to do so now. No hurry; I’ll wait!

Great! Now we all know why Active Directory is at the heart of any on-premises Microsoft environment and the basics of how to manage and secure it. But AD is an on-premises technology, and many organizations today are either moving to the cloud entirely or, more commonly, adopting a hybrid deployment in which some systems and data are on prem and others are in the cloud. If that’s you, then you need also to understand AD’s online cousin, Azure Active Directory. To get you prepped, I’ve put together a new series of blog posts with the key things you need to know about Azure AD. Ready? Let’s get started right now with the basic concepts and terminology.

What is Azure Active Directory?

Azure Active Directory is Microsoft’s cloud-based identity and access management service. Like Active Directory, Azure AD comprises a database (directory) that records things like what users there are and who’s allowed to do what, and set of services that enable your employees to sign in (authentication) and access only the resources they’re allowed to (authorization). These resources include:

  • External resources, such as Office 365, the Azure portal and software-as-a-service (SaaS) applications
  • Internal resources, such as any cloud apps your organization has developed and (if you have hybrid deployment) apps on your corporate network and intranet

Do I have Azure AD?

If your organization subscribes to any Microsoft Online business service such as Office 365, you have Azure AD.
However, only some Azure AD features are included for free. To get capabilities like get self-service, enhanced monitoring, security reporting and mobile device security, you need to upgrade to an Azure AD Basic, Premium P1 or Premium P2 license.

Who uses Azure AD?

Three types of users interact with Azure AD:

  • IT admins work directly with Azure AD. In particular, they set up users, groups, permissions and various settings, such as when to require multi-factor authentication (MFA) and whether to allow users outside the organization to access various resources. The person who creates the tenant is automatically the Global administrator for it. That person can then add additional admins to the tenant.
  • App developers interact with Azure AD through application programming interfaces (APIs), for example, to enable their apps to work with a user's Azure AD credentials and to build personalized app experiences using the organization’s data.
  • Regular users generally don’t realize it, but they interact with Azure AD, too. Every time they log into Microsoft cloud resources, such as Office 365, SharePoint Online or Teams, Azure AD is at work behind the scenes, verifying that they who are they say they are and ensuring they can access only the resources their admins authorized them to use.

How is Azure AD structured?

The basic building block of Azure AD is the tenant. An Azure AD tenant is just a dedicated instance of Azure AD for a particular company. Once your organization signs up for a Microsoft cloud service like Office 365, you can sign in and create a tenant in less than a minute; all you have to do is specify your organization’s name, domain name and country or region. Your initial domain name will have “.onmicrosoft.com” appended to whatever you specify — that is, domainname.onmicrosoft.com.  You can't change or delete the initial domain name, but you can add custom domain names, such companyname.com, to your tenant so you can have more intuitive user names like jennifer.lupiba@quest.com.

It’s important to understand that here we’re using the word “domain” in the internet sense (a website domain name). It has nothing to do with an AD domain, which, as you’ll recall from my “What is Active Directory?” blog post, is a management boundary in an on-prem AD — a group of related users, computers and other AD objects that are stored in a single database and managed together. Similarly, Azure AD does not have trees, forests or organizational units; the key structure is the tenant. Each Azure tenant has a dedicated and trusted Azure AD directory, which includes the tenant's users, groups and apps, and performs identity and access management functions for the tenant’s resources.

Do on-prem AD and Azure AD work together?

They can — to a degree. In fact, while it’s possible to have a purely cloud-based environment, Microsoft says that 75 percent of its customers with at least 500 users have a hybrid AD environment — one with both on-premises and cloud users, applications and other resources.
What does that look like? Well, rather than try to manage two separate sets of identities and permissions, which would be very difficult and highly prone to error, you use the free Microsoft tool Azure AD Connect to sync your identity data from your on-prem AD to Azure AD. Your users can then use their on-premises credentials to authenticate to Office 365, your own custom cloud applications, and SaaS apps like Dropbox, Google apps and Amazon Web Services (AWS). Behind the scenes, you manage your users, groups and permissions (primarily) in your on-prem AD using your on-prem tools, and any changes you make are automatically synced up to the cloud.
Easy peasy, right? Not so fast. You spotted that hedge word “primarily,” didn’t you? It’s essential to understand that it’s practically impossible to consume 0ffice 365 or Azure services without creating some cloud-only objects and attributes. Here are some examples:

  • Cloud-only user accounts — Examples include B2B (business-to-business) and B2C (business-to-consumer) accounts. For instance, with B2B federation, you send external users, such as business partners or consultants, an email invitation and then federate their external identities into your Azure Active Directory. As a result, you have an Azure AD account that simply does not exist in your on-premises AD.
  • Cloud-only attributes — User accounts synced up from your on-prem AD often have cloud-only attributes. One example is Office 365 license type, which determines which Office 365 features a user is entitled to use. Since this attribute exists only in the cloud, so if the user object is deleted, you could recover the on-premises AD user object and use Azure AD Connect to sync it back up to Azure AD — but the license type attribute would be gone, leaving the user unable to work in Office 365 until you resolve the problem manually.

Therefore, whether you have a cloud-only deployment or a hybrid Active Directory, you’ll want to read the rest of the blog posts in this series, which cover the ins and outs of Azure AD management, security, migration and reporting.

Where can I learn more?

Those are the key basic concepts you need to know about Azure AD. But if you’re eager to learn more, check out the other blog posts in this “What is Azure AD?” series:

  • Part 2: Azure AD management (coming soon)
  • Part 3: Azure AD security (coming soon)
  • Part 4: Azure AD migration (coming soon)
  • Part 5: Azure AD reporting (coming soon)

Where can I get help with my Active Directory and Azure AD environments?

Quest is the go-to vendor for Active Directory solutions, both on premises and in the cloud. We can help you manage, secure, migrate and report on your AD and Azure AD environments to drive your business forward. For example, we’ll explore several of our tools for hybrid Active Directory security and governance in the future blog posts in this series.

Anonymous