Welcome back to part 2 of the “Core Components of Microsoft Teams” blog series! This time we’ll be discussing what Azure AD is and how it relates to Microsoft Teams.
What is Azure Active Directory (AAD)?
Azure Active Directory (AAD) is Microsoft’s multi-tenant , cloud based directory and identity management service. Azure AD combines the core directory services that we use in Microsoft Teams as well as application access management and identity protection all into one solution. For those of you coming from an on-premises Windows Server environment you will know that we referred to this as our Windows Server Active Directory/Directory Service. In many instances a company will choose to leverage both an on-premises Active Directory and cloud Azure Active Directory via a synchronization mechanism. Azure AD is broken down in a few different editions:
- AAD Free
- Included with every Azure subscription
- AAD Basic
- Typically used by task workers whom often have cloud first needs
- Group based access management
- Self-service password reset for cloud applications
- AAD Application Proxy
- Gives organizations the ability to publish an on-premises web application while utilizing features and functionality in AAD
- Typically used by task workers whom often have cloud first needs
- AAD Premium P1
- Adds enterprise-level identity management capabilities
- Dynamic groups
- Self-service group management
- Adds enterprise-level identity management capabilities
- AAD Premium P2
- Adds identity protection and privileged identity management (includes all P1 features)
For a full breakdown of these editions please see: https://aka.ms/azure-features
Identity Models used with Microsoft Teams
When looking at different identity models there are 3 different types of classifications:
- Cloud Identity – When user is created and managed in Office 365 and stored within AAD, and the password is verified by Azure Active Directory.
- No on-premises servers (pure cloud)
- Synchronized identity- When user identity is managed in an on-premises server, and the accounts and password hashes are synchronized to the cloud.
- Identities synced via directory sync mechanism with password hash sync to Azure Active Directory
- Requires ability to manage/maintain the directory on-premises so Windows Server with Active Directory would be required as well as a synchronization tool like Azure AD Connect
- Provides single sign-on experience however there are 2 directories to maintain on-premises identity directory in Windows Server AD and synchronized directory in Azure AD
- Requires a couple servers in the on-premises environment
- Federated identity – Requires a synchronized identity where the user password is verified by the on-premises identity provider (such as ADFS)
- Still have directory sync mechanism in place (like Azure AD Connect) but will also need another component that provides service to check user credentials (typically ADFS)
- This solution requires a large number of on-premises servers especially since high availability would be of utmost importance in this type of architecture.
- Still have directory sync mechanism in place (like Azure AD Connect) but will also need another component that provides service to check user credentials (typically ADFS)
Syncing Identities to the Cloud
When synchronizing identities to the cloud you will typically leverage a tool like Azure AD Connect. This is a free tool provided by Microsoft that enables common identities between the on-premises Active Directory environment and online Azure Active Directory environment. Synchronization happens securely over the internet and Microsoft even provides an Express Settings setup to get you on your way as quickly as possible. If you want to dive even a little deeper, you have the option of a custom setup for more complex scenarios. The custom setup allows you to cover scenarios like:
- Multi-forest topologies
- One that requires filtering of which accounts are syncronized into the directory
- One that requires configuration of Single Sign on (SSO)
- One that requires configuration of Azure AD Premium features
- One that has custom attributes
The Azure AD connect tool also allows you to setup sign-in using either the password synchronization or the federation with ADFS. So, this means you can use this tool for both synchronized and federated identities.
Synchronized Identities with Password Sync
When synchronizing your identities with password sync your experiences will differ between the end user and the administrator.
User Experience
From a user’s perspective they only know about a single identity, single username, and single password. Everything else involving the multiple directories on the back-end and synchronization is happening is completely transparent to the end-user. Authentication for end users will typically happen in the cloud but could happen on-premises depending on whether or not an Azure AD proxy is used that allows for authentication for the on-premises environment. If you have a scenario where your users have two ID’s in two different directories but culminates as a single username and password combination then this will all be transparent to the end user.
Administrator Experience
From an administrative perspective, there won’t be anything to maintain in the cloud identity provided synchronization is happening properly. All the maintenance and management would be complete in the on-premises environment and the Azure AD connect will take care of the synchronization piece for you.
Federated Identities
Now that we’ve looked at the synchronized identities, let’s cover the federated identity experiences for end-users and administrators.
User Experience
For the end-user they would sign-in with their corporate ID. The authentication would happen in the on-premises environment via the claim based system. As expected, users will have a single credential that provides SSO whether it be an on-premises or online service. So this means they will get a true SSO experience while only needing to utilize that single username and password.
Administrator Experience
From an administrative perspective, federated scenarios are a bit more complicated due to number of components in play including ADFS. In this scenario, the password policies would be managed on-premises only since this is where the authentication is happening. This will also require additional servers to enable this identity federation. Also, if high availability is needed, we will need redundancy in those servers which means additional cost. These are all things to consider when choosing a federated identity experience. The last topic we’ll discuss in today’s blog will be how Teams leverages Azure Active Directory.
How Teams leverages AAD
We will utilize AAD as our identity mechanism to provide SSO for our O365 applications. As part of AAD we can also leverage MFA (multi-factor authentication) for an additional level of security. With MFA in place, this will require an additional token to allow you to gain access to the service. You also have the option of utilizing Conditional Access so that users can utilize the application but only at a particular location or particular device state such as a device managed by Intune. In addition, there is the capability to leverage Access Reviews (currently in preview). Access Reviews provide attestation for guest users gaining access to your Teams environment and ensure that that those users still require that level of access and if not that they are removed from the system. Lastly, there are advanced modern group features like naming policies and group expiration and these will be discussed further in the next blog on Office 365 Groups.
This concludes today’s blog article. In the next article of this blog series we’ll cover Office 365 Groups and how Teams leverages Groups. I hope you have found this article helpful and I hope you’ll tune in for the next blog in the series soon!
