Our identity defines who we are and what we do. Identity is at the heart of many applications and services. Identity tells the story of who uses the application and what actions the user can perform. Without identity, applications often lose the closeness, or personal relationship, so many users find appealing.
The identity story in the Microsoft Azure platform centers on Azure Active Directory (Azure AD). Azure AD provides a cloud-friendly, secure, scalable, modern identity solution that can serve cloud-hosted and on-premises solutions alike.
Before discussing what Azure AD is, it can be helpful to understand what it is not. First, Azure AD is not a 100 percent replacement for Windows Server Active Directory. For example, you cannot allocate objects such as printers to Azure AD. If you need the full capabilities of Windows Server Active Directory, consider installing and configuring Windows Server Active Directory on Azure Virtual Machines or potentially Azure AD Domain Services.
Azure AD is a robust, secure, multitenant directory service that provides identity and access management in the cloud. In fact, Azure AD is the directory store for many of Microsoft's premium cloud services, such as Microsoft Office 365, Microsoft Dynamics CRM Online, Windows Intune, and, of course, Microsoft Azure. Much like Windows Server Active Directory provides identity and access management for on-premises solutions, Azure AD does so as a service available in Azure. However, instead of you assuming the responsibility of provisioning and configuring the multiple servers necessary for on-premises Active Directory, Microsoft is responsible for managing the entirety of the Azure AD infrastructure (high availability, scalability, disaster recovery, and so on). As a consumer of the Azure AD service (directory as a service), you decide what users and which of their related information should reside in the directory, who can use the information, and what applications have access to the information.
Azure AD should not be considered a full replacement for Windows Server Active Directory. Instead, Azure AD is a complementary service. If you already have Active Directory on-premises, the users and groups can be synchronized to your Azure AD directory by using Azure AD Connect.
Note Azure AD Connect synchronization services is the successor to DirSync, Azure AD Sync, and Forefront Identity Manager with Azure AD Connector.
Azure AD can be associated with an on-premises Active Directory to support single sign-on (SSO). This can be either true SSO using Active Directory Federation Services (AD FS) to federate the onpremises identity to Azure AD or shared sign-on, in which Azure AD Connect is used to sync a password hash between Active Directory and Azure AD. Shared sign-on is simpler to configure at the cost of a small delay in the synchronization of password changes (synchronization is usually completed in a matter of minutes).
By enabling SSO with Azure AD, organizations are able to provide an easy way for employees (or other users) to access a wide range of software as a service (SaaS) applications such as Office365, Salesforce.com, Dropbox, and more. This topic will be discussed in more detail later in this chapter.
Azure AD is a multitenant directory service. Each tenant is a dedicated instance of Azure AD that you own when you sign up for a Microsoft cloud service (Azure, Office 365, and so on). Each tenant directory is isolated from the others in the service and designed to ensure user data is not accessible from other tenants, meaning others cannot access data in your directory unless an administrator grants explicit access.
It is important to note that Azure AD is not just for cloud or Azure-hosted solutions. Azure AD can be used by both cloud (hosted in Azure or elsewhere) and on-premises solutions. Instead of using technologies like Kerberos or Lightweight Directory Access Protocol (LDAP) to access Active Directory (as you would on-premises), Azure AD is accessible via a modern REST API. This allows a wide range of applications—on-premises, cloud, mobile, and so on—to access the rich information available in the Azure AD directory. For developers, this opens up a vast opportunity that previously, with on-premises solutions, either wasn't possible or was difficult to achieve. By leveraging Azure AD and its Graph REST API, developers are able to easily establish SSO for cloud applications and to query and write (create, update, delete) against the directory data.
Azure AD serves as a key component for identity management in the Microsoft cloud. Azure AD include a wide range of capabilities, such as Multi-Factor Authentication, device registration, RoleBased Access Control (RBAC), application usage monitoring, security monitoring and alerting, selfservice password management, and much more. All of these features are designed to help organizations provide security for cloud-based applications, including meeting required compliance targets, in an efficient and cost-effective manner. The list below provides a brief description of several important Azure AD features that are beyond the scope of this book.
Azure AD is a large topic—encompassing much more than can be included in a single chapter in this book. For more detailed information on Azure AD, please start with the article available at https://azure.microsoft.com/documentation/articles/active-directory-whatis/.
For a deep dive into building web applications that leverage Azure AD, you are encouraged to read the book Modern Authentication with Azure Active Directory for Web Applications by Vittorio Bertocci. More information on the book can be found at https://blogs.msdn.microsoft.com/microsoft_press/2016/01/04/new-book-modern-authenticationwith-azure-active-directory-for-web-applications/.
As of this writing, there are three tiers for Azure AD:
See Also For more details on the Azure AD tiers, please refer to https://azure.microsoft.com/documentation/articles/active-directory-editions/.
It is easy to create your own Azure AD directory. In fact, as mentioned earlier, if you are using a Microsoft cloud service such as Office 365, you already have an Azure AD directory. You can associate a new Azure subscription with an existing directory used for authenticating with other Microsoft cloud services. To do so, sign into the Azure classic portal (http://manage.windowsazure.com) using your existing work or school account (formerly known as an organizational account). If there are no existing Azure subscriptions associated with your account, the portal will return a message indicating this, as seen in Figure 7-1. You will need to sign up for an Azure subscription, which you can do at http://aka.ms/AccessAAD. Once you have an Azure subscription, you will be able to use your work or school account to access the Azure subscription.
Note As of this writing, Azure AD is not yet available in the Azure portal at https://portal.azure.com. As a result, all screenshots and directions in this chapter will refer to the Azure classic portal. C
See Also For more information on managing the directory for your Office 365 subscription in Azure, please see https://azure.microsoft.com/documentation/articles/active-directory-manageo365-subscription/.
If you don't yet have a subscription to a Microsoft cloud service such as Azure or Office 365, the act of signing up for the service will automatically create an Azure AD directory. You cannot use Azure without a directory. If you signed up for Azure prior to July 7, 2013, you likely were automatically assigned a default directory. You can associate your subscription with a different Azure AD directory by using the Azure classic portal. Proceed to the Settings extension in the left navigation area, select your subscription, and then click Edit Directory on the bottom command bar. The resulting dialog box, shown in Figure 7-2, will allow you to select a different Azure AD directory to be associated with the selected Azure subscription.
Figure 7-2 Change the Azure AD directory associated with an Azure subscription.
You can add a new Azure AD directory from the Azure classic portal. To do so, select the New button on the command bar and then navigate to App Services, Active Directory, Directory, and finally Custom Create, as seen in Figure 7-3.
In the resulting Add Directory dialog box, provide a friendly name for the directory, provide a unique domain name, and select your country or region, as shown in Figure 7-4.
One topic that can cause a lot of confusion is the relationship between an Azure subscription and Azure AD. In the simplest of terms, an Azure subscription is a billing (and in some ways a security and management) entity for Azure services such as Virtual Machines, App Services, and so on. An Azure subscription is free—you pay only for services used.
Azure Active Directory (Azure AD) is a multitenant service that hosts a multitude of directories. An Azure subscription is automatically associated with a directory. In other words, a subscription belongs to a directory.
Please see the Active Directory team blog post at https://blogs.technet.microsoft.com/ad/2016/02/26/azure-ad-mailbag-azure-subscriptions-andazure-ad-2/ for a really good explanation of how Azure subscriptions and Azure AD are related.
Notice the domain name associated with the directory: [directory_name].onmicrosoft.com. Every Azure AD directory gets a unique name associated with the *.onmicrosoft.com domain. As a result, every user in the directory would have a name such as email@example.com.
You are not forced to always use the *.onmicrosoft.com domain name. Instead, you can assign a custom domain, one that you own. Once a custom domain is established, users in the directory would reference the custom domain name instead (for example, firstname.lastname@example.org).
The process to associate a custom domain with your Azure AD directory is relatively easy. The Azure AD section in the Azure classic portal will walk you through all the steps in an easy-to-follow wizard. There are three basic steps:
First, select the desired directory in the Azure AD section of the Azure classic portal and then click Domains in the top navigation section. As seen in Figure 7-5, if you don't already have a custom domain, the portal will prompt you to create a custom domain and provide an Add A Custom Domain link to get started.
After you click the Add A Custom Domain link, a dialog box will open, as shown in Figure 7-6, prompting you to add the desired domain name to the list of potential domain names associated with your Azure AD directory.
The next step will be to prove that you own the domain name. Step 2 of the wizard, shown in Figure 7-7, prompts you to add a DNS setting (TXT or MX record) at your domain name registrar. For the purposes of this example, GoDaddy is used; however, the wizard provides a link to an article that provides detailed steps for several popular registrars.
Figure 7-7 Verify domain settings.
For GoDaddy, proceed to the DNS Manager section where you can work with DNS records. There you will need to add a new TXT record (if that was the record type selected in the Azure classic portal). As shown in Figure 7-8, provide the Host, TXT Value, and TTL settings that were also specified in the Azure classic portal wizard.
Click Finish in the GoDaddy editor and then be sure to save the zone file. After adding the TXT record and saving the zone file, you can attempt to verify the domain from the Azure classic portal wizard by clicking Verify. If the verification is successful, you will receive a notification, as seen in Figure 7-9.
It could take 15 minutes for the DNS changes to take effect. In some cases, it might take up to 72 hours for the DNS records to propagate. If you are unable to verify the domain after 72 hours, you should return to the domain registrar site to verify the DNS record information is correct.
Note This TXT DNS record is used only to verify that you own the domain. You can safely delete it later if you like.
After exiting the wizard, you should notice both the custom domain and the default (or basic) domain listed in the Domains section, as shown in Figure 7-10. You can now change the primary domain for the directory to be the custom domain. If you want to add more custom domains, repeat the steps by first clicking the Add button in the command bar. Adding more custom, verified domains will allow you to change the primary domain associated with the default *.onmicrosoft.com domain.
It is possible to create (or be associated with, including being a member of) a maximum of 20 directories. Creating multiple Azure AD directories can be helpful in development and testing scenarios in which you might not have access to the production subscription. When finished with a directory, you can easily delete that directory. Because deleting a directory is a potentially significant action, a few conditions (enforced by Azure) must be met to delete a directory:
To delete the directory, just select the directory and click Delete on the bottom command bar.
After creating the Azure AD directory, a common next step is to add users to the directory. Once users are in the directory, those users will be able to take advantage of Azure AD features such as SSO, access application gallery, and Multi-Factor Authentication (more details of which are provided later in this chapter in the "Multi-Factor Authentication" section).
Users in Azure AD can be one of four types:
See Also For more information on Azure AD B2B capabilities, please see https://azure.microsoft.com/documentation/articles/active-directory-b2b-what-is-azure-ad-b2b/.
To add new users to the directory, there a few different approaches you can take:
When you first create a new Azure AD directory and you are using an Azure subscription associated with a Microsoft account, there will already be one user account in the directory: yours. You can then add users to the directory by going to the Users section in the desired directory and clicking the Add User button on the bottom command bar, as shown in Figure 7-11.
Clicking the Add User button opens a new dialog box that allows you to provide details for the new user. As seen in Figure 7-12, if the user is in your organization, you can select the domain name suffix for that user, either the *.onmicrosoft.com or a custom domain (if configured).
Figure 7-12 Add a user in your organization.
Figure 7-13 shows the next step, in which you will be able to provide more information about the user, such as the user's first and last name, display name, and potentially an administrative role (within Azure AD only—not related to RBAC features in the Azure portal) for the user. You can also enable Multi-Factor Authentication for the user.
See Also For more details on the administrative roles, please reference https://azure.microsoft.com/documentation/articles/active-directory-assign-admin-roles/.
The final step in creating a new user in your organization is to get a temporary password for the user. Clicking the Create button, as shown in Figure 7-14, creates and assigns a temporary password for the newly created user.
After creating the temporary password, the password is displayed, as shown in Figure 7-15, and you have the opportunity to copy it to someplace safe.
The process for adding a new user with an existing Microsoft account is similar. Instead of assigning the user to a domain name associated with your organization, you will use the user's Microsoft account (email address), as shown in Figure 7-16.
Figure 7-16 Add a user with an existing Microsoft account.
After providing the user's email address, you will be able to provide the user's first name, last name, display name, and role, just like when adding a user in your organization.
Finally, when adding a new (external) user who is a user in another Azure AD directory, you will need to provide the name for the user. This is done in the form of the user's email account (or in Active Directory terms, the user's User Principal Name, or UPN), as seen in Figure 7-17. Keep in mind that to select a user in another Azure AD directory, you will also need to be an administrator in the other directory.
Adding external users to your directory copies the display names and user names from the source or home directory to your directory. The users would still authenticate against their home directory, but any changes to the users' properties (email address, display name, job title, and so on) do not propagate to your directory.
To determine where users in the directory originated, look at the Sourced From column in the Users section, as seen in Figure 7-18. If users were synchronized from a Windows Server Active Directory using Azure AD Connect sync, the Sourced From column would indicate Local Active Directory. Similarly, users from Office 365 would have the value Office 365 in the Sourced From column, and users created in Azure AD would have the value Microsoft Azure Active Directory in the Sourced From column.
It is a common practice in Active Directory to organize users into groups. Groups make it easier to assign rights or grant access to resources. Instead of granting access for each individual user, access is granted to the group of which the user is a member. The user inherits the access rights of the group.
You can also create and manage groups in an Azure AD directory. Groups in Azure AD can be helpful when granting access to SaaS applications available in the Azure AD application gallery. The Groups section of the selected Azure AD directory allows you to create and manage groups. If no groups exist, create a group by clicking the Add Group button on the bottom command bar or the Add A Group link, as shown in Figure 7-19.
In the Add Group dialog box, you can provide a name, type (a security group or an Office 365 group), and description for the new group, as seen in Figure 7-20.
To add users to the group, select the group name to open a new screen that allows you to manage the group and then click the Add Members link or the Add Members button on the bottom command bar, as shown in Figure 7-21.
As seen in Figure 7-22, the Add Members dialog box enables you to select users or other groups in the current directory to add as members to the group selected.
Azure Multi-Factor Authentication (MFA) provides additional security for on-premises or Azure-hosted solutions. For the purposes of this chapter, only Azure-hosted solutions are discussed. Azure MFA works by injecting a second authentication challenge that the user must complete successfully. Azure MFA complements a password-based authentication challenge (something you know) with a challenge based on something you have: a phone call, text message, or mobile app notification. Having multiple layers of protection makes it harder for attackers to access and compromise the account.
MFA comes in a few different varieties. Azure AD Free and Azure AD Basic support MFA for Azure administrators, and Azure AD Premium adds MFA support for users. MFA for Azure administrators provides security for their administrative account, thus adding security related to creating and managing resources such as Azure Virtual Machines, Azure App Services, and so on. MFA for users provides additional security for users signing into applications configured to support Azure AD.
To begin using the full capabilities of Azure MFA, you will first need to add a Multi-Factor
Authentication provider (MFA provider) in Azure AD. To add an MFA Provider, go to the Active Directory section in the Azure classic portal and then click the Multi-Factor Auth Providers area. If no providers exist, you are presented with an option to create one, as seen in Figure 7-23.
Note A Multi-Factor Authentication provider is needed if you do not have an MFA license through Azure MFA (licenses purchased separately), Azure AD Premium, or Enterprise Mobility Suite (EMS). Azure MFA is included in Azure AD Premium and EMS. If you have licenses available, you do not need to create a Multi-Factor Authentication provider.
Figure 7-23 Create a new Azure Multi-Factor Authentication provider.
After creating a new Multi-Factor Authentication provider, you can customize many advanced features of the service by clicking the Manage button, shown in Figure 7-24, to launch a new browser window that loads the Azure Multi-Factor Authentication management portal.
Note Azure MFA is a result of Microsoft's acquisition of PhoneFactor in October 2012. The Azure MFA management portal continues to reside on a phonefactor.net domain.
See Also For more information on Azure MFA, please refer to http://azure.microsoft.com/documentation/services/multi-factor-authentication/.
Recall from earlier in this chapter that when creating a new user, you had the option to enable MFA. Selecting the user's name and then the Manage Multi-Factor Auth button on the command bar, as shown in Figure 7-25, launches a new browser window and loads a site allowing you to manage MFA settings.
Alternatively, if the user is not enabled for MFA, you can enable it from this site by selecting the desired user(s) and clicking Enable, as shown in Figure 7-26.
Figure 7-26 Enable Multi-Factor Authentication for selected users.
If MFA is enabled for a user, and the user attempts to access the Azure portal (the user must also be a coadministrator on the Azure subscription), the user will be presented with an additional security verification step. As seen in Figure 7-27, the first time the user attempts to log in, the user will be asked to specify the desired contact method—phone, text message, or mobile application—and complete the necessary steps.
On subsequent login attempts, the user will need to provide the requested additional security verification answer. As shown in Figure 7-28, a text message verification code is requested.
The Azure AD application gallery provides access to more than 2,500 popular SaaS applications such as Box, DocuSign, Salesforce, ServiceNow, Google Apps, and many more. Instead of IT administrators configuring access to each application separately and potentially managing various disparate logins, Azure AD simplifies the process by enabling SSO for the applications.
Azure AD supports three options for SSO:
To add gallery applications to your Azure AD directory, first select the desired directory and then the Applications section. If you don't have any applications in the gallery, click Add An Application to open a new dialog box, as shown in Figure 7-29, presenting you with two options: add an application you are developing or add an application from the gallery.
If you or another member of your organization develop an application in which you would like to take advantage of Azure AD features (for example, SSO, ability to query the Azure AD Graph API, and so on), then select the first option.
Selecting the second option will allow you to register third-party SaaS applications with your Azure AD directory. As can be seen in Figure 7-30, there are many applications available. Use the filter box to search by name for a specific application.
After you select the desired application(s), each application will appear on the list in the Applications section. As shown in Figure 7-31, you can add an application by clicking Add, and you can remove an application by selecting the application and clicking Delete.
Figure 7-31 List, add, and delete applications.
As mentioned previously, there are different ways applications can leverage Azure AD for SSO. For example, Box provides all three options (Azure AD Single Sign-On, Password Single Sign-On, and Existing Single Sign-On), and Twitter provides only Password Single Sign-On and Existing Single SignOn. Follow the on-screen guidance, as shown in Figure 7-32, to configure SSO for the selected application.
Some applications, such as Box, have the ability to provision (create) users automatically into the application once the user is assigned access in Azure AD. If a user is deleted from Azure AD or the user's access is revoked, this change is automatically propagated to the SaaS application. This can greatly simplify IT administration responsibilities.
To grant Azure AD directory users access to the selected application, first click Assign Accounts to access a new screen allowing you to assign or revoke access. As shown in Figure 7-33, select the desired user and then click either Assign or Remove on the bottom command bar.
For applications that use Password Single Sign-On, after assigning users you will be presented with an option to allow users to enter and update their own credentials for the application, or you can enter them on their behalf, as shown in Figure 7-34.
See Also For a step-by-step tutorial on integrating SaaS applications with Azure AD, please refer to https://azure.microsoft.com/documentation/articles/active-directory-saas-tutorial-list/.
Once users are assigned access to the SaaS applications available via the Azure AD application gallery, they can access those applications from the MyApps for Azure Active Directory site available at http://myapps.microsoft.com. Users will need to first authenticate with their Azure AD credentials (either *.onmicrosoft.com or associated custom domain name) to gain access to the site. If the user is already signed into a Microsoft cloud service site (Azure, Office 365, and so on), the user will automatically be signed into the MyApps site. As can be seen in Figure 7-35, there are two main sections of the site: Applications and Profile.
The Applications section provides a tile for each application to which the user has been granted access. If password-based SSO was selected as the authentication method when the application was added to the organization's Azure AD directory, the user might be prompted to install a browser component the first time the application is accessed.
To access the desired application, users need to click the application's tile. If password-based SSO was selected, users will be prompted to enter their credentials for the SaaS application, unless the administrator who added the application did that on the users' behalf. The users are then redirected to the application and signed in using the appropriate credentials.
The Profile section, shown in Figure 7-36, provides some basic details about the current user and an easy way for users to change their passwords.
Figure 7-36 User profile in MyApps site.