Implement an Azure Active Directory

Microsoft Azure Active Directory is the identity and access management solution for the Microsoft Azure platform. Organizations can use Azure Active Directory to configure access to applications used by the organization, manage users and groups, configure Multi-Factor Authentication (MFA) for users, identify irregular sign-in activity using advanced machine learning algorithms, extend existing on-premises Windows Server Active Directory implementations to Azure Active Directory, and empower users to manage their identity settings.

Objectives in this chapter:

• Objective 5.1: Integrate an Azure AD with existing directories
• Objective 5.2: Configure the Application Access Panel
• Objective 5.3: Integrate an app with Azure AD

Objective 5.1: Integrate an Azure AD with existing directories

Integrating Azure Active Directory with existing directories is one of the most common tasks for an IT professional because most organizations have an existing on-premises directory and/or online directory that the business depends on. Azure Active Directory is by no means intended to be a replacement for existing directories. It is a directory service that is specifically designed for the cloud, and, in particular, the Microsoft Azure platform. As such, it delivers services and features that can augment existing directory solutions to handle cloud-based identity and access needs for an organization.

Azure Active Directory is offered in either a Free, Basic, or Premium edition. The Basic and Premium editions offer advanced enterprise features, an unlimited number of directory objects, and SLAs. The content in this chapter discusses features and services of Azure Active Directory without regard for which edition the feature is offered in. Details about which features are available with each edition are available at http://msdn.microsoft.com/en-us/library/azure/dn532272.aspx.

Implementing directory synchronization

Many organizations have a significant investment in their on-premises infrastructure that includes a Windows Server Active Directory used to manage users, groups, and other resources in the organization. This on-premises directory provides the identity and access capabilities needed by IT professionals to support their business operations on-premises.

As these organizations move workloads to Azure and leverage cloud applications to support their business, it is common for organizations to seek ways to leverage their on-premises investment in Windows Server Active Directory. Organizations do this to provide similar identity and access capabilities for their cloud environment in Azure.

Directory synchronization addresses the needs of IT professionals seeking to extend their on-premises Windows Server Active Directory to Azure Active Directory. It reduces the administration costs that would otherwise be associated with managing users and groups in different environments. It also promotes a more positive user sign-in experiences for users accessing applications in their on-premises environment and cloud applications running in Azure.

Azure Active Directory supports directory synchronization of users and groups under four scenarios. The scenario best suited for your environment will depend on your on-premises infrastructure and authentication requirements for your users. These scenarios and a description of each are shown in Table 5-1.

TABLE 5-1 Directory synchronization scenarios supported by Azure Active Directory

scenario	description
Directory synchronization	Synchronizes on-premises users and groups to Azure Active Directory. Synchronization occurs on scheduled intervals to synchronize changes made in the on-premises directory.
Directory synchronization with password sync	An extension to the directory synchronization scenario that synchronizes a hash of a user’s on-premises password to Azure Active Directory. This enables users to authenticate to Azure Active Directory using the same credentials they use to authenticate to their on-premises directory.

Currently there are two tools used to implement directory synchronization, which are as follows:

• Azure Active Directory Synchronization tool (DirSync)
• Azure Active Directory Synchronization Services (AAD Sync)

Which tool you use also depends on the scenario you are implementing and the synchronization features that your scenario requires. AAD Sync should be the tool you look to first because this is the tool Microsoft is making investments in going forward. DirSync was the first directory integration tool released and is still required for some scenarios.

Enable directory integration

Regardless of the directory synchronization scenario you are implementing, the first task will be to enable directory synchronization for your Azure Active Directory. This can be accomplished in the Azure management portal by going to the Directory Integration page of your directory and setting the Directory Sync field to Activated, as shown in Figure 5-1.

After directory sync is activated for your directory, you can proceed with the implementation of one of the directory synchronization scenarios. As shown previously in 5-1, there are four directory synchronization scenarios supported by Azure Active Directory. The following scenarios are the most common, and therefore the focus for the next two sections:

• Directory synchronization with password sync
• Directory synchronization with single sign-on

Configure directory synchronization with password sync

