On-premises Exchange administrators are intimately aware of how Exchange relies on Active Directory

to store much of its configuration data plus information about mail-enabled objects Exchange Online
depends on Azure Active Directory and uses it in much the same way as on premises.
Exchange uses Active Directory, with some significant differences centered around how the Office 365
workloads leverage Azure Active Directory and its own workload-specific directory

Azure is highly available multitier,multi-tenant service that is capable of handling load at immense scale

Every Office 365 tenant has a corresponding tenant within Azure Active Directory running within the

service, and each instance is isolated from others so that no tenant has access to data belonging to

another tenant.

Azure Active Directory is used by Microsoft Dynamics CRM, Intune, and other cloud services.

When you first create a brand-new Office 365 tenant, the setup process also creates a new Azure AD

tenant for you As you add users and groups, those objects go into this Azure AD tenant, but you see and
manage them through the Office 365 Admin center.

Remember that guest accounts need user rights to use premium Azure Active Directory functionality

To support workload needs,and to isolate the configuration and other data owned by a single tenant
inside the multi-directory Azure Active Directory, each service adds another layer on top of Azure Active
Directory. This layer is a workload-specific directory store and is named after the workload:

Exchange Online Directory Services (EXODS).

SharePoint Online Directory Services (SPODS).

Lync Online Directory Services (LYODS).

Yammer Directory.

Teams Directory.

Exchange Online Directory Services

Exchange Online uses EXODS to hold its configuration data, including information about mail

enabled
recipients. Exchange Online is deployed across multiple forests (30 or so according to the

most recent Microsoft reports) with tenants divided between the forests. Each forest is unique to an

Office 365 region and has its own instance of EXODS together with a synchronization endpoint that is

used to replicate information with the directories used by Microsoft Online Services (for user
accounts and licensing), other applications (like SharePoint for mailbox information used in

eDiscovery), and Azure Active Directory.

Exchange Online can create new Microsoft Online Services accounts during the mailbox creation

process. In this case, synchronization pushes the information about the new account to the Microsoft

Online Services directory and to Azure Active Directory, which serves as the overall master

directory for Office 365. Exchange Online is unique in this capability, which exists because many

customers have built extensive mailbox provisioning workflows with PowerShell or Exchange Web

Services that would break if forced to connect to Azure Active Directory or Microsoft Online

Services instead.

Identity Models for Office 365

Standalone identity : In this model, user accounts exist only within the Office 365 environment

and are not linked or related to any other Active Directory environment. This means that a user

may have an account in an on-premises Active Directory, as well as an account in the Azure

Active Directory that supports the organization’s Office 365 tenant. The accounts may happen to

have the same username and password, as well as other attributes, but are separate and

independent objects, and need to be managed independently as well. This duplicates

administrative effort and introduces risks if attributes conflict or are not maintained correctly

Hybrid identity: In this model, user accounts are created and managed in the on-premises

Active Directory environment and synchronized to Azure Active Directory (and thus to Office

365). The synchronization is performed by a directory synchronization tool; the only supported

tool is Azure AD Connect. In the hybrid identity model, the on-premises Active Directory is the

“source of authority”, with objects and attributes replicating from on-premises to the cloud.

Because the on-premises Active Directory is now the source of authority, an administrator can

only change limited aspects of the synchronized identity in Office 365

A synchronized identity exists in the cloud, but users still need a way to authenticate using that identity

plus a password.

Password hash synchronization : In this model, a cryptographic hash of the user’s password,

but not the password itself, is synchronized to the cloud. When a user requests access to a

service component, the password they provide is hashed; if that hash matches the stored hash, the

passwords are considered to match. This process relies on directory synchronization but doesn’t

require any other servers or components.

Pass-through authentication (PTA): in this model, user accounts are synchronized from on

premises domain controllers to Azure Active Directory. Authentication requests from the service

are sent to a queue, where they are retrieved by a small agent that runs as part of Azure AD

Connect. The agent validates passwords and returns an access token if the validation succeeds.

Federated identity: In this model, user accounts are also populated in Azure Active Directory

through directory synchronization, but authentication requests from the service are passed to an

