CHAPTER 9

Identity Management with Azure Active Directory

Introducing Azure Active Directory

Azure Active Directory (AAD) is a service made available through Microsoft Azure for Microsoft cloud-based identity management and access capabilities. You can use this service to authenticate with other clouds. It is similar in function to Active Directory (AD), which is a service that runs in an on-premises datacenter on Windows Server.

AAD is the foundation for identity management in Office 365, and it can be used to provide single-sign on (SSO) access to more than 2,400 other cloud-based services such as Box, Dropbox for Business, and Salesforce, to name just a few.

Azure Active Directory Versions

AAD is available in three versions: Free, Basic, and Premium. The features of each version of AAD are included in the next higher level, as shown in Table 9-1.

With the Free version of AAD, you can manage user accounts that are cloud-based accounts or synchronized with your on-premises AD. You can also use the Free version to enable SSO with up to ten of the software as a service (SaaS) application providers with whom Microsoft has partnered.

AAD Basic Features

AAD Basic provides all the features that are available in the Free version and also introduces the ability to customize some of the pages with which users regularly interact. With the Basic version of AAD, you can customize the sign-in page and the access panel. This feature allows you to brand the portal with your company logo, which gives the service a personal look and feel.

The default sign-in page, shown in Figure 9-1, lets users access SaaS applications, such as when signing into Office 365.

Figure 9-2 shows a customized Office 365 Portal sign-in page. Notice how support contact information is provided. Another common sign-in page configuration includes a legal disclaimer.

The access panel page in the Portal provides links to the SaaS applications to which a user has been granted access. You also get group-based access management and provisioning, which greatly simplifies the management of application access. By assigning access to SaaS-based applications to a single group, you only need to manage the membership of the group to provide access to the application to individual users.

The two biggest differences between the Free version and the Basic and Premium versions of AAD are the number of supported objects and the SLA. With the Free version, the default object quota is 150,000. It is possible, however, to go above this limit by contacting Azure support; they will increase the quota to a maximum of 500,000 on request. The Basic and Premium versions both support an unlimited number of objects. Also with the Free version, there is no SLA for the service; SLAs of 99.9% are available only when you purchase the Basic or Premium version of AAD.

AAD Premium Features

The highest level of AAD is the Premium version. With AAD Premium, Microsoft provides the following features in addition to those found in the Free and Basic versions.

Password Write-Back

Password write-back is an Azure Active Directory Synchronization Services (AAD Sync) tool feature that, when enabled, is used by your users to change a forgotten on-premises password in the cloud. It lets you configure your Azure tenant to write passwords back to your on-premises AD. When it’s configured, it provides a simple cloud-based way for users to reset their on-premises passwords without needing to be in the office or call the helpdesk.

Password write-back is supported for resetting passwords for users regardless of whether you use Active Directory Federation Services (AD FS) or another federation technologies for SSO and whether you are using password synchronization. With password write-back, as long as the user accounts are synchronized into your AAD tenant, the on-premises passwords can be managed from the cloud.

Enabling password write-back does not change your on-premises AD password policies. In the same manner as a user changes their password on-premises, when a user resets their password, AAD ensures that it meets the on-premises AD policy before committing it to that directory.

Password write-back doesn’t require any inbound firewall rules to work with your on-premises AD. It uses an Azure service bus relay as the communication channel into AD. This means you don’t have to open any inbound ports on your firewall for this feature to work.

Self-Service Group Management for Cloud Users

Self-service group management lets users create and manage security groups in AAD and provides them with the ability to request security group memberships, which can then be approved or denied by the owner of the group. By using self-service group management features, you can delegate daily control of group membership to people who understand the business need for membership requests.

A benefit of self-service group management is that it removes the burden of a group manager having to know who requires access to a group and who does not. For example, if you have many SaaS applications and use the access-management feature, by using self-service group management, users can submit requests to join groups as they need. The group owner then approves or denies the membership based on the business need for joining the group.

Multifactor Authentication (for Cloud and On-Premises Applications)

Azure multifactor authentication (MFA) provides a second level of security when signing into cloud-based or on-premises applications. When enabled, Azure MFA can be configured to verify a user’s identity using a mobile app, a text message, or a call to a mobile or landline phone.

You can use Azure MFA to secure cloud-based SaaS applications when authenticating with AAD or when using AD FS by configuring the AAD user account to require MFA. AAD security groups can also be configured to require MFA, which greatly simplifies its management, especially if you are also using the previously discussed self-service group management.

The MFA feature can also be used to secure on-premises applications. Doing so requires an MFA server to be installed and configured in your datacenter. MFA for on-premises applications provides the same MFA experience as Azure MFA when configured to provide a second layer of security to on-premises resources, such as IIS or AD.

