Chapter 3. Hybrid identity
Windows Server Active Directory and Forefront Identity Manager (FIM) have long been the standard for on-premises identity management, but in a mobile-first, cloud-first world, the concept of user identity must be expanded to include identity for cloud-based applications and management spanning multiple services. The Microsoft hybrid identity solution spans on-premises and cloud-based capabilities to create a single user identity for authentication and authorization regardless of where the user is. By easily extending your local directories into Microsoft Azure Active Directory (Azure AD) through directory synchronization, hybrid identity provides users with one username and password to remember and enables authentication and self-service scenarios to keep users happy and productive while also protecting company information.
Everything starts with identity and it will be one of the foundations of your enterprise mobility strategy. Whether you are logging into your mobile device or your Software as a Service (SaaS) app, your identity is the key to gaining access to everything. This chapter discusses how Azure AD works with your on-premises Active Directory to provide a comprehensive identity and access management hybrid identity solution as part of the Enterprise Mobility Suite. In this chapter, you will learn about the various aspects and capabilities of Azure AD Premium that support hybrid identity and the tools used to synchronize on-premises directories with the cloud in preparation for the implementation guidance you will learn in Chapter 4.
Cloud identity with Azure AD Premium
Chances are that you are already familiar with Windows Server Active Directory and how it is used to provide identity management. That being the case, you might think that Azure AD is the cloud-version of the on-premises solution that has become the bedrock for so many enterprises, but Azure AD is really much more than a domain controller in the sky. In addition to providing identity management, Azure AD is also a complete access management cloud solution. Azure AD handles identity governance, manages access to applications, and also provides a standards-based platform for developers to build their own applications without having to worry about how identity will be factored in because Azure AD will handle that for them. Enterprise businesses today require a solution that can verify a user’s identity across multiple devices to give them access to apps and resources in a consistent manner. That solution is cloud identity with Azure AD Premium.
Azure AD Premium is included with the Enterprise Mobility Suite and, in addition to the rich features supported by Azure Active Directory Free and Azure Active Directory Basic editions,1 it enables bonus advanced features to your directory that help empower enterprises with more demanding identity and access management requirements. When you use Azure AD Premium, you can perform write-back of object attributes from Azure AD to your on-premises directories as well as do things like view advanced security reports and alerts, enable multi-factor authentication, and provide self-service group and password reset management.
1 You can learn more about the different versions of Azure AD at http://azure.microsoft.com/en-us/pricing/details/active-directory/.
Azure AD Premium advanced security reports and alerts
Azure AD Premium access and usage reports2 are based on machine learning and allow you to easily monitor and protect access to your Azure AD tenant resources. Using these reports, you can view information that will help to secure your organization’s Azure AD directory. The data collected and displayed by Azure AD Premium Reports can be used to better determine where possible security risks might be present so that they can be addressed and mitigated. In addition, there are other reports that provide analytics on device access and application usage so that you can better manage resources.
2 You can learn more about Azure AD Premium access and usage reports at http://msdn.microsoft.com/en-us/library/azure/dn283934.aspx.
To view the reports available for you to run, simply go to the Reports tab of your Azure AD directory as shown in Figure 3-1. To run a report, just click the report name in the list and you will see a detailed page for that specific report. In addition to viewing the report, you can also download a copy of it as a compressed, Comma Separated Values (CSV) format for offline viewing or backup purposes.
Tip
If you see a section called Premium Reports at the bottom of the Reports tab for your directory containing reports, the account you are logged in as has not been granted an Azure AD Premium license.
The remainder of this section describes the premium reports that are currently available for you to use in managing your Azure AD objects and resources in addition to those available by default.
Anomalous activity reports
Azure AD Premium anomaly reports alert you to suspicious sign-in behaviors and include the following reports:
Sign ins from IP addresses with suspicious activity This report can be used to find a successful sign-in after a sustained intrusion attempt.
Sign ins from possibly infected devices This report indicates an attempt to sign in from possibly infected devices.
Irregular sign in activity This report shows events that might indicate anomalous patterns in user signs.
Users with anomalous sign in activity This report shows information about user accounts that might have been compromised.
Tip
You can scope the interval to the last twenty-four hours, seven days, or thirty days for all of the above Azure AD Premium Reports.
Activity logs
These Azure AD Premium reports provide activity logs about audited events that can be scoped to a specific number of days and include:
Password reset activity This report provides a detailed view of password resets that occur in your organization.
Password reset registration activity This report provides a detailed view of password reset registration activities that occur in your organization.
Groups activity This report provides an activity log to view all group related activity occurring in your Azure AD directory.
Tip
These reports can be scoped to a certain date range by using the provided date picker for both the start and end dates that you are interested in.
Integrated applications
These Azure AD Premium reports provide details about how cloud applications are being used and include:
Application usage This report provides a usage summary for all SaaS applications that have been integrated with your Azure AD directory.
Tip
You can scope the interval for this report to the last twenty-four hours, seven days, or thirty days.
Azure Multi-Factor Authentication
Azure Multi-Factor Authentication capabilities are also included with Azure AD Premium and can help you secure access to your data and applications both in the cloud and on-premises applications made available for Azure AD authentication through VPN, RADIUS, and other forms of authentication. Multi-Factor Authentication (MFA), sometimes referred to as two-factor authentication, is a security best practice that requires that you identify yourself with more than just a password to access resources.
You can use MFA for all of your users to enforce stronger security measures or apply MFA policies to only selected users. For example, if you are unsure if a user account has been compromised, or if you think a user might be acting suspiciously, you can use Azure Multi-Factor Authentication to require that account to take additional verification steps that are beyond just entering a password. Azure Multi-Factor Authentication can request additional forms of verification through a mobile phone call, a mobile phone text message, or an office phone call. Alternatively, you could also provide a one-time password or use a push notification to a mobile device app to enable supplementary identity verification before allowing access to your apps and resources. Once you verify that the account has not been compromised, you can always easily disable MFA for the account.
The mobile device app helps secure access by providing an MFA option for verifying account sign-ins. The app, formerly named PhoneFactor, is now named Multi-Factor Auth in the Microsoft Store and Multi-Factor Authentication in the Google Play and Apple App stores. It can be downloaded and installed for free. Once installed, the Multi-Factor Auth app will notify you of a pending verification request by pushing an alert to your mobile device. When you receive the alert, you just need to view the request and then verify or cancel the MFA request. You could also be prompted by an application you are accessing to enter a passcode received by the Multi-Factor Auth app.
Getting the right Azure Multi-Factor Authentication app for your device
To use Azure Multi-Factor Authentication, simply install the free app on your mobile device. Be sure that the application you install includes the logo shown in Figure 3-2; those apps are the only ones supported for Azure Multi-Factor Authentication.
You can use one of the following links to get the appropriate app for your device type:
Windows Phone http://www.windowsphone.com/en-us/store/app/phonefactor/0a9691de-c0a1-44ee-ab96-6807f8322bd1
Android https://play.google.com/store/apps/details?id=com.phonefactor.phonefactor
iOS https://itunes.apple.com/us/app/phonefactor/id475844606?mt=8
After you install the app, you will receive instructions, which contain either an activation code and URL or a QR code, from the company that has enabled MFA for your account. Enter this information into the app or scan the QR code. You can activate multiple companies and accounts.
Important
The Multi-Factor Auth app requires connectivity to an active Azure Multi-Factor Authentication service and will not work without it.
User self-service from the Azure Access Panel
Users can easily access these self-service features as well as published applications from the Microsoft Azure Access Panel3. These Azure AD Premium features allow you to empower your end-users to be productive and get things done without having to call the helpdesk or becoming ensnared in time-consuming processes. There are several advantages to enabling self-service features made possible by Azure AD Premium, including:
3 The Azure Access Panel is available at https://myapps.microsoft.com.
Your users can get access to published SaaS applications integrated with your Azure AD.
Users can change and reset their own passwords or update their profiles to add missing information or to correct errors.
IT can easily assign groups to SaaS apps to grant access and users can create and manage their own groups from the Azure Access Panel. From there, group owners can easily access and manage group membership requests.
Tip
By using the Configure tab for your directory in the Azure Account portal4, you can customize the Access Panel to brand it with your company logo, pictures, and color schemes to provide a consistent look and feel for your organization across websites and services.
4 You can learn more about applying company branding to the Azure Access Panel page at http://msdn.microsoft.com/library/azure/dn532270.aspx#bkmk_customizable.
SaaS application availability
Your users can access SaaS applications that you integrate with Azure AD simply and quickly just by logging in to the Azure Access Panel. You can publish applications that you develop yourself or simply add an application from the gallery. Currently there are more than 3,000 SaaS applications available from within the Azure application gallery to integrate with your Azure AD domain.
Once you integrate a SaaS application with your directory, you can control access to the app using self-service group management. You can do that by assigning one or more security groups to manage access from the application properties on the Users And Groups tab of the application properties, as shown in Figure 3-3.
FIGURE 3-3 Controlling access to SaaS apps by assigning one or more security groups in the application properties
To make it even easier to use SaaS applications, when you integrate them with your Azure AD, you have the option of allowing all group members to authenticate to the SaaS application from within the Access Panel using stored credentials. This can be useful if you have a centralized SaaS app account used by more than one person in the organization, such as a company Facebook or Twitter account. Alternatively, you can enable Single Sign-On (SSO) for apps in order to require users to authenticate using their organizational credentials. If you are curious if a particular app is used often, you can easily see usage reports on the Dashboard tab of the application properties.
As you will learn in the next chapter, SaaS apps that support federation with Azure AD, such as Google Apps, Box, Office 365 and others, can be signed in to from the Access Panel using just about any web browser that supports JavaScript and cascading style sheets without requiring a web browser plug-in or mobile app. However, for users to sign in to apps that are configured to use password-based SSO, an Access Panel web browser extension is required to be installed and enabled. The extension is downloaded automatically when a user tries to access an application that is configured for password-based SSO.5 To access password-based SSO apps using iOS or Android devices, users need to install the My Apps mobile app published by the Azure AD team and made available in both the Google Play store and the Apple App store.6
5 The Access Panel web browser extension is currently supported on IE 8 and later, Chrome, and Firefox browsers.
6 The My Apps mobile app is currently supported on Android 4.1 and up and iOS 7 and up on iPad and iPhone.
Self-service group management
It is easy for users to create and manage security groups that enable access to SaaS applications integrated with Azure AD. Requests to join groups can either be auto-approved or they can require the owner of the group to approve or deny the request. This saves you a lot of time and hassle because you no longer need to manually administer user-access rights to every SaaS application in use.
For example, if you want to assign access for the marketing department to use one or more specific SaaS applications, you can use the Access Panel to simply create a security group to contain the marketing department users and then assign that group to the SaaS applications used by marketing that have been integrated into your Azure AD. You can then set the group to require owner approval for joining so that when other users want access to the marketing SaaS apps, the owner of the group has to approve their requests, as shown in Figure 3-4.
FIGURE 3-4 The security group membership request Approvals user interface in the Azure Access Panel as seen by the group owner
By managing access to the SaaS applications used by the marketing department this way, you save time and users get access to the apps they need to get their jobs done more quickly. When a user is added to the group, that user immediately receives the apps assigned to the security group; those apps are automatically removed from the user’s list of applications in the Access Panel when the user leaves the Marketing group.
Tip
Do you think you don’t have any SaaS applications to manage in your enterprise? Run the Azure AD Cloud App Discovery (http://appdiscovery.azure.com/) and find out. Most enterprises discover many more SaaS applications in use than they would have guessed.
Self-service password management
In addition to applications and group management, your users can also use the Azure Access Panel to manage their profile information and passwords themselves as shown in Figure 3-5.
The self-service change password functionality allows your users to simply log on to the Access Panel to change their passwords without needing to call the helpdesk. If a user cannot remember his password, then he can also use password reset to obtain a new password. Changing a password is a very simple process, but before users can reset their passwords, they must first have at least one multifactor authentication method defined from the following options: office phone, mobile phone, or alternate email address.
The ability to reset and change user passwords is enabled by default for user accounts created in Azure, but to enable passwords to be changed for user accounts synchronized to your Azure AD from on-premises Active Directory, you must enable the Password Write Back option when configuring directory synchronization. This option provides a cloud-based option for your users to reset their on-premises passwords wherever they are located while still enforcing on-premises password complexity rules and without opening any inbound firewall ports.
Understanding directory integration
Of course, before you can use Azure AD Premium features that depend on user cloud identities for authentication, you need to have some users in your Azure AD! Accordingly, directory integration is really all about creating an identity bridge between on-premises and Azure AD to manage identities, users, and groups, as well as manage access to applications though a central Azure AD management console. Most enterprises have made a significant investment in their on-premises Active Directory and do not want to have to manually re-create every single user and group object in Azure AD. By integrating your on-premises Active Directory with Azure AD, you can extend identity to the cloud and leverage all the hard work you’ve done to manage your users, groups, and on-premises resource access controls.
Tip
The centralized identity management and access solution created by combining on-premises Active Directory and the cloud-based Azure AD is the key to enabling your users to work anywhere from any device.
Synchronizing your on-premises Active Directory objects with Azure AD enables users to sign in to cloud-based services using a single identity based on the same usernames and passwords they already use to access local resources on-premises. Taking it a step further, you can federate an on-premises domain with the custom domain that is registered and verified for use with the Azure AD to enable true SSO. Using that single identity, you can then centrally manage access to Microsoft Online Services such as Azure, Office 365, Dynamics CRM Online, Microsoft Intune, and many other Microsoft and non-Microsoft cloud applications.
The remainder of this section describes several key aspects of directory integration that you should understand and consider before implementing your own plans for on-premises to Azure AD integration. This will help you decide whether or not you want to synchronize your directories, federate your domains, or both.
Source of authority
When you create users or other objects in Azure AD by using either a Windows PowerShell cmdlet or account portal tools such as the Microsoft Intune or Office 365 admin portals, those objects are considered “mastered” in the cloud. Because these mastered objects were created in the cloud, they can only be modified via cloud-based directory tools. This is referred to as the source of authority and there can only be one source of authority for each object in Azure AD to prevent data loss. So, in the example just given, the cloud-based directory would be authoritative over those objects for future changes.
Once you activate and start synchronizing your on-premises Active Directory information to Azure AD, the source of authority will be transferred to the on-premises Active Directory immediately after the first sync cycle completes. When that change is complete, the Azure AD user and group objects belonging to your on-premises domain will become read-only in the Azure AD management portal. That being the case, after the source of authority has changed to your local Active Directory, you will be powerless to modify them from the Azure portal and you must create or modify users using your on-premises tools if you want them synchronized with Azure AD. This change has no effect on objects that were created in the cloud because they are not linked to objects in your on-premises Active Directory.
Important
After the first successful directory synchronization, you can only update synchronized directory objects stored in the cloud from your on-premises environment.
Directory synchronization
An easy way to understand how directory synchronization works is shown in Figure 3-6, where you can think of it as a kind of simple extension cord linking your on-premises users to the cloud and “lighting up” cloud-based services and application identity and access management scenarios.
The goal of directory synchronization is to create a single identity for each user that identifies them both on-premises and in the cloud. This identity synchronization is accomplished by linking what is basically a copy of your on-premises Active Directory user and group accounts in Azure AD. Once activated, directory synchronization occurs on a regular schedule about every three hours and is meant to ensure that any ongoing changes occurring in your on-premises directories are accurate and automatically reflected in Azure AD. The automated process helps to reduce administrative costs by leveraging your existing on-premises user and group accounts so that you do not have to manually re-create them in Azure AD. It also reduces the amount of time necessary to enable access to cloud-based services for your users and increases security to shared resources and apps by automatically keeping synchronized group memberships updated.
Tip
Directory synchronization also allows global address list (GAL) synchronization if you want to integrate an on-premises Microsoft Exchange Server environment with Microsoft Exchange Online.
Directory synchronization can be turned on and off as needed and here are three ways to do it that from your Azure AD’s Directory Integration tab in the Azure portal:
Activate Activating directory synchronization from the Microsoft Azure account portal is required to start the flow of on-premises object attributes to Azure AD. Remember that after the first synchronization is complete, the source of authority for everything stored in the cloud that corresponds to something in the local Active Directory will be set to the on-premises directory.
Deactivate Deactivating directory synchronization from the Azure account portal stops the transfer of on-premises object attributes to Azure AD. When this happens, the source of authority is transferred from the on-premises directory to the cloud-based Azure AD. You should do this only when you no longer want or need to manage objects from on-premises.
Deactivating directory synchronization can take up to 72 hours or more, depending on how many objects have been synchronized with your Azure tenant that need to have their source of authority set to Azure AD instead of the local directory.
Reactivate If you change your mind and decide to return the source of authority for directory objects to on-premises, you can do that by reactivating directory synchronization. Be careful when doing this; reactivating directory synchronization in this manner could lead to data loss. For example, if objects have been created or modified in the cloud since they were last uploaded by the local directory sync, then those changes would immediately be lost because the synchronization process would instantaneously begin overwriting object data from on-premises back to the cloud.
When you synchronize your local on-premises Active Directory objects and their associated password hashes with Azure AD, you enable your users to be authenticated by Azure AD using their on-premises credentials. The basic architecture behind directory synchronization is shown in Figure 3-7. It shows the one-way transfer of object data from the on-premises Active Directory through the directory sync tool and to the Azure AD directory with directory sync activated. In this configuration, your on-premises objects and attributes will be synchronized and made available for identity and resource access management in the cloud.
Active Directory Federation Services
As you have seen, you do not necessarily have to federate domains in order to enable your users to authenticate in to Azure AD with the same usernames and passwords that they use on-premises. There are certainly situations in which directory sync capabilities alone will meet your organizational needs, but eventually you will need more than just basic authentication enabled by directory synchronization. Extending your authentication capabilities to provide a single, federated identity for each user enables you to better deliver a seamless user experience through Active Directory Federation Services (AD FS) and SSO.
Figure 3-8 shows the more complex identity and authentication scenario involving SSO via AD FS to enable on-premises authentication. Notice that you must still use identity synchronization tools to populate your Azure AD with on-premises objects, but now authentication to cloud-based services is handled by your on-premises Windows Server Active Directory rather than Azure AD.
FIGURE 3-8 Synchronizing on-premises Active Directory with Azure AD to enable SSO using on-premises authentication enabled by AD FS
Before you begin using SSO, you will need to add your organization’s public domain name to your Azure AD instance and then verify it for directory integration in the Azure management portal. When that is completed, you will need to prepare your on-premises domain to configure certain settings to work properly with SSO. In particular, the user principal name (UPN), also known as a user logon name, must be set up in a specific way for each user to match the domain that you have added and verified in Azure AD for directory synchronization.
The following are important points to consider when preparing your on-premises Active Directory for directory synchronization with Azure AD:
The domain you choose to federate must be registered as a public domain.
The UPN added to users to be synchronized with Azure AD and for SSO can only contain letters, numbers, periods, dashes, and underscores.
The UPN domain suffix must be added under the domain that you choose to set up for SSO and known by your users.
Directory integration scenarios
Now that you understand how directory integration works, you are ready to learn more about the various synchronization options available to you by using the different identity synchronization tools that are available.
Depending on your organization’s needs and policies, directory synchronization can be done a few different ways. Starting simple, you can go from a basic synchronization of user and group attributes only (without passwords) all the way to synchronizing on-premises objects and password hashes from multiple forests to Azure AD.
Directory sync
This is the simplest form of directory synchronization in that while you are synchronizing on-premises Active Directory user information and attributes to Azure AD, you choose not to synchronize user passwords. In this scenario, administrators can manage on-premises directory objects and those changes will synchronize with Azure AD on a regular schedule. While this does alleviate the administrator overhead required when creating accounts in Azure AD, and it will enable users to log in with familiar usernames, their passwords will be different when accessing cloud and on-premises resources.
Directory sync with password sync
Next in complexity is the addition of user-password hashes to the information synchronized from your on-premises environment to the cloud. This allows your users to sign in to Azure AD and other cloud services (such as Office 365 or Microsoft Intune) using the same user names and passwords that they use on-premises. This means that user authentication can occur in both locations and that the passwords are always the same as long as the synchronization of on-premises data occurs on schedule. Having the same password in both locations provides same sign-on for users because they can now use the same usernames and passwords when authenticating to both on-premises and cloud-based resources and applications.
When using password sync7, the plain-text version of a user’s password is not synchronized to Azure AD or any other cloud service. Instead, the user password information that is synchronized from the on-premises Active Directory is the stored hash value representations of the actual user passwords. The password hash synchronized to Azure AD cannot be used to log in to on-premises networks and it also cannot be reversed in an effort to discover the user’s plaintext password.
7 You can read more about password synchronization at http://msdn.microsoft.com/en-us/library/azure/dn246918.aspx.
Important
On-premises Active Directory directories that are configured for Federal Information Processing Standards (FIPS)8 are not compatible with password sync.
8 You can learn more about FIPS at http://www.nist.gov/itl/fipsinfo.cfm.
Directory sync with SSO
This synchronization method is used to provide users with seamless login experiences as they can access cloud services while logged on with their corporate network credentials. However, in order to set up SSO, you have to first deploy a security token service on-premises, such as AD FS. That on-premises service then authenticates users coming in from the cloud based on their on-premises identity attributes. Once set up, users can simply use their existing on-premises company sign-on information to access both the services in the cloud as well as their existing on-premises resources.
Multiforest directory sync with SSO
This is the most complex directory synchronization scenario. It is basically the same as the single directory sync with SSO scenario described previously except there are multiple on-premises directories configured to synchronize with Azure AD. Again, you have to deploy AD FS on-premises, but this is the best way to enable a seamless authentication experience from multiple forests with your cloud-based services and applications.
Directory synchronization tools
Once you have selected the synchronization strategy you want to implement, the next step is to choose the synchronization tool to use to get the job done. Several tools have been made available online from Microsoft to configure directory integration between your on-premises environment and Azure AD. The following three tools will be described, providing you with insight into how the tools evolved and clarifying any confusion about when to use each tool:
Azure Active Directory Sync (DirSync)
Azure Active Directory Synchronization Services (AAD Sync)
Azure AD Connect
Based solely on the names of the synchronization tools you can probably understand how a lot of people get confused about which one to use. When you add in AD FS and SSO, things really get complicated. Luckily, Microsoft has heard that feedback and made vast improvements based on it in each subsequent synchronization tool release as you will see in the remainder of this section.
Azure Active Directory Synchronization Tool
Previously known as the Microsoft Online Services Directory Synchronization tool, Azure Active Directory Synchronization Tool (DirSync) is the first as well as the oldest tool you will look at in this section. It’s so old, in fact, that it has basically been retired from active use and replaced by the Azure Active Directory Synchronization Services (AAD Sync) tool that will be covered next. However, for the sake of completeness and in an attempt to clarify the various directory sync tools available, it will be briefly touched on here. You can see the DirSync Welcome page in Figure 3-9.
Note
If you already have DirSync functioning in your environment and it is doing everything you need it to do, there is no need to change synchronization tools. However, if you want to change tools, your best bet is to simply uninstall it and then install Azure AD Connect on the DirSync computer.
DirSync is a very basic application meant to simply provide a one-way synchronization from an organization’s on-premises Active Directory to Azure AD on a schedule of about once every three hours. As is the case with all of the synchronization tools to be discussed, an administrator should install this tool and run it on only one computer in your organization’s local network.
When you install DirSync, a service account is created in your Active Directory forest named something like MSOL_AD_SYNC or AAD_xxxxxxxxxxxx (with the 12 x characters replaced with some alphanumeric string representing your specific installation). You should not move, remove, or re-permission this service account or you will most likely cause synchronization failures.
As compared to the other two directory synchronization tools to be discussed, DirSync has several limitations, including the following:
It can connect to only a single Active Directory forest (perhaps its most egregious limitation).
It doesn’t support the newer Azure AD Premium features, such as password change and password reset to Active Directory on-premises accounts.
It does not allow advanced object attribute filtering.
Again, DirSync is basically obsolete at this point, but you are probably sure to come across it if you are searching online for Active Directory synchronization information. Time to move on to the newer directory synchronization tools.
Azure Active Directory Synchronization Services
Azure Active Directory Synchronization Services (Azure AD Sync) is relatively new and includes some major improvements over its DirSync predecessor. It supports Azure AD Premium features and is a step up from DirSync for more advanced configurations. The Azure AD Sync Welcome page is shown in Figure 3-10.
This synchronization service allows you to do the following:
Synchronize single or multiforest Active Directory environments with Azure AD
Configure advanced provisioning, mapping and filtering rules for objects and attributes, including support for syncing a very minimal set of user attributes
Configure multiple on-premises Exchange organizations to map to a single AAD tenant.
In addition to synchronizing users and groups with Azure AD, Azure AD Sync also has optional features that allow you to enable enhanced functionality, as shown in Figure 3-11.
The optional features are as follows:
Exchange Hybrid Deployment Use this option when you need to support a unified email experience for a mix of users who have mailboxes with on-premises Exchange Server environments as well as users who have Exchange Online mailboxes. This feature of the Azure AD Sync tool enables users to find one another in the global address list (GAL) to send and receive emails regardless of which system is hosting their mailbox.
Password Synchronization Enable this feature to synchronize passwords from your on-premises Active Directory to Azure AD. When you enable password synchronization between your on-premises Active Directory and Azure AD, you need to grant the following permissions to the account that is used by Azure AD Sync to connect to your on-premises Active Directory to read password hash information: Replicating Directory Changes and Replicating Directory Changes All.
Password Write-Back Select this option to enable self-service functionality for users to reset their passwords from the Azure Access Panel. When this feature is enabled, Azure AD will synchronize the changes back to your on-premises Active Directory.
Azure AD App And Attribute Filtering This optional feature should be selected when you want to review or limit the attributes that are synchronized with Azure AD.
Just like DirSync, Azure AD Sync also configures directory sync to occur every three hours. However, there are ways to change the default schedule or to manually force a directory synchronization; these will be discussed in the next chapter. Directory synchronization is kept on schedule by a scheduled task running as the service account created when installing Azure AD Sync on the directory synchronization server computer. An initial synchronization task will be run at the end of Azure AD Sync installation unless you cleared the option to run the initial synchronization in the installation wizard.
Important
When you clear the check box for the option to synchronize changes during Azure AD Sync installation, the task will be installed as Disabled. After you configure the sync options according to your preferences, you need to Enable this scheduled task.
By default, the directory synchronization process will synchronize all of your on-premises users and groups to Azure AD. However, in most cases, you won’t want to synchronize every single object from your on-premises Active Directory to Azure AD. Instead, you can use one of the following options to configure Active Directory synchronization filtering9 to better scope the synchronization process to only what you need to be available in Azure AD:
9 You can learn more about Azure AD Sync filtering at http://msdn.microsoft.com/library/azure/dn801051.aspx.
Organizational unit Select which OUs are allowed to sync with the cloud
Domain name Define which OUs are allowed to sync with the cloud
User attributes Specify user attributes to control which user objects should not be synchronized with Azure AD
Tip
If you accidentally synchronize more than you wanted to from your local Active Directory to Azure AD, don’t worry. Just configure directory synchronization filtering and the objects that are filtered out from the next synchronization process will be removed from Azure AD.
Both of the directory synchronization tools that have been discussed thus far can be used to provision your Azure AD with on-premises user and group information, but neither will enable SSO or configure AD FS for you. If you are looking for a more complete directory synchronization tool that guides you through the complex configuration necessary to enable AD FS and SSO, then read on to discover the final—and recommended—directory synchronization tool that is used to complete the identity bridge from on-premises Active Directory to Azure AD.
Azure AD Connect
Making what used to be a very complicated and time consuming experience almost an afterthought because it is so easy now, the Microsoft Azure Active Directory Connect (AD Connect) Wizard provides a guided experience for integrating your on-premises Active Directory with Azure AD. It can be used to connect multiple Active Directory directories and forests, will optionally guide you through the steps necessary to configure AD FS for SSO, and even finishes by verifying that the integration is successful. The Asure AD Connect Getting Started page is shown in Figure 3-12. (At the time of this writing, the Azure AD Connect Wizard was in Beta preview. The user interface might look a little different when you use it post-final release.)
Azure AD Connect downloads, installs, and configures the identity bridge components for you that are necessary to configure a single, simple connection to Azure AD without requiring you to review pages and pages of documentation or download several tools. When you use this all-in-one tool for directory synchronization Azure AD Connect will:
Download and install pre-requisites like the .NET Framework, Azure AD PowerShell Module, and Microsoft Online Services Sign-In Assistant.
Azure AD connect will download and install all of the components necessary to configure and activate directory synchronization with your Azure AD directory. Configure either the password sync or the single sign-on option, depending on whether or not you select express settings or choose to use custom settings.
Azure AD Connect express settings
If you select to use express settings when installing Azure AD Connect to enable synchronization for a single Windows Server Active Directory forest, the wizard will automatically install AAD Sync on the server the wizard is installed on, configure synchronization of the on-premises Active Directory forest, enable password sync, and finally start the initial synchronization for you.
Azure AD Connect makes directory synchronization with the password sync for a single forest about as easy as can be imagined. After you download and start the wizard, it will set up everything for you with just a few mouse clicks, allowing sign-on to cloud resources based on Active Directory passwords with only a few minutes of work.
Azure AD Connect custom settings
If you want to go beyond basic directory and password synchronization, you can select to use custom settings when installing Azure AD Connect. In addition to directory synchronization, this option will guide you through the steps necessary to implement and configure AD FS for SSO.
You do not need to be an AD FS expert to configure SSO using Azure AD Connect because the wizard will guide you through each step of the process. However, you do need to have one SSL certificate10 for your federation service name before you get started. That .pfx file will be imported and configured for you later on, when the wizard is configuring AD FS for you. AD FS and SSO really cannot get much easier.
10 You can learn more about the SSL certificate requirements to enable AD FS using Azure AD Connect at http://msdn.microsoft.com/en-us/library/azure/dn832693.aspx.
Download Azure AD Connect
While this is the third directory synchronization tool discussed thus far, it is also the first synchronization tool to be recommended for you to download. Azure AD Connect is the simplest, most complete option for enabling both directory synchronization and identity federation.
This is the one directory synchronization tool that you want to be sure to have in your toolbox before continuing and you can get it at http://aka.ms/dpzn0e.