on-premises federation server. This can be Microsoft Active Directory Federation Services (AD

FS), or a third-party federation service such as Ping Identity or Okta. The federation server is

responsible for authenticating the user by passing an authentication request to an on-premises

AD domain controller, then returning an authentication token for the user to access cloud

services. This process provides the end user with a single sign-on (SSO) experience that can be

used to access various Office 365 services.

pros and cons

Standalone identities are convenient because they do not need an on-premises Active Directory.

Most small organizations using Office 365 don’t have, or want, on-premises AD. However, if an

on-premises Active Directory is available, cloud identities can be more time consuming to

manage because two separate accounts need to be managed for each user. There is no arbitrary

threshold for user objects to manage before synchronizing identities makes more sense. It
typically comes down to how much time and effort an administrator must put into managing dual

identities versus maintaining a synchronization infrastructure.

Directory synchronization simplifies administration because all changes are typically made to

the on-premises Active Directory and then synchronized to the cloud by a synchronization

infrastructure that must be managed and maintained. However, if password hash sync (PHS) is

used, Office 365 can authenticate users when the on-premises Active Directory is unavailable

(for example, if a power failure occurs at the on-premises datacenter). Even when using

directory synchronization, you can still create and use cloud-only identities (for instance, for the

group objects created by Office 365 Groups, or for external users who only need access to

Office 365 resources).

Federated identities give organizations much greater control over how to enforce security

policies such as logon hours, third-party multi-factor authentication, and network locations from

which users can access Office 365 resources, as well as any other cloud service that uses AD

FS. However, the identity federation infrastructure must scale to meet performance and

workload requirements. It must also be highly available and resilient to failure because Office

365 may not be able to authenticate user logons if the federation service is not available. It is

possible to use password synchronization as a fallback option when your federation

infrastructure has failed. However, this is not an automatic process and must be considered

during the planning and deployment phase

By default, Office 365 sets the primary SMTP address for an object to be its UPN and things usually

stay that way. However, this does not have to be the case as the two properties serve different

purposes: the UPN identifies the object to Office 365 and the primary SMTP address routes messages

to its mailbox, if it is mailbox-enable.

Changing a UPN for a cloud-only identity is straightforward. However, when an identity belongs to a

federated domain, things can become a little more complicated.

Service accounts

Not all the accounts you use with Office 365 belong to users. Some applications, such as those that

monitor workload health or report on various aspects of Office 365, might require the creation of

special service accounts. that are solely used for administrative purposes. These accounts usually do

not need a mailbox or a license, but probably need the assignment of some form of administrative

permissions to be able to view and access data on behalf of the tenant

Syncronised identities

Directory synchronization is most often associated with a hybrid Exchange deployment, many
organizations use it even when Exchange on-premises is not in the picture as it is the only way to avoid
duplicate management of objects. There is no magical number that states what the threshold is for
implementing directory synchronization, nor is there any lower limit. Obviously, the larger the on-
premises organization, the more sense it makes to deploy directory synchronization.

This happens because directory synchronization is a mostly one-way operation that flows from the

on-premises organization to Azure Active Directory. The on-premises version of the object is the

authoritative source. Objects that are created directly in Office 365 are considered cloud-only objects

and are, by default, not synchronized back to the on-premises Active Directory. The only exception to

that rule is when you have a writeback feature enabled. Writeback is a capablity in Azure AD

Connect which permits the synchronization of some recipient types (such as Groups) and attributes

(such as mobile device partnerships) back to the on-premises directory.

for ex directory synchronization process did not update the User Principal Name (UPN) for

a synchronized user when an Office 365 license is assigned to that user. Although you could still

change the UPN as explained in the Cloud-only Identities section, this approach needs a manual

update for the UPN, which is not very practical if you need to update many UPNs at once.

Hybrid Writeback Attributes

Although the synchronization of objects is usually a one-way operation to Office 365, a handful of

object attributes are written back into the on-premises organization if you enable hybrid mode while

setting up the directory synchronization tool. The writeback attributes are necessary to support some
features in a hybrid deployment, such as the ability for an on-premises mailbox to access a cloud