Configuring directory synchronization with password sync is the simplest of the supported directory synchronization scenarios. It does not provide a true single sign-on experience for users, but it does enable users to sign-in using the same username and password that they use in their on-premises environment. For many organizations, this is sufficient to meet their authentication requirements for cloud applications if Active Directory Federation Services (AD FS) is not already configured on-premises.

To get started with this scenario, the Azure management portal will open step three on the Directory Integration page where you activated directory synchronization. Click the download link for the directory sync tool and save it to either the on-premises domain controller, or a domain joined server that will be dedicated to running directory synchronization. The download is a single executable called DirSync.exe. After copying this to the target server in your on-premises environment, run DirSync.exe to start the installation.

The DirSync installation is a wizard-driven experience that starts by prompting you for two sets of credentials that DirSync needs to configure directory synchronization. The credentials needed are as follows:

• The credentials for a global administrator in the Azure Active Directory
• The credentials for a domain administrator in the Windows Server Active Directory

The rest of the options are check boxes to enable or disable a feature of directory synchronization, such as Hybrid Deployment or Password Synchronization. The goal of this section of the objective is to configure password synchronization; therefore, this option must be checked in the wizard, as shown in Figure 5-2.

After exiting the DirSync Installation Wizard, DirSync will continue running in the background as a Windows Service and periodically synchronize objects from the on-premises Windows Server Active Directory to the Azure Active Directory. The name of the service is Windows Azure Directory Sync Service.

Verifying that directory synchronization is working is a matter of simply checking the Users and/or Groups page of the directory in the management portal. Users that are synchronized from the on-premises Windows Server Active Directory will appear as sourced from the Local Active Directory, as shown in Figure 5-3. You can also check the event log on the server running DirSync to see logs recorded by DirSync. This will be covered in further detail in the Monitor Azure Active Directory section of this text.

The default configuration for this scenario synchronizes user passwords from the Windows Server Active Directory to the Azure Active Directory. In the event that a user needs to reset his or her password, an administrator of the on-premises directory would have to reset the password for the user. Resetting user passwords is one of the most common IT tasks costing organizations time and money, and Azure Active Directory offers a feature to combat this through its self-service password reset (SSPR) feature. The SSPR feature enables you to define password reset policies for users in a way that gives the organization great control over how password resets are performed, while empowering users to complete the task on their own. This feature is available for Azure Active Directory Basic and Premium, and is enabled and configurable in the management portal, as shown in Figure 5-4.

DirSync with password sync includes a feature called password write-back that can be enabled for an Azure Active Directory with SSPR enabled. With this feature, password resets performed in Azure Active Directory can be persisted back to the on-premises Windows Server Active Directory. The DirSync installation includes the following Windows PowerShell cmdlets to enable or disable this feature as shown here:

• Enable-OnlinePasswordWriteback
• Disable-OnlinePasswordWriteback

Before running these cmdlets, you must first run the Windows PowerShell script at %ProgramFiles%\Azure Active Directory Sync\DirSyncConfigShell.psc1 with elevated admin rights. Additional information, potential requirements, and troubleshooting steps for the password write-back feature are available at http://msdn.microsoft.com/en-us/library/azure/dn688249.aspx.

Configure directory synchronization with single sign-on

Configuring directory synchronization with single sign-on results in a better user experience for users than the password-sync scenario discussed in the previous section because it provides true single sign-on for the users. In this scenario, if a user is already authenticated in their on-premises environment, the user will not be prompted to re-authenticate when accessing cloud applications protected by Azure Active Directory. This is the most significant difference for users, as compared to the password sync scenario described earlier. In that scenario, the user would be prompted to sign-in when accessing cloud applications even if the user was already authenticated in their on-premises environment.

The single sign-on experience this configuration delivers is made possible by the fact that users always authenticate to their on-premises Windows Server Active Directory, whether they are accessing resources on-premises or in the cloud. In other words, there is no synchronization of hashed passwords to Azure Active Directory. Instead, users are prompted to authenticate at a security token service (STS) on-premises. Active Directory Federation Service (AD FS) is such a service and must be installed in the on-premises environment to implement this scenario.

Implementing this scenario requires the high-level tasks below. Each of these tasks are broken down further into several steps that must be completed.

