Paul Andrew is a Technical Product Manager on the Office 365 team working
on identity and commerce.
Office 365 uses Windows Azure
Active Directory (Azure AD) for managing user login and storing user profiles. The
Directory Sync tool (DirSync) is provided to synchronize user profiles between
on-premises Active Directory implementations and Azure AD in the cloud. This
means all of the same user profiles from the on-premises Active Directory will
be available in Office 365.
Recently, a new version of
DirSync was released that includes synchronization of user password hashes.
This avoids the need for users having separate passwords for on-premises login
and cloud based login. Prior to this, having the same password required
deployment of identity federation servers which is a more significant
implementation project. The password hash which is synchronized to the cloud is
a one way mathematical computation based on the users password which is not
reversible to discover the users plaintext password. Synchronizing the password
hash means the user can log into Office 365 using their on-premises password.
This blog post describes
directory synchronization and password hash synchronization in the context of
User Identity in the Cloud
For a moment let me take you back
to a time before cloud computing and SAAS applications. Back when software
predominantly ran on PCs connected to networks with Active Directory as the
identity provider. When you ran software on a PC in this environment you are
already logged onto the PC. When the software needs to look up your name or do
some other kind of personalization it just asks the PC who you are using API
calls. There isn’t any additional login required to run new applications as all
applications share the same identity provider (Active Directory).
SAAS applications are a little
different. They are not installed on the local machine and they do not get
access to the local Active Directory domain controller. Because of this, SAAS
applications often use disjoint identity providers. As a result users will have
to maintain separate usernames and passwords across multiple cloud based
applications. Single Sign-On (SSO) is the common answer to resolving this. SSO is
defined as the ability for two disjoint identity providers (IDP) to trust one
another so that as a user, you log in once against your IDP, and then when you
try to access resources secured by the second IDP, you don’t need to login
again. This trust relationship is called federation. SSO is implemented using
federation and provides the same benefit to users as when all software used to
run on your PC and it inherently knew who is logged in.
Directory synchronization does
not provide SSO because a user logged in on-premises will still have to log in
separately to Office 365. But synchronization does provide that the username
will be the same, and now with password hash synchronization also that the
password will be the same. Since directory synchronization is much simpler to
configure than SSO the benefit of having password hash synchronization makes
this a great choice for many customer scenarios.
This diagram shows the three main identity
provider options you can choose for Office 365.
Office 365 Cloud Identity
The simplest way that Office 365
provides for user authentication is with a Cloud Identity. This is provided for
where your organization wants a new user directory with new usernames and
passwords. This may be the case for a new organization, or a small organization
that doesn’t have an existing dedicated on-premises directory. Using the Cloud
Identity model means that users are not associated with any on-premises
identity provider. They are instead fully managed in the cloud and the users
will manage their own passwords in the cloud.
Under the covers Office 365 will
actually create a new instance of the user in Azure AD. Azure AD has
always been the user directory behind Office 365. Just like your on-premises
Active Directory stores user accounts for Exchange, SharePoint, Lync and your
custom LOB Apps, Azure AD stores the information for Exchange Online,
SharePoint Online, Lync Online and any custom applications you build in the cloud.
All administration of Azure AD for Office 365 customers can be done through the
standard Office 365 admin portal. Although Azure AD has been used for some time
by Office 365, it
was also made available for other web based applications in July 2012.
Directory Synchronization is used
when you have an existing on-premises Windows Active Directory infrastructure
and you want those same users to have access to Office 365. After installing
the DirSync tool on a member server in your domain it will periodically
synchronize user profiles to Office 365 where synchronization is based on the
user objects Source Anchor attribute. Directory synchronization avoids any need
to manually create users into the cloud directory. Furthermore, it avoids the
need to create yet another username and password. With the advent of password
hash synchronization, it eliminates the need for users to manage passwords in
two places. Note that if password hash synchronization is not enabled each user
would be required to create a new password in the cloud.
Office 365 admin center showing the
users and groups page where you can configure Directory Synchronization.
Deploying DirSync is pretty
straight forward. From the Office 365 admin center, select “Active Directory
synchronization” to go through the six step process. The process is detailed in
in the Office 365 admin center and includes the following steps:
for directory synchronization
Active Directory synchronization
and configure the Directory Sync tool
There is a little preparatory
work and then you download and install the DirSync tool on a Windows Server
that has connectivity to your Active Directory domain controllers. The actual download
link for DirSync is contained within the six step process in the Office 365
admin portal. DirSync installs with a simple wizard installer and then is ready
to go. It will run periodically on the server that it is installed on and
synchronize user accounts (and other directory data) for you to Azure AD. It
will synchronize user objects every three hours and password changes will be
synchronized every two minutes. An Office 365 tenant can have a mix of cloud
identities described above and synchronized identities from Active Directory
With a few exceptions, all of the
data is synchronized one way only from on-premises to the cloud. This means
that a user identity is either managed in the cloud or it is managed
on-premises but not both. Users who are managed on-premises can only be edited
on-premises and this includes the ability of the user to change their password.
A synchronized user would either need to go to their office, or connect over a
VPN to their corporate network in order to change their password.
You can select which users are
synchronized to Office 365 but you cannot select specific user attributes from
the user profile as all are required.
The new password
hash sync feature takes the one way hash result of your user passwords, applies
additional security processing and synchronizes the result to Azure AD. The
actual plaintext password is never sent to Azure AD. Prior to this release, the
DirSync tool would not synchronize password hashes and users would need to
enter a separate password for Office 365 to their on premises use. This new password
hash sync feature is not the same as Microsoft Password Change Notification Service
- Password Hash Sync is newer and more secure.
shows the new screen added to the DirSync installation wizard to enable
password hash synchronization.
There is only
one configuration option to add password hash sync to the DirSync tool. This is
done during the configuration wizard and is a checkbox where you choose to sync
password hashes in addition to the users profile attributes. If enabled,
password hash sync applies to all synchronized users.
Directory federation means that
Azure AD (and therefore Office 365) is federated with another directory – it
trusts that other directory to handle user authentication requests. Simply put,
this means that all login attempts are managed by the federated directory, and
Office 365 does not see the password. The login form where you enter your
password is actually part of the federated identity provider. Office 365 is
known as the Relying Party (RP) in this case because it relies on the federated
directory for authentication checks. Once the user authentication is
successful, proof is provided by the federated directory in the form of a
digital signature is provided to Office 365 that the user is authenticated.
Federation on Office 365 is
commonly done with on-premises Windows Active Directory using Active Directory
Federation Services (ADFS). ADFS is implemented with additional servers that
are deployed both inside the corporate directory and in the organization’s Internet-facing
network or demilitarized zone. Directory synchronization is a required
pre-requisite for directory federation since federation relies on Azure AD
knowing that the user exists in the on-premises directory in the first place. Federation
is used exclusively for authentication and authorization flows. Address book functionality,
such as lookups when a user is looking for a recipient to send an email to, do
not use federation.
Federation is also configured by
walking through a step-by-step guide in the Office 365 admin portal.
Avoiding Federation Now That Password Hash Sync Is
A key driver for federation
deployments with ADFS used to be that it enables users to use a single password
across on-premises and cloud sessions. However, federation deployments take
some effort due to the additional servers and network implementation. The
on-premises servers also have to be Internet accessible through any corporate
firewalls in a secure way, and they also have to be highly available since
logins are not possible if they or their Internet connectivity are offline.
Because password hash sync is a
feature of directory synchronization, it is initiated from the on-premises
server and doesn’t incur many of the infrastructure requirements and costs of federation.
It only requires a single server and whilst that server requires outgoing
access to the Internet in order to connect to Azure AD there is no requirement
for inbound connections, custom firewall openings or highly available configurations.
There are still some reasons why
some customers will still prefer ADFS and directory federation over DirSync and
password hash synchronization. These include:
ADFS can be configured such that users who are
already logged on to a domain joined and connected machine do not require any
password re-entry to sign in at Office 365. This gives you true single sign-on
since re-entry of the password is not required. With DirSync and password hash
synchronization a user must still re-enter their password, although it will be the
same password as they use on-premises.
ADFS allows for client access filtering, which
restricts access to Exchange Online to users based on their IP address.
ADFS will honor Active Directory configured login
time restrictions for users.
ADFS can include web pages for users to change
their passwords while they are outside the corporate network.
With ADFS the authentication decision is always
made on-premises and no password hashes are synchronized to the cloud. This may
be obvious but can be sometimes a security policy requirement.
With ADFS an administrator can immediate block a
user to remove access where-as DirSync synchronizes these changes every three
hours. Only password changes are synchronized by DirSync every two minutes.
ADFS permits use of on-premises deployed multi-factor
authentication products. Note that Azure AD supports multi-factor
authentication but many third party multi-factor authentication products
require on-premises integration.
Where Microsoft Forefront Identity Manger (FIM)
is required for some other FIM capability. FIM directory synchronization does
not include password hash synchronization so ADFS will still be required for
Some on-premises to cloud hybrid scenarios
require ADFS such as hybrid search.
If you need any of these then
Active Directory Federation Services is still the best option.
Other Directory Integration Options with Office
Microsoft Forefront Identity Manager
Forefront Identity Manager is a
more comprehensive identity management solution from Microsoft. It can also be
used to synchronize user profiles from Active Directory to Azure AD for use by
Office 365 when the customer has more than one Active Directory forest, or has
a non-Active Directory service on-premises.
This uses the FIM Connector for Office 365 which currently does not
include support for password hash synchronization.
For identity federation purposes
ADFS can still be used in a configuration with Forefront Identity Manager and
this enables users to have a single password across the corporate network and
Office 365. This provides for single sign on.
Both DirSync and Forefront
Identity Manager require Microsoft Active Directory.
Third-party WS-* Based Identity Providers
WS-* includes WS-Federation for
passive authentication from Office 365 web properties and also WS-Trust for
active authentication from Office rich client applications accessing Office
365. Active authentication is required by rich client applications to access
Office 365 and for Office 365 ProPlus licensing. Office 365 ProPlus is included
with some Office 365 SKUs and it includes Office rich client applications such
as Word, Excel, PowerPoint, Outlook and Lync. The connectivity required for
licensing these products is active authentication and relies on WS-Trust.
Microsoft has a program called Works with Office 365 – Identity which
qualifies third party WS-* based identity providers for use with Office 365.
You may have an existing identity provider that is part of the Works with Office 365 – Identity
program. Some of these providers support both WS-Federation and WS-Trust and
some only support WS-Federation for only passive web based authentication.
Third-party Shibboleth Based Identity Providers
Shibboleth is an identity
provider that has significant usage in academic circles. Shibboleth is
supported by Azure AD and there is a guide on TechNet for implementing it for
use with Office 365.
Other Identity Providers and Custom Solutions
Azure AD also supports
programmatic directory access using PowerShell.
Azure AD Graph provides access to
Using these two tools custom
solutions can be built to synchronize user identities with Azure AD for use
with Office 365.
Resources for Directory and Password Hash
Please review these links for
more resources for synchronizing and federating identity providers with Office
– Paul Andrew, @pndrw