When a user attempts to sign in to an on-premises application that has been configured to require a second level of authentication, the on-premises MFA server makes a call to the Azure MFA authentication service, which contacts the user by whatever method has been configured (mobile app, phone call, or text message).

Advanced Usage and Security Reports

All versions of AAD provide access and usage reporting to help administrators understand where potential security risks exist. The Azure Management Portal provides reports on five separate categories:

• Anomalous activity (an activity, such as a sign-in from an unknown source, that is inconsistent with what is normally expected)
• Activity logs
• Integrated applications
• Error reports
• User-specific reports

AAD Free Reports

AAD Premium offers more advanced reporting than the Free version. The following lists provide information about each of the reports that are available with AAD Premium:

• Sign-Ins from Unknown Sources: Indicates users who have successfully signed in to your Azure tenant while assigned a client IP address that is recognized by Microsoft as an anonymous proxy IP address. Users who want to hide their computer’s IP address often use these proxies. They may be used for malicious purposes. For example, hackers sometimes use these proxies. This report shows the number of times a user has successfully signed in to your Azure tenant from that address and the proxy’s IP address.
• Sign-Ins After Multiple Failures: Indicates users who have successfully signed in after multiple, consecutive failed sign-in attempts. It also shows you the number of consecutive failed sign-in attempts made prior to the successful sign-in and a timestamp associated with the first successful sign-in. Possible causes include
  • A user who forgot their password
  • A successful password-guessing brute-force attack
• Sign-Ins from Multiple Geographies: Indicates successful sign-ins by a user originating from different countries when the travel time between those countries would prohibit the user from actually signing in from both places. Results of this report show the successful sign-in events, together with the time between the sign-ins, the countries from which the sign-ins originated, and the estimated travel time between the two locations. Possible causes include
  • User sharing their password
  • User using a remote desktop to launch a web browser for sign-in
  • A hacker signed in to the account of a user from a different country
• Application Dashboard: Indicates cumulative sign-ins to the application by users in your organization over a selected time period. The chart on the dashboard page helps you identify usage trends for that application.
• Account Provisioning Errors: Lets you monitor errors that occur during the synchronization of accounts from SaaS applications to AAD.
• Activity: Shows the sign-in activity for a user. The report includes information such as the application signed in to, device used, IP address, and location. Microsoft does not collect the history for users who sign in with a Microsoft account.
• Audit: Shows a record of all audited events within the last 24 hours, last 7 days, or last 30 days. The report includes events in the following categories:
  • Credential updates
  • Device management
  • Directory synchronization
  • Domain management
  • Group management
  • Partner administration
  • Policy management (MFA)
  • Role changes
  • User account changes
  • User licensing
  • User, group, and contact management

AAD Premium Reports

The AAD reports details the following:

• Sign-Ins from IP Addresses with Suspicious Activity: Includes sign-in attempts that have been executed from IP addresses where suspicious activity has been noted. Suspicious activity includes multiple failed sign-in attempts from the same IP address over a short period of time and other activity deemed suspicious, possibly indicating that a hacker has been trying to sign in from this IP address. The results of this report show sign-in attempts that originated from an IP address where the suspicious activity was noted, together with the timestamp associated with the sign-in.
• Irregular Sign-In Activity: Includes sign-ins that have been identified as irregular by the Azure machine-learning algorithms. Reasons for marking a sign-in attempt as irregular include unexpected sign-in locations or time of day and locations that could be an indication that a hacker has been trying to sign in using this account. The machine-learning algorithm classifies events as irregular or suspicious, where suspicious indicates a higher likelihood of a security breach. The results of this report show these sign-ins, together with the classification, the location, and a timestamp associated with each sign-in.
• Sign-Ins from Possibly Infected Devices: Shows sign-ins from devices on which malware (malicious software) may be running. A possible cause may be users with anomalous sign-in activity. Microsoft Azure correlates IP addresses of sign-ins against IP addresses from which an attempt was made to contact a malware server. Use this report when you want to view all user accounts for which anomalous sign-in activity has been identified. This report includes data from all other anomalous activity reports. The results show you details about the user, the reason why the sign-in event was flagged as anomalous, the date and time, and other relevant information about the event.
• Users with Anomalous Sign-In Activity: Lists accounts that have been flagged as having anomalous sign-ins. Anomalous sign-in activity includes sign-ins from unknown locations, multiple failed login attempts, sign-ins from more than one location, and sign-ins that are outside of the usual time of day.
• Application Usage: Summary: Shows summary usage data for all the SaaS applications in your directory. This report is based on the number of times users have clicked the application in the Access Panel.
• Application Usage: Detailed: Provides information on how often a specific SaaS application is being used. Like the Application Usage: Summary report, this report is based on the number of times users have clicked the application in the Access Panel.
• Devices: Shows the IP address and geographical location of devices that a specific user has used to access Azure AD.
• Groups Activity: Provides information on all the activity for the self-service managed groups in your directory.
• Password Reset Registration Activity: Shows all the password-reset registrations that have occurred in your organization.
• Password Reset Activity: Shows all password-reset attempts (both successful and failed) that have occurred in your organization.

