This article is contributed. See the original author and article here.
If your organization is using Microsoft 365, you already have Azure Active Directory. It’s the identity platform that provides the authentication of your users’ credentials when they sign and and the authorization to your Microsoft 365 SaaS applications. If you want to then expand your use of Azure, you can take advantage of this existing directory instance, keeping all of your Microsoft services controlled by the same set of credentials. However, that doesn’t mean you should start using Azure Active Directory for your Microsoft 365 user management directly. Let’s explore the differences.
Adding a user
The Microsoft 365 admin center also allows you to set up user templates to help standardize the creation of new user accounts. The template includes their default domain, password settings on creation, location, licenses and apps to be assigned, administrative roles (such as Teams Administrator) and pre-populated profile information like office address. You can set up multiple templates for different scenarios and share them with the other admins.
In Azure Active Directory, you can bulk create user accounts with their information in a correctly formatted .csv file, but you cannot assign them a Microsoft 365 license during the creation process and some of the detailed profile information allowed in Microsoft 365 (such as office address) is also missing during the new user setup process. Microsoft 365 licenses do show up in the Azure Active Directory Licenses pane under All products, and they can be assigned to users there or new licenses bought, but generally you’d do your license management in the M365 admin center.
In both interfaces, you can assign administrative roles (like Billing Administrator or SharePoint Administrator) and add people to groups.
But only the Microsoft 365 admin center (and the Exchange admin center via Mailboxes) allow you to manage email aliases – that information appears in the user’s profile in Azure Active Directory in the list of proxy addresses, but it’s a read-only list.
Managing multi-factor authentication for a user from the Microsoft 365 admin center takes us straight to Azure Active Directory’s multi-factor authentication pane, with settings for users and service-wide settings (like trusted IP subnets and available methods).
Adding a guest user in the Microsoft 365 admin center shows you the Azure Active Directory integration – it takes you into the Azure portal and the new user page. If instead you add a guest user via the options inside Teams or SharePoint, the guest user will show up in both the M365 admin center and in the Azure Active Directory Users blade in the Azure portal. This is a great example of one identity system with multiple entry points.
Deleting a user
An important question for any organisation is “If I delete a user from Microsoft 365, what happens to their data?”, especially if you don’t want that data deleted! This is where the Microsoft 365 admin center is really helpful. Deleting a user takes you through a series of questions and options for their associated data. It’s now more automated than the old manual process of converting the mailbox to be a shared one, then deleting the original user account. The wizard asks if you want to give access to the deleted person’s email to another user (converting it to a shared mailbox), allows you to change the display name, set automatic replies, remove aliases and unassigns licenses. You are also asked if you want to give another user access to OneDrive files for 30days after the user is deleted.
To learn more, visit Remove or delete a former employee.
Delete a user in Azure Active Directory, and you’ll see a Yes/No prompt to confirm. That’s it.
Group management
If Azure Active Directory is my Microsoft 365 identity platform, where do I manage my groups? Well, it depends on what kind of group management you are doing. All groups will appear in Azure Active Directory but you can’t use the Azure portal to manage groups synced from an on-premises Active Directory (which must be managed in the on=prem directory) and some group types like distribution lists and mail-enabled security groups (which must be managed in the Microsoft 365 admin center or the Exchange admin center).
As you extend your use of Azure, you might create security groups directly in Azure Active Directory for access to Azure resources and applications, or you might use an existing mail-enabled security group that was created in M365 if it already reflect your organization’s structure – just be mindful where you have to go to make group changes and what resources (in M365 and Azure) that group has access to.
For more information, see:
Manage app and resource access using Azure Active Directory Groups
Manage Microsoft 365 groups
Manage a group in the Microsoft 365 admin center
Other admin centers
The Microsoft 365 admin center also contains links through to product or feature specific admin centers, such as security, compliance, Endpoint Manager, Teams, Yammer, SharePoint, OneDrive and more.
PowerShell
Comparing portal experiences is one thing, but what about PowerShell? The answer to this is “yes”!
To start with, there’s the Azure Active Directory PowerShell module (also known as Azure Active Directory PowerShell for Graph or just the AzureAD module) – with cmdlets like Get-AzureADGroup and New-AzureADUser. Learn more at Azure Active Directory PowerShell for Graph.
Then there is also the Microsoft Azure Active Directory Module for Windows PowerShell (whose cmdlets include Msol in their name). At the time of writing, there is some functionality that only exists in this module, and it’s safe (and recommended) to use both. One example of this is Set-MSolUserPrincipalName. Just note that the Microsoft Azure Active Directory Module for Windows PowerShell and those msol cmdlets won’t run on PowerShell version 7 or later or PowerShell Core. For more information, visit Connect to Microsoft 365 with PowerShell.
In addition, Microsoft 365 services may have their own specific PowerShell modules. For example, Exchange Online has a small set of cmdlets optimized for retrieving thousands and thousands of objects as one, with the Exchange Online PowerShell V2 module (also known as EXO V2). That has cmdlets like Get-EXOMailboxStatistics. To learn more, visit About the Exchange Online PowerShell V2 module.
Expanding your use of Microsoft Azure
Your use of Azure Active Directory is often first determined by your existing environment (before you adopted any Cloud services) and the order in which you started using the Cloud.
If you had on-premises Active Directory servers first and then started using Microsoft 365, you may have connected your on-prem AD to Azure Active Directory via Azure AD Connect. In this case, you may primarily be doing your user and group administration in your on-prem AD and syncing those changes to Azure AD. When you want to use resources and services in Azure, use this same directory instance and add your Azure subscriptions. It’s the one place that has your organization’s custom domain name and makes both user management and the end user experience better, as you dont have to manage separate identities for the same person. It also opens up the enhanced security features of Azure Active Directory Premium (like multi-factor authentication) for both your Azure and Microsoft 365 resources, and provides that seamless single sign on experience for your on-premises resources.
If you created Azure resources first as a cloud-native organization, it makes sense to use that same directory instance if you adopt Microsoft 365.
With your Azure subscriptions and resources, it’s a good idea to limit access by using Role-Based Access Control (RBAC) . It’s currently possible (as a preview feature) to use an M365 created mail-enabled security group to assign an Azure AD role to, but there are some limitations and licensing requirements. Also, on-premises groups cannot currently be assigned to Azure AD roles. For more information, visit Use cloud groups to manage role based assignments in Azure Active Directory (preview).
Summary
Azure Active Directory is the underlying platform for Microsoft 365, but there are some administrative functions you need to perform in the Microsoft 365 admin center or with the PowerShell commands for specific Microsoft 365 services. As you look to adopt more Azure-based resources, take a look at how your users and groups are already structured and identify where it makes sense to use these for access to Azure, without creating a separate identity directory. There’s power and simplicity in using your directory for both.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments