Microsoft AZ-104 Certification Exams - Identity: Azure Active Directory

Category: Microsoft AZ-104 Certifications Page 1 of 3

Azure Active Directory – Identity: Azure Active Directory

As mentioned in the introduction of this chapter, Azure AD is Microsoft’s cloud-based identity and access management (IAM) solution. Azure AD is an especially useful solution for IT admins, developers, and subscribers of various Microsoft solutions (such as Microsoft 365, Dynamics 365, and Azure). Primarily, Azure AD deals with helping employees to sign-in to various resources such as O365, M365, Dynamics, Azure, etc. However, the integration does not stop here; you can integrate Azure AD as the IAM solution for third-party applications and your internal applications as well. Developers are constantly working on integrating Azure AD as the IAM solution because of the increased reliability it provides. Since this book is about Azure administration, we will focus on how Azure AD is intended to help IT admins.

Benefits

Let’s explore the different benefits of Azure AD and why organizations should consider Azure AD as the IAM solution.

SSO to Cloud and On-Premises Applications  Having too many credentials for different applications increases the complexity and results in a higher chance of human error because an SSO solution will help users to sign in to all cloud applications, on-premises applications, and devices using their corporate credentials. Azure AD is not only meant for Microsoft Stack, but for thousands of SaaS applications such as Dropbox, ServiceNow, DocuSign, etc.

Easily Extend On-Premises Active Directory to the Cloud  When organizations move from on-premises to the cloud, there is a need to synchronize the users with the cloud. Otherwise, users will end up with two credentials, one for on-premises and another one for the cloud. To avoid this scenario and to provide a seamless SSO experience, Azure AD allows administrators to synchronize users, groups, passwords, and devices across both on-premises and the cloud. This is accomplished using a tool called Azure AD Connect that needs to be installed on your on-premises domain controller or any other domain-joined server with Windows Server 2012 or later, and it will help with the synchronization.

Cross-Platform Support  Regardless of what platform the user is using, be it iOS, Android, Windows, Linux, or macOS, the sign-in experience is going to be the same, and the users can sign-in to their applications using their work credentials.

Increase Security of Your On-Premises Applications  You can use the Azure AD Application Proxy service to access your on-premises applications via a secured remote access. The best part is you do not have to expose any additional ports on your on-premises firewalls; the access is managed by application proxy endpoints. The access can be tightened using multifactor authentication and conditional access policies.

Better Monitoring and Data Protection  Azure AD amplifies the overall security posture of your environment by providing unique identity protection features. Azure AD Identity Protection comprises several features including suspicious sign-in activity, risk alerts, etc. These triggers can be further integrated with conditional access policies to make business decisions. In addition to these capabilities, administrators can leverage security reports, sign-in activities, and potential vulnerability reports that are available off the shelf without the need to deploy any additional components.

Self-Service Capabilities  If you have worked as an IT administrator, you know most of the calls to the help desk will be regarding password resets. Azure AD offers a feature called Self-Service Password Reset by which users can reset their own passwords with the help of an authentication method such as phone, email, security questions, or a combination of these. IT admins need to enroll users into the SSPR program before they can use this feature. Enrolling is also self-serve, and the user will be prompted to verify the authentication methods. Enabling SSPR in your environment can elevate the security and reduce help-desk engagements.

If you are using Office 365, Azure, or Dynamics 365 in your environment, knowingly or unknowingly you are interacting with Azure AD to complete the authentication process.

We have been talking about Azure AD for a while now, and it is time that we understand the concepts that are part of Azure AD.

Concepts – Identity: Azure Active Directory

Understanding the various terminologies that are related to Azure AD is the first step in learning Azure AD. The following are the Azure AD concepts:

Identity  An object that can interact with Azure AD and get authenticated is called an identity. A user is an exceptionally good example of an identity; to get authenticated, a user will present the username and password to Azure AD. Upon receiving these credentials, Azure AD will substantiate and confirm if the authentication was successful. Servers and applications can also use their identity to authenticate with Azure AD; since these can be authenticated, they are also called identities. When it comes to servers or applications, they use certificates or secrets for completing the authentication.