• Have a custom domain configured for the Azure Active Directory that you are going to integrate with.
• Have an SSL certificate that can be used when communicating with the AD FS server in the on-premises domain.
• AD FS deployed.
• A trust setup between AD FS and Azure Active Directory.
• Directory synchronization (not password sync) installed and configured.

Assuming AD FS will be used for the on-premises STS, step-by-step instructions and guidance is available at http://msdn.microsoft.com/en-us/library/azure/jj205462.aspx.

If you have the required SSL certificates and servers available for the required federation servers and proxy servers, the AAD Connect tool will configure everything for you. This will be the recommended path for implementing this scenario for users who don’t already have AD FS or another third-party STS implemented in their environment.

Integrating Azure Active Directory with Office 365

Although Microsoft Azure and Microsoft Office 365 are marketed and sold as separate subscriptions, there is one service that ties the two together, and that service is Azure Active Directory. If you are an Office 365 subscriber, you already have an Azure Active Directory, whether you have an Azure Subscription or not. That is because the directory you get with Office 365 is actually a tenant in Azure Active Directory. However, that does not mean you have the full set of services an Azure Subscription offers. To be able to provision services and resources in Microsoft Azure requires that you have an Azure subscription.

If you have an Office 365 subscription and an Azure subscription, the Azure Active Directory from your Office 365 can be integrated with your existing Azure subscription.

If you have an Azure subscription but don’t have an Office 365 subscription, Office 365 can be added to your Azure subscription through the Application Gallery.

No matter which of these scenarios applies, integrating an Azure Active Directory from an Office 365 subscription with an Azure subscription offers your organization some important benefits, including the following:

• Authorized users in the Azure Active Directory can provision resources in the Azure subscription.
• Application access to software as a services (SaaS) applications that the organization depends on can be managed in the management portal for users in the directory.
• Applications an organization develops in-house can be protected such that only authenticated users in the directory can access them.

Sign up for Azure as an organization using Office 365 organization accounts

If you already have an Office 365 subscription but not an Azure subscription, the easiest way to add an Azure subscription for your organization is to go to http://azure.com and click the link to start a free trial subscription. When the sign in page appears, you should click the Sign In With Your Organizational Account link, as shown in Figure 5-5.

After clicking the link to sign in, using your organizational account, complete the process as follows:

1. Provide your contact information. Some of the fields will be pre-populated from your directory in Office 365 for you.
2. Provide mobile verification as a second authentication step.
3. Provide payment information.
4. Agree to the terms for an Azure subscription.

After completing these steps, the Azure subscription will be created, your directory from Office 365 will be accessible in the management portal, and you will be added as a service administrator on the Azure subscription. Optionally, you can add co-administrators to the Azure subscription so others in your organization can provision services in the Azure subscription. No further action is needed to integrate your Office 365 directory with your Azure subscription.

Integrate an Office 365 directory with an existing Azure subscription

If you already have an Office 365 subscription and an Azure subscription obtained from a Microsoft Account, you can integrate the Office 365 directory with the Azure subscription by adding an existing directory to your Azure subscription. To accomplish this, sign in to the management portal using your Microsoft account credentials associated with the Azure subscription. Next, click New, App Service, Active Directory, Directory, and Custom Create. This opens a dialog box to add a directory. Change the drop-down box for the directory field to Use Existing Directory, as shown in Figure 5-6.

This approach requires you to sign out of the management portal and sign back in using the organizational account of a global administrator in the Office 365 directory. The reason you must sign back in as a global administrator of the directory is that Azure will add your Microsoft account to the directory as a global administrator and associate the directory with your Azure subscription, which requires the permissions of a global administrator to complete.

Complete details about these administrator roles, and any applicable constraints, can be found at http://msdn.microsoft.com/library/azure/dn468213.aspx.

After completing this step, your Office 365 directory will be the default directory associated with your Azure subscription. You will be able sign in to the management portal using your organizational account and provision services in the Azure subscription. No further action is needed to integrate your Office 365 directory with your Azure subscription.

Adding Office 365 to an existing Azure subscription

If you have only an Azure subscription, you can add Office 365 for your organization by signing up for Office 365 using the organizational account credentials for a global administrator user in your Azure Active Directory. Unless you have created a different Azure Active Directory in your Azure subscription, the Default Directory that came with your Azure subscription will be used to purchase the Office 365 subscription.