based archive. Currently, there is no way to select which attributes are synchronized back into the on

premises organization from Office 365.

The attributes that are written back to on-prem AD from office365

Federated identities

Federated Identities are very like synchronized identities, with the exception that authentication is no

longer handled solely by Azure Active Directory, but by an on-premises Active Directory Federation

Services farm or a third-party federation solution. A by-product of configuring identity federation is

that it can provide a single sign-on experience (SSO). SSO is when users authenticate to both the on

premises organization and Office 365 using the same username and password without having to type

their credentials again whenever they access an Office 365 resource. When an object synchronizes with
Azure Active Directory, it automatically becomes a synchronized identity. Despite offering a similar
sign-on experience, password synchronization is not an identity federation solution as Azure Active
Directory still confirms authentication requests When you federate a domain, the responsibility for
validating authentication requests is shifted towards the federation solution. The application that’s
asking the federation system to perform an authentication is known as the relying party (because it’s
relying on the federation service). Third party federation applications generally makes requests to,
and gets responses from, the federation server using a protocol known as the Security Assertions
Markup Language (SAML), while AD FS uses a competing standard named WS-Fed/WS-Trust. Both of
these standards specify the format and content of data and metadata that the service and federation
broker can use to negotiate and perform the authentication. Both use the concept of claims, which are
statements made by one party about another. For example, the application might send a claim to the
federation server that says “the user requesting authentication is coming from IP address 172.16.0.204”
and the federation server might reply with a set of claims that includes “the email address associated
with the account you’re trying to authenticate is paul@office365itpros.com . ” You can configure claims
rules that allow or restrict authentication based on the contents of these claims.
Federation is enabled per domain and all users in Azure Active Directory for whom the domain

portion of the UPN (UPN suffix) matches a federated domain are automatically considered to be

federated identities. Even with federated identities, the first authentication request is still received by

Azure Active Directory. The user's UPN suffix is examined and, if the domain name is federated,

Azure Active Directory will redirect or proxy the authentication request to the customer's federation

solution. This process is called home realm discovery and needs to be performed for each initial

authentication (such as the first time that someone logs on). You can see this process at work when

you have federation set up and you visit an Office 365 logon page; at first you see the standard

Microsoft logon dialog, which contains code that looks at the right-hand side of the entered UPN and

determines if it’s a federated domain, redirecting to the organization’s federation solution if so.

The details of the customer's federation solutions and all the relevant details such as the federation

endpoint and certificate information are stored in Azure AD during the federation setup process. The

initial request (home realm discovery), and the subsequent redirects all happen within a matter of

seconds, often transparent to the user.

Keep in mind that you should also update the UPN on-premises to align the UPN in Office 365 with

the on-premises UPN. Once you have made the update in Azure AD and the on-premises Active

Directory, the synchronization error for that account will automatically disappear.

To Federate or Not?

It is unsurprising that password hash synchronization is the fastest growing authentication method in
Azure Active Directory, as it's much easier to deploy and maintain, and it offers a similar login
experience to end users.

In addition, users will still be able to authenticate, even when the on-premises infrastructure is down;
the only thing that would (temporarily) stop working in such a scenario, is the actual synchronization of
passwords.

On the other hand, identity federation (for example, through Active Directory Federation Services)

can solve very specific problems, like whether to block authentication from outside the corporate
network or to limit access to Office 365 services to members of a specific group. In addition, it is

also the only way to integrate with third-party multi-factor authentication solutions.

The introduction of pass-through authentication (PTA) in Azure AD Connect complicates your choice

a bit further. The decision point on whether to use PTA or federation boils down to whether or not you

need true federation. For example, you can use AD FS to provide single sign-on with Amazon Web

Services, service desk management solutions, employee benefits systems, and other cloud

applications from third parties, whereas PTA doesn’t support these applications. For most

organizations, PTA is simpler to implement, and still allows you to take advantage of features such as

conditional access through Azure or Enterprise Mobility + Security.

Most organizations allow users to save their credentials to avoid having to re-enter them

every time an Office 365 workload needs authentication. The single sign-on experience also depends

on how users access their domain-joined computer. For SSO to work, they must use their UPN to log