Account  Any identity that has data associated with it is called an account. For example, if we take a user named John Doe, the user will have different data attributes associated to it such as user principal name, sign-in name, manager name, department, etc. All the data associated to the user identity will make the identity an account. Since identity is required for mapping these attributes, you cannot have an account without an identity. The account can be on-premises as well as in the cloud.

Azure AD Account  Usually known as work or school accounts, these accounts are provisioned in Azure AD or via other cloud services such as Office 365, etc. The data associated to these identities is stored in Azure AD and can be used to log in to services that use Azure AD as the authentication provider.

Azure Subscription  This is the container created in Azure to separate billing and environments. An account can have multiple subscriptions that can be used to create isolated environments and billing boundaries. Each subscription you create will be mapped to a tenant, and it is always a one-to-one mapping. You can always move subscriptions across tenants if you have a multitenant environment.

Azure AD Tenant/Directory  The term tenant means a single instance of Azure AD denoting a single organization. When you sign up for any Microsoft cloud service (Azure, O365, etc.), a dedicated instance of Azure AD is provisioned for you. There will be a unique name associated to this tenant that will have the suffix onmicrosoft.com and a unique ID assigned to the tenant called the tenant ID. An organization can create multiple directories/tenants for creating disparate environments or realms with different users and groups.

Now that we are familiar with the concepts related to Azure AD, the next question you will have in your mind is how Azure AD is different from Active Directory Domain Services.

Resource Groups 2 – Compliance and Cloud Governance

 Listing Resource Groups from the Azure Portal

  1. Sign in to the Azure portal.
  2. Select the Resource Groups blade, and you will be able to list all the resource groups in your subscription. You have already seen how to list the resources groups; if you can’t recall, refer to Exercise 2.1, step 2, to see the resource groups (if there are any).
  3. You can open any resource group by clicking the name of the resource group. If the resource group is a new one, it will be empty. You will see a Create Resources button to add resources to the resource group.

EXERCISE 2.3
 Deleting Resource Groups from the Azure Portal

  1. Sign in to the Azure portal.
  2. Select the Resource Groups blade, and you will be able to list all resource groups in your subscription.
  3. Open the resource group you would like to delete. Once you are inside the resource group, you will be able to see the Delete Resource Group option that can be used to delete the resource group. You need to enter the name of the resource group to confirm the deletion as this action cannot be undone.

So far, we used the Azure portal to perform the management actions. You can also use Azure PowerShell or the Azure CLI to perform the same tasks. As of now, you can delete only one resource group at a time from the Azure portal. By using scripting, you can perform the management actions in bulk. It’s recommended that you refer to the documentation to learn how to use one of the scripting languages if you prefer to automate your actions in bulk.

In Figure 2.6, you can see that we have created the resource group using the New-AzResourceGroup command along with the location and name parameters, listing resource groups using the Get-AzResourceGroup command, and finally deleting one of the resource groups using the Remove-AzResourceGroup command.

FIGURE 2.6 Managing resource groups using PowerShell

Similarly, you can perform the command using the Azure CLI, as shown in Figure 2.7.

With that, we will move on to the next topic, which is management groups.

Azure AD vs. Active Directory Domain Services – Identity: Azure Active Directory

You might have already worked or heard about Active Directory Domain Services (AD DS) in your on-premises environment. If you have not heard about AD DS, this is a deployment of the Active Directory service/role on Windows Server. The server can be a physical or virtualized one. The primary focus of AD DS is to work as a directory service. There are several other components of Active Directory that get installed along with the directory service such as Active Directory Lightweight Directory Service (AD LDS), Active Directory Federation Services (AD FS), Active Directory Certificate Services (AD CS), and Active Directory Rights Management Service (AD RMS). You can also implement AD DS in Azure by installing the Active Directory Domain Services role on your Windows virtual machines deployed in Azure. This is not a recommended scenario unless you have a special scenario that requires AD DS deployment; for all other scenarios, Azure AD is recommended.