Service-Level Agreement

Microsoft offers a financially backed service-level agreement (SLA) for AAD Premium customers for Azure services. Table 9-2 shows the financial credit for which Azure customers may be eligible based on the amount of time the service is unavailable.

The SLA is available on each of the following Azure services:

• Active Directory
• API Management
• Automation
• Backup
• BizTalk Services
• Cache
• CDN
• Cloud Services
• ExpressRoute
• HDInsight
• Media Services
• Mobile Services
• Multifactor Authentication
• RemoteApp
• Scheduler
• Service Bus
• Site Recovery
• SQL Database
• Storage
• StorSimple
• Traffic Manager
• Virtual Machines
• Virtual Network
• Visual Studio Online
• Web sites

The monthly recovery time objective (RTO) and SLA for on-premises-to-Azure failovers for the site recovery service includes an additional metric for determining the amount of credit for which you could be eligible. The formula for determining this credit is shown in Table 9-3.

The full Azure SLA document is available for download at www.microsoft.com/en-us/download. Search for “Microsoft Azure SLA” at the Microsoft download site, and download the most current version of the document.

Adding and Managing Accounts in Azure Active Directory

AAD provides a great deal of flexibility in terms of adding and managing accounts. Adding accounts to AAD can be accomplished in a few ways.

Bulk User Creation

Adding users manually into AAD is convenient and simple, but it can be very time-consuming if there are a large number of users to be added. In cases where hundreds or even thousands of users need to be added in a single event, importing user accounts from a .csv file is quick and easy.

The bulk import option is not available in the Azure Portal or with Azure PowerShell. To perform these steps, a subscription to Office 365 is required. This book does not cover Office 365, but for the purposes of this exercise, you require an Office 365 subscription. You can obtain a trial Office 365 subscription at https://products.office.com/en-us/business/office-365-enterprise-e3-business-software.

It is assumed that you already have an Azure subscription. If you need to sign up for an Office 365 trial tenant as well, you can use the same ID that you use to manage Azure. Office 365 and Azure share the same AD space, so when you add users via the Office 365 bulk-import processes, the accounts will also appear in your Azure Portal under the Users tab in the Domains window.

After you create your Office 365 tenant, you can use the bulk-import process through Windows PowerShell. To do so, you first need to download and install the Azure Active Directory Module for Windows PowerShell cmdlets (pronounced command-lets). These cmdlets let you perform and automate user- and domain-management functions with AAD.

The first step in using the AAD PowerShell module is to install it on a computer that will be used for AAD management. The Azure AD Module is supported in Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2. The default versions of .NET Framework and Windows PowerShell are required to be installed on the management computer as well.

The Microsoft Online (MSOL) Services Sign-In Assistant must also be installed on the computer. The Sign-In Assistant is available from the Microsoft Download Center at http://www.microsoft.com/en-us/download/details.aspx?id=41950.

After downloading and installing the Sign-In Assistant, the next step is to download and install the Azure Active Directory Module for Windows PowerShell. The module is available at: http://go.microsoft.com/fwlink/p/?linkid=236297.

Now that the necessary components have been installed, you can connect to AAD using Windows PowerShell. First you need to connect to AAD. Use the following cmdlets to establish the connection:

$cred = get-credential
connect-msolservice -credential $cred

The first part of the cmdlet produces a credentials dialog window, as shown in Figure 9-12, where you enter your tenant Global Administrator or User Administrator name and password. These credentials are stored in the $cred variable, which is used by the second cmdlet to connect to Microsoft Online.

Once the connection to the MSOL service has been established, you can use other PowerShell cmdlets to manage your users and domains. To perform the bulk import, you first need to populate a .csv file with the required columns, as follows:

• UserPrincipalName
  FirstName
  LastName
  DisplayName

A good recommendation, as shown in Figure 9-13, is to add the UsageLocation field to the .csv file as well. Doing so removes the prompt for the user to set it when they sign in for the first time or for the administrator to have to do this when licenses are applied. Additionally, the user’s preferred language can be set in advance of them logging in, which saves a mouse click.

You use two cmdlets to bulk-create the users in AAD from the .csv file: Import-csv and New-MsolUser. The following example imports users from a .csv file into a variable and then cycles through the information in the variable to create the accounts:

$users = Import-Csv C:	empO365Users.CSV

$users | ForEach-Object {

New-MsolUser -UserPrincipalName $_.UserPrincipalName -FirstName $_.FirstName -LastName $_.LastName -DisplayName $_.DisplayName -UsageLocation $_.UsageLocation}