on to their computer. Remote users, workgroup users, Mac users, and users on mobile devices will

still have to sign-in to AD FS every time they access an Office 365 workload for the first time.

Third-party Federation Solutions

Active Directory Federation Services is not the only federation solution to enable Single Sign-On.

Several third-party solutions, such as those from Okta, Ping Identity, and OneLogin take a similar

approach to federation, albeit without needing the deployment of extra on-premises servers. Many of

these solutions have gone through a validation process called “ Works with Office 365 ”. This means

that these solutions have been tested by Microsoft and that you can substitute AD FS with one of these

solutions. Azure ad contains multi factor authentication and self-service password management for
office365.Many of these features require license for azure ad premium and enterprise mobility suite.

let's first look at how authentication is performed in Office 365.

The simplest credential that can be used for authentication is the combination of a

username and a password. This option is also the default in Office 365 for all non-federated

identities.
When a user attempts to access resources in Office 365, the user is prompted for credentials.

Depending on what client is used, the authentication prompt comes in various forms. One such

example is the username/password form on the Office 365 portal web page, but each client can

implement its own interface. Microsoft has worked hard to standardize the appearance of the Azure

AD-based logon interface across clients and platforms, although starting in late 2017 they began

tweaking it again and so you may notice some differences between clients and platforms. No matter

the interface, once the user provides a credential, various things happen behind the scene depending

on what client is used and what authentication method has been configured.

Basic Authentication

When looking at the authentication process in Azure AD, one can distinguish two main approaches to

authentication: basic authentication and modern authentication. The former is used when legacy

clients, those that do not support modern authentication capabilities, connect to Office 365. For

example, this is the case when an ActiveSync client connects to a mailbox in Exchange Online.

When a basic-authentication client connects, a basic authentication prompt is shown. Once the user

enters their credentials, they are forwarded to the service (Exchange Online) which, in turn, will

connect to the underlying authentication solution (Azure AD or AD FS) to validate the credentials. If

the credentials are successfully verified, the service will authorize the client to connect to the

resource it requested access to. This process is quite different from Modern Authentication where the

client communicates directly with the authentication endpoint.

you cannot perform multi-factor authentication using basic authentication, nor can you exert the same

levels of controls (through policies) as with the modern authentication options.

Disable Basic Authentication for Exchange Online

In mid-October 2018, Microsoft announced a public preview of a long-awaited feature: you can now

turn off Exchange Online support for basic authentication. The blog article announcing this change

makes for very interesting reading; it points out that there is no telemetry that allows tenant admins to
see which users are using basic authentication, so there’s a risk that you might accidentally shut off

access for some clients if you disable basic authentication indiscriminately. The documentation on

how to apply authentication policies to enforce this change is mandatory reading if you’re even

thinking about making this change.

Modern Authentication

Modern Authentication (also known as ADAL authentication) uses the Active Directory

Authentication Library (ADAL) to enable improved authentication for a variety of clients, including

Office 2013 (with the latest updates), Office 2016, Office for iOS and Android, the Outlook mobile

application, and the Teams and Skype for Business clients. Modern Authentication is based on the use

of OAuth 2.0, an authentication protocol first used by Microsoft for server-to-server authentication

for Exchange and Lync integration but quickly adopted for client authentication as well. Modern

Authentication allows enabled clients to take advantage of the following:

SAML-based sign-in with third-party multi-factor authentication providers for Office 365.

Smart card-based authentication.

True multi-factor authentication.