At first look, AD DS and Azure AD may look the same and both can be used for authentication and offer directory services; however, there are some differences in the way things work under the hood. The key point to understand here is if you install the AD DS role on an Azure Windows virtual machine, it is not equivalent to Azure AD. A lot of beginners have this misconception and assume both are the same. Well, that is wrong. The following are some of the key differences that make Azure AD different from AD DS:

Hierarchy  A flat structure is used by Azure AD to represent or provision the users and groups. Therefore, organizational units (OUs) and Group Policy objects (GPOs), which exist in AD DS, do not exist in Azure AD.

Federation Services  Azure AD supports Federation Services as an authentication method, and you can further integrate with third-party providers such as Twitter, Facebook, etc. On the other hand, in the case of AD DS, we can set up federation with another domain controller or forest only, and third-party integration is not supported.

Lack of LDAP  In AD DS, we used a protocol called LDAP to query users, groups, or objects in Active Directory. In the case of Azure AD, since this is an HTTP/HTTPS-based service, we will be using the REST API for querying instead of LDAP.

Lack of Kerberos  AD DS deployment uses Kerberos authentication; however, Azure AD uses HTTP/HTTPS protocols like SAML, OpenID Connect for authentication, OAuth for authorization, and SAML. Developers can choose any of these communication protocols while they design security for their applications.

Management  Azure AD is a managed service, and it is an underlying infrastructure; the availability is managed by Microsoft. If AD DS is deployed on an Azure Windows virtual machine, the configuration, management, virtual machine patching, updates, upgrades, and other maintenance tasks should be taken care by the end customer.

Azure AD: Licensing – Identity: Azure Active Directory

You have seen that Azure AD offers a lot of add-on features more than legacy identity and management solutions. These features come with a price, and not all organizations need all these features. Licenses are categorized based on the number of premium features it supports. There are four editions of Azure Active Directory.

Azure Active Directory Free  As the name implies, this is the free version of Azure Active Directory and offers minimal features such as user management, group management, Azure AD Connect for syncing on-premises identities, basic reporting, SSO, SSPR, etc. If you have not purchased any Azure AD license, this is going to be your default edition.

Azure Active Directory Microsoft 365 Apps  If you have O365, this edition of Azure AD is automatically provisioned for you. Besides the features offered by Azure AD Free, this edition offers additional functionalities such as IAM for Microsoft 365 Apps, branding, MFA, etc.

Azure Active Directory Premium P1  Azure AD Premium P1 offers all the capabilities of Azure AD Free and some additional premium features that can increase the overall security of your environment. Dynamic groups, self-serve group management, Microsoft Identity Manager, and password writeback are some of the additional features offered by Azure AD Premium P1.

Azure Active Directory Premium P2  This is the top edition of Azure AD and offers all features in the P1 and Azure AD Free editions; additionally, Identity Protection and Identity Governance are offered.

Table 1.1 provides a quick comparison of all editions of Azure AD and the features offered by each edition.

TABLE 1.1  Comparison of Azure AD Editions

FeatureFreeMicrosoft 365 AppsPremium P1Premium P2
Directory objects500,000UnlimitedUnlimitedUnlimited
Single sign-onUnlimitedUnlimitedUnlimitedUnlimited
Core identity and access management✓️✓️
Business-to-business collaboration✓️✓️✓️✓️
Identity and access management for Microsoft 365 apps✓️✓️✓️
Hybrid identities (password writeback)✓️✓️
Advanced group access management✓️
Conditional access✓️✓️
Identity protection✓️
Identity governance✓️

The pricing of Azure AD licensing can be reviewed on the Azure AD pricing page.

https://azure.microsoft.com/en-us/pricing/details/active-directory

In addition to these editions, if you already have an Office 365 E3/E5 license, then you can use the premium features of Azure AD, and you do not have to pay for these licenses separately. P1 is included in E3, and P2 is included in E5, respectively.

Since you have the basic understanding of the editions of Azure AD and how they are different from a traditional Active Directory deployment, let’s talk quickly about custom domains in Azure AD.

Resource Groups – Compliance and Cloud Governance

