Password hash sync simplifies user management for Office 365

www.office.com/setup Blogs: 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 Office 365.

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.

www.office.com/setup

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

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.

www.office.com/setup

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:

Prepare for directory synchronization
Verify domains
Activate Active Directory synchronization
Install and configure the Directory Sync tool
Verify directory synchronization
Activate synchronized users

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 on-premises.

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.

This screenshot shows the new screen added to the DirSync installation wizard to enable password hash synchronization.

www.office.com/setup

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

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 Available

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 SSO login.
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 365

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.

See Works with Office 365 – Identity program on TechNet.

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.

See Use Shibboleth Identity Provider to implement single sign-on on TechNet.