The accounts are populated with the information in the .csv columns by reading the individual variables and then writing that information to the attributes in AAD.

Although you can’t do this in the Azure Portal, in Office 365 it is possible to add users via a .csv file import through a graphical user interface (GUI). This can be done by signing in to Office 365 as a Global Administrator or User Administrator, navigating to the Users Active Users page, and clicking the Bulk Add link, as shown in Figure 9-14.

Directory Synchronization

In addition to manually creating individual user accounts in Azure or bulk-creating them from a .csv file, another method in AAD to create them is through directory synchronization. With directory synchronization, objects are synchronized from your on-premises AD into AAD with the Azure Active Directory Synchronization Services (AAD Sync) tool, available free of charge from Microsoft. User objects, security groups, and distribution groups are synchronized with this tool.

The latest release of AAD Sync, released in the fourth quarter of 2014, offers many improvements over the previous version of the Directory Synchronization tool, known as DirSync. These improvements include an increase in the number of objects that can be synchronized before requiring a full SQL server installation from 50,000 to 100,000. Also, in the initial release of AAD Sync, password sync was not available; the current version makes this feature available.

AAD Sync Operational Accounts

The prior version of the Directory Synchronization tool, DirSync, required that an Enterprise Administrator account be used for the installation. This permission level was required so that installation operations, such as setting permissions for password sync or hybrid-enabled write-back, could be set. This level of permission was seen as excessive by many organizations’ security teams, because the credentials for an Enterprise Administrator account are often a closely guarded secret.

The AAD Sync tool today no longer requires these permissions for installation. Instead, you are now required to set these permissions manually before installing AAD Sync. In organizations where the Enterprise Administrator permissions are known by only a few AD administrators, the installation permissions can be set by those administrators and then the installation of AAD Sync can be carried out by another server administrator without the need to grant that person Enterprise Administrator permissions first.

It is recommended that you create an AAD Sync service account for connecting to your on-premises AD as well as one for connecting to AAD. The account requirements for each are as follows:

• AAD: This must be a Global Administrator account, and it should have the password set never to expire.
• On-premises AD: This can be a standard user account. If password sync, hybrid, or password write-back is required, the permissions must be applied to the service account separately for those features to work properly.

The permissions required for password synchronization are as follows:

• Replicating Directory Changes
• Replicating Directory Changes All

Installing the Azure Active Directory Synchronization Service

Now that all the permissions for installing AAD Sync have been configured, you can proceed with the installation. Microsoft has worked hard to simplify the installation, whether it’s for a single forest or a multiforest environment. The installation is straightforward and easy to follow for most deployments.

Filtering AAD Sync

As in previous versions of the Directory Synchronization tool, there are three options for filtering objects to prevent them from synchronizing to AAD:

• Domain-based: Excludes an entire domain from your on-premises AD forest from synchronizing to AAD.
• Organizational unit-based filtering: Excludes an entire OU from synchronizing to AAD. As an example, you may have an OU that is specifically used for service accounts that don’t need to be synchronized to AAD.
• Attribute–based: Prevents accounts that have specific data in a certain attribute. For example, you can put “on-premises only” into an account attribute and then filter on that data within that attribute to prevent accounts with this data from synchronizing to AAD.

Configuring Attribute-Based Filtering

There are several ways to configure filtering based on AD attributes. Configuration on inbound synchronization from AD is recommended because these configuration settings will be kept even after upgrading to a newer version. Configuration on outbound synchronization to AAD is supported, but these settings will not be kept after upgrading to a newer version; they should be used only when required to view the combined object in the metaverse to determine filtering. For this reason, this section only discusses inbound filtering.

Inbound-based filtering is accomplished by using the default configuration, where objects going to AAD must not have the metaverse attribute cloudFiltered set to a value and the metaverse attribute sourceObjectType is set to either User or Contact.

When you are filtering objects so that they don’t synchronize to AAD, the attribute cloudFiltered must be set to True. In all other cases, the value should remain empty. This method is used to prevent synchronizing an object to AAD. This type of filtering is known as negative filtering.

In the following example, you filter out all contact objects that have an SMTP address ending in office365pro.ca. In the lab used in this example, there are two forests, and in each forest there are mailbox users who have contact objects in the other forest. Thus users in each forest are visible in the Global Address List.

Summary

In this chapter, you were introduced to Azure Active Directory. You learned about the different versions of AAD and what each version offers. You also learned about the different methods used to add user accounts to AAD, along with how to install AAD Sync and how to configure the different filtering options.

In the next chapter, you learn about extending your on-premises AD to Azure by using the site-to-site VPN and installing a Windows server on an Azure virtual machine that will be configured as a domain controller in your domain.