Adding Office 365, using your existing Azure Active Directory, can be accomplished by going to https://portal.office.com. Sign in using the credentials for a global administrator in your directory. After signing in you will be in the Office 365 Admin portal. Because you don’t have an Office 365 subscription associated with the Azure Active Directory you signed in with, you will be prompted to purchase services, as shown in Figure 5-7.

Proceeding through the options to purchase an Office 365 subscription will result in an Office 365 subscription that is backed by the Azure Active Directory in your Azure subscription. Just as in the previous scenarios, the Office 365 subscription will be integrated with the Azure Active Directory. Users and groups can be created using the management portal or the Office 365 Admin portal.

Configuring a custom domain

Each Azure subscription is assigned a default directory and DNS name on the shared domain *.onmicrosoft.com. For example, if you signed up for an Azure subscription using the name Contoso, the default directory and DNS name for your Azure subscription is contoso.onmicrosoft.com. Although this assigned domain is a fully functional domain, it isn’t necessarily user friendly. Users would have to sign in using a sign in name, such as john.doe@contoso.onmicrosoft.com, which has the disadvantages of having to type in a rather long domain and also not being intuitive for a user in the Contoso directory.

By adding a custom domain to your directory, you can significantly improve the user sign-on experience for users in the directory. If you own the contoso.com domain, and associate it to your Azure directory, users would be able to sign in using a sign in name, such as john.doe@contoso.com.

Configuring a custom domain involves the following steps:

1. Obtain ownership of a domain if you don’t already have one.
2. Add the domain to your Azure directory.
3. Update DNS records at the domain registrar.
4. Verify the domain in the management portal.
5. Change the primary domain for the directory.

Assuming the ownership of a domain has been established, the next step is to add the domain to the directory. In the management portal, go to the Domains page for the directory, and then click Add. This action opens a dialog box where you can specify the name of the domain and indicate whether you plan to configure the domain for single sign-on with a local Windows Server Active Directory, as shown in Figure 5-8.

Clicking Add adds the domain to the directory and generates a unique DNS record value for the domain. The value of the DNS record is what you must enter at your domain name registrar because this record is what Azure uses in the final step to verify that you own the domain.

After the domain has been successfully added to the directory, the management portal will present a second dialog box showing the unique value for the DNS record that must be added to the domain name registrar, as shown in Figure 5-9. The record type shown is a TXT record, which is preferred. However, if you need an MX record, you can get the value by selecting the MX record type in the dialog box.

After adding either the TXT record or the MX record to your domain name registrar, the next step is to verify the domain, which is accomplished by clicking Verify.

At this stage, you have two domain names associated with your directory: the one that was assigned to your directory on the *.onmicrosoft.com shared domain, and now your custom domain. The last step in this process is to make your custom domain the primary domain for your directory, which can be accomplished in the Domains page for the directory by clicking Change Primary, as shown in Figure 5-10.

Monitoring Azure Active Directory

Azure Active Directory provides features that enable you to monitor activities of users in the directory. Using reporting, notifications, and services of Azure Active Directory, you can see the sign-in activity of users, identify suspicious activity, and identify application usage trends in the organization.

User and group activity sign-in reports

You can get user and group sign-in activity using the management portal. To see sign-in activity for a user, click the user you want to retrieve the report for in the Users page of the directory. In the individual user’s page is an Activity tab where you can specify the criteria for the report, as shown in Figure 5-11.

You can also run a sign-in activity report for a group of users. To view sign-in activity for a group, click the group you want to retrieve the report for in the Groups page, and follow the same steps.

Whether your report is for a single user or a group, the information on the report will be comprised of the following:

• The date and time the sign in occurred.
• The application the user accessed. This could be an Office 365 application or an application registered in the directory for the organization, such as a SaaS application or a custom developed application.
• The user’s IP address.
• The user’s location, such as city and state.
• The type of client the user was running, such as Windows 8.

You can view the report in the management portal, or you can download it as a .csv file.

Azure reports

Azure Active Directory reports are an extremely useful monitoring tool that you can use to gain visibility into potential security risks for your organization, user activities such as sign in, password resets, and application usage.