A resource group is a container used for the logical organization of resources in Azure. These resources may be part of the same solution or based on any grouping that you prefer. Some organizations prefer to keep all services that are part of a solution in a single resource group. For example, say you are hosting a payroll application that has a virtual machine, SQL database, and storage. You can group these resources so that you can manage the lifecycle of them together. Some organizations prefer to keep resources of the same type together, for example, all virtual machines in a single resource group or all databases in a single resource group. This strategy would help them to manage the access to all virtual machines or databases easily.

Resource groups make it easy to deploy, delete, or update resources in bulk. Instead of performing operations on these resources one by one, you could directly perform the action on the resource group, and all resources that are part of the resource group are updated with the action. Assume you have 135 services deployed to your subscription and now your management is asking you to delete these 135 services. You could select all services from the portal or write a script in PS/CLI to delete the resources. Another easier workaround is to delete the resource group so that all the resources are deleted. This is not an action that is recommended in a production environment, as this delete action cannot be reversed, and the deleted services cannot be recovered. It’s recommended that you are cautious and vigilant before deleting a resource group.

A resource group contains the metadata about the resources that are part of the resource group. You can have resources from different regions be part of the same resource group; however, the metadata about these resources will be stored in the region of the resource group. An example is if the location of your resource group is East US and you have a couple of VMs from West US that are part of the resource group. Another is if the East US region is facing an outage and you are making any changes to the VM. Even though the VMs are from West US, the metadata cannot be updated as the East US (region of the resource group) is facing an outage.

Now we will see how you can manage (create, list, open, and delete) a resource group from the Azure portal; see Exercise 2.1, Exercise 2.2, and Exercise 2.3.

EXERCISE 2.1
 Creating a Resource Group from the Azure Portal

  1. Sign in to the Azure portal.

2. Select Resource Groups and click Create.

3. Input the following values:

  • Subscription: Select your subscription.
    • Resource Group: Enter a name for the new resource group.
    • Region: Select the region for the resource group such as East US, India Central, UK South, etc.
  1. Clicking Review + Create will take you to the validation phase.
  2. Once the validation is done, you will see the Create button. Click Create, and your resource group will be created.

EXERCISE 2.2

Custom Domains in Azure AD – Identity: Azure Active Directory

Every tenant will have two properties that make it unique from other tenants created by other organizations (tenant ID and the tenant initial domain). By default, when you create a tenant, there will be a default domain that will look like <yourdomainname>.onmicrosoft.com. This initial domain cannot be changed or deleted once the tenant is provisioned. Because of the uniqueness of this domain name, sometimes you will not get the domain name that you are looking for. For example, when you try to sign up for a Gmail or Outlook mailbox, you get an option to choose a username. Though you have a choice, username allocation works based on the availability of the username. Sometimes you might try to get an email with your name, and you might end up with Gmail suggesting some usernames having random numbers because the one you asked for is not available. The same concept applies to the initial domains as well; if the name you request is taken, then you must append some letters or numbers to make the name unique.

 If the tenant was created while you signed up for the Azure subscription using your email address, then Microsoft Azure uses your email address and considers that as the initial domain name. You can create additional domains, and at that point you will get an option to choose the initial domain name. Refer to the “Managing Multiple Directories” section in this chapter to understand multitenant environments.

The problem with this approach is that all the users you create will have this initial domain assigned to their username. Since you have added letters and numbers to make it unique, this initial domain is hard to remember and not user friendly. To resolve this issue, you can use custom domains in Azure AD.

Using custom domains, you can use your domain that you created with the domain registrar. Adding custom domains requires you to validate and prove to Azure that you own the domain. This verification can be completed by adding a TXT/MX record to your DNS domain. The value for this DNS record will be given by Azure. When you add a domain to Azure AD, it will be unverified. After you add the DNS record to your DNS zone, you can initiate the verification request, and Azure AD will start querying your domain to verify if the value given by Azure is returned as the answer for the DNS query. Once the record is returned, Azure AD will mark the domain as verified, and you will be able to use the domain when you create users. You can have multiple domains and keep one of them as your primary.