SSO across apps through token sharing (for example, the Office 2016 desktop apps).
1.The Outlook desktop client connects to Exchange Online and is redirected
to Azure AD for authentication.
2. The client connects to the Azure AD authentication endpoint and is
prompted for credentials.
Because modern authentication is enabled, the client displays the forms-
based modern authentication credential dialog.
3. After the user submits their credentials, Azure AD first verifies the identity
type of the user. It does so by looking at the domain portion of the User
Principal Name and verifying what type it is.
1.If the user is federated, the client is redirected to the on-premises identity
solution using an HTTP 302 redirect. Depending on what client the user is
connecting with and how the endpoint is configured, the user might need to
enter additional credentials. By default, the client automatically passes the
logged in credentials of the user to the endpoint. If those credentials do not
work, the user is prompted for credentials by the federation server.
2. If the user's password is managed in Azure AD (cloud-only identity, or
using password hash synchronization), the username/password combination
is verified by Azure AD itself.
3. If pass-through authentication is enabled, the user's request is passed on to
the on-premises Active Directory through dedicated Azure App Proxies
(Azure AD Connect).
4. When the credentials are successfully validated, one of the following
happens:
1. the application receives a SAML token (from the AD FS server) and is
then redirected to Azure
AD where the user receives a JSON web token (access and refresh token)
instead.
2. if multi-factor authentication is enabled, the user is first requested to enter
additional
verification after which (if successfully validated) the tokens are created and
returned.
5. The client is now redirected to the service it initially connected with (for
example, Exchange
Online). Using the access token previously received from Azure AD, the
client can now access the online resource.
access token and a refresh token. The access token is short-lived, meaning it has a limited lifespan; 1
hour by default, and is used to authenticate to Office 365 (Azure AD). The refresh token, which can
remain valid indefinitely, is used to request new access tokens when they expire. With a valid refresh
token, the user does not have to re-authenticate. Instead, the refresh token is used to obtain a new
access token from Azure AD

The way Modern Authentication works in an on-premises organization is very similar to how it does

in Azure AD and Office 365. However, instead of being a native capability, the on-premises

Exchange Servers will pass authentication requests to Azure AD and use the OAuth tokens. Azure AD

returns instead of using the native Exchange on-premises mechanisms. In effect, when a user attempts

to connect to Exchange, they will be redirected to Azure AD to authenticate there. Depending on the

configuration of Azure AD, the user will authenticate using one of the available options like

password hash synchronization, pass-through authentication, or even an on-premises redirection to an

AD FS server farm. Once a user is successfully authenticated, they will receive access and refresh tokens
from Azure AD which can then be used to authenticate to Exchange on-premises.

Multifactor authentication

it is surprising to learn that the maximum password length in Azure Active Directory, and thus Office
365, is only 16 characters. To enable the baseline policy, you’ll need to go to the Azure Active Directory
section of the Azure portal. In the Security section of the left navigation rail, select Conditional access
and you’ll see the list of existing conditional access policies in your tenant. The current baseline policy is
called “Baseline policy: Require MFA for admins (Preview).” To enable it, just click the policy and chose

the Use policy immediately option. That will immediately force the use of MFA for any account that
has one of the supported admin roles (global, SharePoint, Exchange, conditional access, and security

administrators are included). The policy will take effect immediately, and overrides the MFA setting

you may have applied to the accounts individually.

Pass-Through Authentication (PTA)

Pass-through authentication, if enabled, allows you to offload the authentication from Azure AD to

your on-premises Active Directory without the need to deploy AD FS or a third-party federation

solution. As such, it can greatly simplify your deployment if you are seeking to keep control of the

actual authentication process. you must install and configure one (or more) on-premises connectors to

communicate with Azure AD to validate user authentication requests. The connectors can be installed

as part of Azure AD Connect and are very similar to Azure App Proxies. In fact, they share the same

architecture; the PTA connector is a customized version of the Azure App Proxy connector.

From a high-level perspective, here are the steps an authentication request goes through when PTA is

enabled:

1. The client connects to an Office 365 service endpoint and is redirected to Azure AD for

authentication.

2. The client connects to the Azure AD authentication endpoint and is prompted for credentials. If

Modern Authentication is enabled, the client displays the forms-based Modern Authentication

credential dialog.

3. After the user submits their credentials, and assuming PTA is enabled, Azure AD encrypts the

Credential data and holds the authentication request in a virtual queue for validation.

4. The on-premises connector (which is part of the PTA deployment) makes an outbound

connection to Azure AD and retrieves the authentication request.

5. The connector decrypts the data from the request and validates the decrypted credentials against

the on-premises Active Directory. The result of this verification process is then communicated

back to Azure AD.

6. If the credentials were verified successfully, a token is issued, or the multi-factor authentication

flow is started.