The reports are available in the reports page of the directory in the management portal. They are organized into three groups of reports, which are anomalous activity, activity logs, and integrated applications. You can view the reports directly in the management portal or download them as .csv files.

Anomalous activity reports are used to report sign in activity that Azure Active Directory found to be inconsistent with normal activity. Data in the report does not necessarily mean there is a security risk. Ultimately, that is for you decide. These reports are designed to bring this information to your attention so you can make informed decisions about how to respond. Table 5-2 lists the anomalous activity reports available.

TABLE 5-2 Anomalous reports for Azure Active Directory

Report name	description
Sign ins from unknown sources	May indicate an attempt to sign in without being traced.
Sign ins after multiple failures	May indicate a successful brute force attack.
Sign ins from multiple geographies	May indicate that multiple users are signing in with the same account.
Sign ins from IP addresses with suspicious activity	May indicate a successful sign in after a sustained intrusion attempt.
Sign ins from possibly infected devices	May indicate an attempt to sign in from possibly infected devices.
Irregular sign in activity	May indicate events anomalous to users’ sign in patterns.
Users with anomalous sign in activity	Indicates users whose accounts may have been compromised.

Activity log reports are used to report sign in activity, location of a user during sign in, the IP address of the user, and password reset activities. Table 5-3 lists the activity log reports available.

TABLE 5-3 Activity log reports for Azure Active Directory

Report name	description
Audit	Audited events in your directory.
Password reset activity	Provides a detailed view of password resets that occur in your organization.
Password reset registration activity	Provides a detailed view of password reset registrations that occur in your organization.
Groups activity	Provides an activity log to all group-related activity in your directory.

The integrated applications reports are where you can identify application usage trends and account provisioning events related to users being granted or denied access to SaaS applications. Table 5-4 lists the integrated applications reports.

TABLE 5-4 Integrated applications reports for Azure Active Directory

Report name	description
Application usage	Provides a usage summary for all SaaS applications integrated with your directory. This report is based on the number of times users have clicked the application in the Access Panel.
Account provisioning activity	Provides information pertaining to the provisioning of user or group access to a SaaS application.
Account provisioning errors	Use this to monitor errors that occur during the synchronization of accounts from SaaS applications to Azure AD.

Notifications

The notifications feature for Azure Active Directory Premium users enables administrators to be notified via email when anomalous sign in activity is detected. The email in the alert includes a link to a report identifying the situation and requires that the user viewing the report be both a co-administrator on the Azure subscription, and a global administrator for the directory. Additional notifications pertaining to password reset activity are also configurable in the Configure page of the directory in the management portal, as shown in Figure 5-12.

Cloud App Discovery

Cloud App Discovery is a service you can use to discover cloud applications being used from within your organization. Unlike the application usage reports that report on application usage for applications you have provisioned in your Azure Active Directory, this service discovers applications that are being used that have not been provisioned in your directory. At the time of this writing, this service is in preview.

Cloud App Discovery is available at https://appdiscovery.azure.com. To get started using the service, you need to sign in using the organization credentials of a global administrator in the directory. The service works by collecting data from user’s computers about which cloud applications they are accessing and using. This is accomplished through an agent that you must download and install on the users’ machines you want to collect data for. The agent software runs on the user’s computer as a service called the Microsoft Cloud App Discovery Endpoint Agent and captures application usage on the machine. The agent periodically transfers the application usage data for the machine to the Cloud App Discovery service. You can download the agent from the Cloud App Discovery portal.

The Cloud App Discovery portal provides information about applications that have been discovered, the users that are accessing those applications, and application usage metrics such as the number of requests made to an application, the volume of data, and number of users. Using the management portal you can manage the applications discovered, proceed to add the application to your Azure Active Directory, and provision user and group access to it. Alternatively, you may decide the application is not suitable for the organization and take action to restrict access to it. Figure 5-13 shows a portion of the management portal where apps and users have been discovered.

Monitoring directory synchronization

DirSync records events in the Windows Application Event Log. The source of the logs is Directory Synchronization. DirSync runs on an automatic schedule of every three hours, and the password sync extension runs on a schedule of every 30 minutes. Therefore, many of the logs will be a result of these scheduled synchronizations.

Part of the DirSync installation includes the Synchronization Service Manager from Microsoft Forefront Identity Manger (FIM) 2010 R2. It is located at C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\msiiclient.exe.

