You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
Office 365 sign-in
Office 365 Community
FastTrack: Office 365 deployment resources
Ignite: Office 365 admin training resources
Office 365 TechCenter
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
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.
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.
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:
If you need any of these then
Active Directory Federation Services is still the best option.
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.
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.
See Works with
Office 365 - Identity program on TechNet.
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.
See Use Shibboleth
Identity Provider to implement single sign-on on TechNet.
Azure AD also supports
programmatic directory access using PowerShell.
See Manage Azure AD
using PowerShell on TechNet.
Azure AD Graph provides access to
AD Graph Overview on MSDN.
Using these two tools custom
solutions can be built to synchronize user identities with Azure AD for use
with Office 365.
Please review these links for
more resources for synchronizing and federating identity providers with Office
documentation for Directory Sync and Password Sync.
Sync Feature Announcement Blog Post.
Tool Version History.
for Password Sync on DirSync.
Forum for Directory Sync Questions.
-- Paul Andrew, @pndrw
Very Good. I really like of Office 365.
June and July have been busy months for the Office 365 and related teams. On the mobile apps front, we
La gestion de l’identité avec Windows Intune est un sujet important qui nécessite clarification. En effet