IT Blog

Identity & Access Management

Overview of User Identities & Authentication Options in Microsoft 365 and Azure

Overview of User Identities & Authentication Options in  Microsoft 365 and Azure

To plan user identities, you first need to understand the different user identities, namely: Cloud identities, Synchronized identities, and Federated identities. You can choose to maintain identities only in Office 365, or you can integrate identities with your on-premises Active Directory.

Cloud identities

Cloud identity is a user account that exists only in Azure AD. You can create a cloud identity with the same name as your on-premises AD DS user account, but there is no link between the two accounts. They would be considered two different, unique identities, each with their own password. You will create cloud identities by using the Office 365 admin center. Most often, only very small organizations use cloud identities because they do not need to maintain a local Active Directory implementation.

Synchronized identities

A synchronized identity is a user that exists in an on-premises AD DS and in Microsoft 365. The AD DS user and the Microsoft 365 user are synchronized and linked together. Any changes that you make to the on-premises user account are synchronized to the Microsoft 365 user account. Azure Active Directory Connect (Azure AD Connect) performs the synchronization. You need to download Azure AD Connect and install it in your on-premises environment. Azure AD Connect provides the ability to filter which accounts are synchronized and whether to synchronize passwords. When you implement synchronized identities, your on-premises AD DS is the authoritative source for most information. This means that you perform administration tasks mostly on-premises, which are then synchronized to Azure AD. Only a very small set of attributes synchronize from Microsoft 365 back to ADDS on-premises. Authentication for synchronized identities occurs in Microsoft 365. The username and password are evaluated in Microsoft 365 without any reliance on the on-premises infrastructure.

Federated identities

A federated identity is a synchronized user account that is authenticated by Lightweight Directory Access Protocol (LDAP) on the AD DS which creates a local claims provider trust with the Active Directory Federation Services (AD FS). AD FS is deployed on-premises and communicates with AD DS on-premises. Therefore, Azure AD authorizes federated user accounts to access resources in Microsoft 365 based on the LDAP policy located on AD DS (through AD FS). Because the on-premises user account is used for authentication, the same password is used for signing in to Microsoft 365 and on-premises AD DS. Implementing federated identities used to be significantly more complex than implementing synchronized identities because of the requirement to implement AD FS. However, that complexity has basically been removed with the adoption of Azure AD Connect, which now deploys most of the AD FS infrastructure. Because authentication to Microsoft 365 is dependent on the availability of AD FS, service interruptions to the on-premises infrastructure can affect Microsoft 365 authentication. For example, an on-premises Internet outage will cause Microsoft 365 authentication to fail. However, you can mitigate this by placing a copy of AD DS and AD FS in Microsoft Azure.

The main benefit of using federated identities is single sign-on (SSO). Users authenticate at a domain-joined workstation by using their credentials. SSO uses these cached credentials to automatically authenticate to Microsoft 365 services. Synchronized identities typically need to enter their credentials manually when accessing Microsoft 365 services. Federated identities also take advantage of password policies and account lockout policies in an on-premises AD DS. This provides more flexibility when managing password policies for Microsoft 365.

Microsoft 365 Authentication Options

Azure Active Directory (Azure AD) is an online instance like Active Directory. Azure AD provides authentication and authorization for Microsoft 365 (which includes Microsoft Intune) and for other Microsoft cloud offerings, including Azure. Azure AD can authenticate cloud-only identities or identities synchronized with an on-premises directory, with optional password synchronization, or you can enable user authentication with on-premises user accounts through Active Directory Federation Services (AD FS) or other single sign-on (SSO) providers.

Authentication options in Microsoft 365 fall into one of the following categories:

Cloud-only.

Directory Synchronization with Pass-through authentication (PTA).

SSO with AD FS.

Cloud-only

Cloud-only identities are exactly as the name suggests; the user identity only exists in the cloud, so all password management and policy control are done through Azure AD.

Directory Synchronization with Pass-through authentication (PTA).

This authentication option provides a simple password validation for Azure AD authentication services. Pass-through uses a software agent running on one or more on-premises servers to validate the users directly with your on-premises Active Directory. With PTA, you synchronize on-premises Active Directory user account objects with Microsoft 365 and manage your users on-premises. PTA enables users to sign in to both on-premises and Microsoft 365 resources and applications using their on-premises account and password.

SSO with AD FS.

The SSO option hands over authentication control to your directory service; therefore, users no longer authenticate against Azure AD but against AD FS. Consequently, when a user types their login credentials (for example, user@abc.com) into the Microsoft 365 sign-in page, the user receives a message telling them that they have been redirected to their organization’s sign-in page. They now enter their on-premises credentials and authenticate to the Microsoft 365 online services by using a delegated token that verifies to Microsoft 365 that the user has been successfully authenticated by their on-premises directory service.

Ports and Protocols in deployment.

Leave a Reply

Your email address will not be published. Required fields are marked *