Nevertheless, this is not a daily task for the administrators, and this is a one-time setup. In the future, if more domains need to be linked, then you may have to repeat the verification process. This topic is not part of the exam; however, understanding custom domains will help you set up your test environment with a custom domain. In this chapter, the exercises will have a custom domain name instead of the onmicrosoft.com domain name. I hope that this quick introduction of custom domains will help you understand why your test environment has an onmicrosoft.com domain and the exercises have a proper domain name.

If you would like to add your custom domain to Azure AD, please follow the process outlined in this documentation:

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain

On that note, we will start with users and groups in Azure AD.

Users and Groups – Identity: Azure Active Directory

Users and groups are the primary objects of every IAM solution, and Azure AD also has a user and group management system, which is the backbone for access management. You have seen what an account is; just to refresh what we discussed; an account is an identity that has data associated to it. In Azure AD, you have user accounts and group accounts for managing users and groups. Let’s get started with user accounts and see the operations that are available for administrators.

User Accounts

As the name suggests, user accounts consist of user identities, which will be used by users to log in to services such as Azure, O365, Dynamics 365, SaaS applications, and other third-party applications that are integrated with Azure AD.

 You should create a subscription for testing all labs in this book. You can create a Free Trial subscription. If you are using your personal email address to sign up for the subscription, a new tenant will be automatically provisioned for you. All operations can be performed on that tenant.

Now that you know what a user account is, it is time to see how you can see users in our directory.

Viewing User Accounts

If you are working on a new directory that was set up for testing the exercises in this book, then you won’t have any additional users apart from the account that you used to sign up for the subscription. However, in a production environment, there will be hundreds of users. As an administrator, you will be asked to verify if the account exists in Azure AD or get information about a particular user. Hence, knowing how to view user accounts is particularly important in an IT admin’s daily job. We will follow a step-by-step process to view the users in your directory, as shown in Exercise 1.1.

EXERCISE 1.1
 Viewing Users in Your Directory  

  1. Open your browser (Microsoft recommends that you use the latest version of your favorite browser) and navigate to the Azure portal, which is available at https://portal.azure.com.
  2. A sign-in screen will be presented to you. Sign in using the email address that you used to create the subscription. The data you enter (username and password) will be sent to Azure AD. If the credentials are correct, then you will be logged in.

3. Now that you are in the Azure portal, you can click the hamburger icon at the top-left corner and click Azure Active Directory.  

4. Selecting Azure Active Directory will take you to the Overview blade of Azure Active Directory. This blade gives you some idea about certain aspects of your Azure AD such as the tenant ID, tenant name, primary domain associated to your tenant, edition of Azure AD, and number of users, groups, applications, and devices. If you scroll down, you will see more information such as your account, Azure AD connect, secure score, etc. The graphic here shows the overview of the tenant that is used for the demonstration.

If you take a close look at the graphic, you can see at the top the option that will let you create, manage, and delete tenants. These options are quite useful if you are managing a multi-tenant environment. One thing to note here is that deleting a tenant requires you to cancel all active Azure subscriptions that are part of the tenant. You cannot delete a tenant when there is an active Azure subscription associated with that tenant. Since we are working on user management, let’s shift our focus to the Users blade under the Manage section.

5. Once you click the Users blade, you will be presented with the All Users view. Your view might be different from what is shown here as it is displaying the users in the demo tenant.

6. If you click any user, you will be presented with the details of the user such as name, user principal name, job title, department, manager, etc., along with the creation date and last sign-in date.

In this section you saw how to view the existing users in the directory and find the details of a user. Now that you know how to find a user in the directory, let’s see how to add a new user to the directory.

Adding Users 2 – Identity: Azure Active Directory

Additionally, we need to keep a couple of points in mind while managing users.

  • You must be a Global Administrator of the tenant to manage the users. This is one of the Azure AD roles that we will discuss later in this chapter. The Global Administrator role is like a superuser role and should be granted to users who need to manage all aspects of Azure AD. There are other roles like User Administrator who can manage the users, but this can be used only for managing non-admin accounts.
  • While creating a username, the name and password are the only mandatory options. You have two choices with password. First, you can let the system generate a password for the user. The second option is to bring your own password. In both cases, the user will be asked to change the password during the first sign-in, and as an administrator, you should be finding a way to securely share the password with the new user. The commonly used method is to email the new user’s manager.
  • Even though the users can be deleted (will be covered in the “Deleting and Modifying Users” section), you can restore these users within 30 days from the deletion date.