The advantage that Synchronization Service Manager provides is clickable links on directory synchronization events to see details of the object synchronized. As an example, when a user is updated, you will be able to see all the attributes for the user that were updated, such as the display name, surname, upn, and more, This level of detail does not exist in the event logs. Using this tool to monitor synchronization only works for adding, updating, or deleting directory objects. It does not display information for password sync events. Figure 5-14 shows the Synchronization Statistics window in the Synchronization Service Manager client for a single directory object that was added, and a directory object that was updated. Notice in the Staging section, the Adds and Updates are linkable and clicking either will display the details for that directory object.

In some cases it may be necessary to turn on additional logging that is not captured in the event log or discoverable through the Synchronization Service Manager. For example, if there are synchronization errors occurring, it may be necessary to see the result of each action occurring in the context of the synchronization. You can use the following Windows PowerShell cmdlets to enable or disable logs for directory synchronization and password synchronization.

• Enable-DirSyncLog
• Disable-DirSyncLog
• Enable-PasswordSyncLog
• Disable-PasswordSyncLog

When enabling logging, you can also indicate the desired TraceLevel for the logs, which can be Error, Info, Verbose, or Warning.

Objective summary

• The default DNS name for an Azure Active Directory is assigned on the shared domain *.onmicrosoft.com.
• Verifying a custom domain can be done by adding either a TXT or an MX record to your domain name registrar. TXT records are the preferred method assuming that the domain registrar supports it. It is possible to have multiple domain names for a directory but only one domain can be the primary domain.
• Azure Active Directory Sync (AAD Sync) supports directory synchronization for multi-forest environments.
• Configuring directory synchronization with single sign-on requires an on-premises security token service (STS) be installed. In a Windows environment, this will generally be Active Directory Federation Services (AD FS), but other third-party products, such as Shibboleth, are also supported. The AAD Connect tool can be used to implement this scenario.
• A trust relationship between Azure Active Directory and the on-premises STS in the directory synchronization with single sign-on is required because Azure AD will externalize the authentication of users accessing the cloud application to the local STS. If a user is already authenticated in their on-premises environment, an authentication token will be issued by the STS without prompting the users again for credentials.
• The password write-back feature of directory synchronization with password sync requires the premium version for Azure AD.
• Azure Active Directory is offered in three tiers: Free, Basic, and Premium. The 99.9 percent SLA is only available in the Basic and Premium offerings.

Objective review

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

1. You need to give a user in your Azure Active Directory full administrative access. Which administrator role should you assign the user?

   1. Global administrator
   2. User administrator
   3. Password administrator
   4. Billing administrator

2. You have a user in your Azure Active Directory that needs permissions to create a virtual machine in the Azure subscription. What should you do to support this requirement?

   1. Assign the global administrator role to the user.
   2. Assign the user administrator role to the user.
   3. Add the user as a co-administrator on the Azure subscription.
   4. Add the user as a service administrator on the Azure subscription.

3. You need to verify a custom domain for an Azure Active Directory. Which type of DNS record can you add to your domain registrar to accomplish this? (Choose two.)

   1. CNAME (Alias)
   2. TXT (Text)
   3. MX (Mail Exchanger)
   4. A (Host)

4. You have configured directory synchronization with password sync between your on-premises Windows Server Active Directory and your Azure Active Directory. Which Windows PowerShell cmdlet should you use to allow password resets in Azure Active Directory to be persisted back to your on-premises directory?

   1. Enable-MSOnlinePasswordSync
   2. Enable-PasswordSyncLog
   3. Enable-DirSyncLog
   4. Enable-OnlinePasswordWriteBack

5. You have removed a user from your on-premises directory that is configured for directory synchronization with your Azure Active Directory. You need for this change to be synchronized immediately. Which Windows PowerShell cmdlet will you use?

   1. Start-OnlineCoexistenceSync
   2. Set-DirSyncConfiguration
   3. Enable-DirSyncLog
   4. Set-FullPasswordSync

6. You need to implement directory synchronization with single sign-on for a multi-forest environment. Which tool should you use?

   1. . DirSync
   2. AAD Sync
   3. AAD Connect
   4. Synchronization Service Manager