Now that we are clear about the different user types and key points, let’s create users in Azure AD, as shown in Exercise 1.2.

EXERCISE 1.2
 Creating Users in Azure AD

  1. Navigate to the All Users blade inside Azure Active Directory. You can follow the steps 1–5 of Exercise 1.1 to reach the All Users blade.
  2. Once you are in the All Users blade, you can click the New User option.

3. Selecting New User will display a window to input details of the new user you intend to create. You will be presented with two options, Create User and Invite User.

  1. Selecting Create User will help you create a cloud identity that will exist only in Azure AD. On the other hand, if you select Invite User, you can invite a person from another Azure AD or a person who doesn’t have an Azure AD account (Guest user) via an invitation process. In this exercise, we will choose Create User as our plan is to create a cloud identity user type.
  2. Here the username, name, and password are the mandatory fields. You can fill in the fields First Name, Last Name, Department, Job Title, Contact Info, Profile Picture, etc., if you’d like; they are optional. In the previous graphic, you can see that we have left Password as “Auto-generate password,” which means that the system will generate the password for the user. You can see the password by enabling the Show Password option.
  3. Since we have filled the mandatory fields, we can click Create to provision the user. Within a couple of seconds, you will get a notification that the user is created, and the new user will be visible in your All Users blade.

You have successfully created a new user in the Azure AD. As of now, we have covered two exercises where you are viewing and adding users to Azure AD. As an administrator, your responsibility does not stop here; in your daily tasks you will be asked to delete users when someone leaves the organization, modify user attributes when they move to a different department, or change their location. To give you the idea of how to delete and modify users, let’s head to the next section.

Adding Users – Identity: Azure Active Directory

In an enterprise environment, user insertion happens frequently, and cloud administrators are responsible for this. Whenever a new employee joins the organization, administrators are required to create their account, add the necessary licenses, complete their profile, set up their initial password, etc. In this section, we will add users from the Azure portal to understand the user insertion process. Before we start the exercise, it is important you know the user types that are available in Azure AD. There are three types of users in Azure AD.

Cloud Identities  As the name implies, these are identities that are created in Azure AD and exist only in Azure AD. In the upcoming exercise, we are going to create a user called John Doe in Azure AD. This user is going to be a cloud identity as the user will exist only in Azure AD. Another point to note here is that the user can be part of another Azure AD as in an Azure AD of another organization. For instance, assume that there is a company abc.onmicrosoft.com with a user called Jane Doe. Jane Doe can be added to another company’s Azure AD, say, xyz.onmicrosoft.com, through an invitation process also known as business-to-business collaboration. In this case, Jane Doe is a cloud identity of abc.onmicrosoft.com and she is added to xyz.onmicrosoft.com for collaboration. When Jane’s account is deleted from her primary directory (abc.onmicrosoft.com), her presence in the other directory is not automatically removed; we have to perform this action manually.

Directory Synchronized Identities  As mentioned earlier, one of the features in Azure AD is that you can synchronize your on-premises Active Directory to Azure AD. If you have an identity that is synchronized, then you will see Yes in the Directory Synced column for the user in the All Users view (Figure 1.1).

FIGURE 1.1 Distinguishing directory synchronized users

Guest Users  These are accounts that exist outside of Azure. These include Microsoft accounts (earlier known as Live accounts) or accounts from other identity providers and accounts from other organizations. The identities are not part of your organizational Azure AD; they need to be invited to your tenant for collaboration. These accounts will be shown as Guest if you look at the User Type value of the user (refer to Figure 1.1). Once the collaboration is no longer required, you can delete these accounts from your user list, and the access will be revoked.

Page 1 of 3

Powered by Dianne & Theme by Diannehill