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

Category: Users and Groups Page 1 of 2

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.

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

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.

Inviting Users – Identity: Azure Active Directory

In the “Adding Users” section, we discussed several types of users. If you recall, we talked about Guest accounts (Microsoft accounts and users from external Azure ADs). These users need to be invited to your tenant. Recipients can redeem the invitation and join your tenant for collaboration.

In the All Users blade, you have an option to add a new Guest user. Clicking New Guest User will redirect you to a screen similar to Figure 1.2.

FIGURE 1.2 Inviting users

 You can also add a guest user by clicking New User and then selecting the Invite User radio button instead of Create User.

The only email address is the mandatory field, and you can even customize the personalized message. By clicking Submit, this message will be appended to the email invitation, which will be triggered to the recipient, as shown in Figure 1.3.

A sample invitation has been added for your reference (refer to Figure 1.4).

These users can be easily spotted in the All Users blade by looking at the User Type column. You can further add a filter in the blade as shown in Figure 1.5 to list all the Guest users in your tenant.

FIGURE 1.3 Customizing the invite

FIGURE 1.4 Invitation for Guest user

FIGURE 1.5 Filtering Guest users

So far, you have been working on user accounts and different operations that administrators can perform for managing users. Basic administrative tasks are limited not only to user management but can include group management as well. In the next section, we will talk about group accounts in Azure AD.

Group Accounts

When it comes to access management, applying permissions or roles to each user one by one is cumbersome, so to solve this complexity, we have groups in Azure AD. We can group users to create group accounts and then apply the permissions or roles to the group so that all members of the group get that access. Group accounts make access management easier. You can also synchronize groups from on-premises to the cloud, the same as with users.

Azure AD allows you to create two types of groups, security groups and Microsoft 365 Groups. Let’s understand the differences between these types.

Security Groups  Groups play an inevitable role in access management. Security groups can be used to control access to resources easily. For instance, you can create a security group called All HR and give access to all HR-related resources. As an administrator, the advantage here is you do not have to manage individual access; this can be controlled at the group level. Security groups require the Azure AD administrator to perform management actions.

Microsoft 365 Groups  Microsoft 365 groups serve the same purpose as security groups; however, they provide additional capabilities such as access to a shared mailbox, shared calendar, SharePoint, and more. You can extend the collaboration and provide access to external users as well. Unlike security groups, both users and admins can use Microsoft 365 groups.

Another point to understand here is about membership to groups. You can add users as well as groups (nested groups) to a group as members. The rights can be accessed in three diverse ways, as follows:

Assigned  This one is straightforward; this will let you add users (or groups) to the group as members. This type of addition is also known as direct membership.

Dynamic User  Group memberships are controlled using member attributes; using them we can dynamically add or remove users from a group. For example, you can have a rule like if the department of a user is HR, then that user should be added to the group All HR. Here Azure constantly reviews user attributes. If a new user is added with the department as HR, then Azure will add that user to the All HR group. Similarly, when someone leaves the department, Azure automatically removes the user from the group. This is especially useful for administrators, as they do not have to remove or add access whenever a new user is added or removed; but they must make sure that the attributes are added to the user correctly.

Dynamic Device  This is applicable only in the case of security groups and is like the dynamic user concept. The primary difference is that instead of looking at the user attributes, here you are looking at the device attributes. You can register or join our devices to Azure AD, and based on the device attributes, the group membership can be controlled; we will cover AD Join later in this chapter.

Now that you are familiar with the membership types, let’s go ahead and perform some hands-on tasks related to groups.

Adding Microsoft 365 Groups in Azure AD – Identity: Azure Active Directory

In the previous exercise, we created security groups. It is time that we take the exercise to the next level by creating a Microsoft 365 group and adding users dynamically based on rules.

  1. Before you create the group, you need to add some new users using the bulk create method. If you cannot recall the process, perform the steps in Exercise 1.4 to accomplish bulk creation. The following is a sample file used for creation and note that here we are using the usageLocation and department headers to add the usage location and department of the users. These attributes will later be used to build our dynamic rules. Upload the file and create the users before you create the group.

2. As you performed in Exercise 1.6, you need to reach the New Group window and add properties as follows:
a. Group type: Microsoft 365 (as we need to create a Microsoft 365 group).
b. Group name: All HR (a group for all users whose department is HR).
c. Group email address: This is a required field as all Microsoft 365 groups should have an email address. You can add something like “all-hr” and the domain will be auto populated based on your tenant domain.
d. Group description: This field is optional; if you need to add a description about the group, feel free to add it.
e. Membership type: Dynamic User (as we are going to use dynamic queries to add users).

    f. Owners can be selected in the same fashion as we did in the case of security groups (refer to Exercise 1.6 step 2.f).
    g. The next option is to define the dynamic query for the user. If you take a closer look at the previous graphic, at the bottom you can see there is an option to add a dynamic query. Click that, and you will be taken to the dynamic membership rules editor.
    h. Based on the properties you are selecting, corresponding rules are created. In our example, we are adding the property “department” EQUALS “HR.” We can add more expressions by clicking Add Expression.
    i. Azure Portal will automatically generate the rule syntax based on our selection. The rule syntax for what we selected here is user.department -eq “HR”. Once you have verified the rules, click Save to save the rule.

    1. Wait for a couple of minutes, and the members of the group will be automatically added based on the rule you configured.

    4. Let’s try to create another group called India Marketing where we will set up the rule using an additional expression. The final syntax will be (user.department -eq “Marketing”) and (user.usageLocation -eq “IN”), as shown here.

    5. You will see that the members matching the rule are added to the Members blade

      If you completed both the exercises, by now you know how to create security groups and Microsoft 365 groups. Now let’s see how to delete or modify the existing groups.

      Deleting Groups – Identity: Azure Active Directory

      Deleting groups is a straightforward process; however, you need to perform this action with caution because deleting a group in production may cause serious repercussions on access management. Some scenarios where you will need to delete a group include the following:

      • You selected the wrong group type while creating the group. This selection cannot be modified after creation; the only option is to delete the group and re-create the group with the right type.
      • You have a duplicate group.
      • You no longer need the group in your environment.

      If you want to delete a group, you can navigate to Azure Active Directory ➢ Groups ➢ All Groups and open the group you want to delete. Clicking the Delete button as shown in Figure 1.6 will delete the group.

      FIGURE 1.6 Deleting group

      Updating details in a group is no different than updating the user properties. You can add or remove users any time from security groups or Microsoft 365 groups with an assigned membership type. However, in dynamic membership groups, you cannot manually add or remove users. The member management is completely managed by dynamic rules that you create. Azure gives you the option to modify the dynamic rules of your existing group without the need to re-create the group.

      Now that are familiar with the user and group accounts in Azure AD, we will talk about the roles in Azure AD.

      Azure AD Roles

      Azure AD roles are used to manage the permissions that can be assigned to users. You can assign roles to users so they can perform certain actions such as resetting user passwords, assigning, or removing licenses, adding, or removing users, etc.

      More than 50+ built-in roles are available in Azure AD so you can follow the principle of least privilege and assign users the permission that they need to complete the tasks given to them. Azure AD roles make sure that the users are not over-privileged or under-privileged with the permissions given to them. For example, if you want to give a user the permission to create/manage groups, create/manage groups settings such as naming and expiration policies, and view groups activity and audit reports, then Groups Administrator is the right role that can be assigned to the user.

      Here is the complete list of roles available in Azure AD:

      https://docs.microsoft.com/en-us/azure/active-directory/roles/permissions-reference

      You can assign roles to the users from the Users ➢ Assigned Roles blade. At the time of authoring this book, assigning roles to groups is in preview. If you would like to know more about this preview feature, refer to this document:

      https://docs.microsoft.com/en-us/azure/active-directory/roles/groups-concept

      We will cover more about Azure AD roles when we discuss role-based access control in Chapter 2, “Compliance and Cloud Governance.”

      We talked about managing users and groups and assigning roles to them. In an enterprise environment, not only users but devices used by users need to be managed and monitored. Azure AD Join helps you to make sure that the devices used by the users follow the organizational standards. Let’s discuss Azure AD Join.

      Managing Multiple Directories – Identity: Azure Active Directory

      Each tenant represents an organization, and it is a fully independent resource. Every tenant that you create is logically separated from other tenants that you manage in a multitenant environment. Even if you are the common administrator for all these tenants, there will not be any parent-child relationship between these tenants or directories. Resource independence, administrative independence, and synchronization independence are there between the tenants.

      Resource independence is when you create or delete a resource in one tenant; this action will have no impact on any other resource in another tenant. However, there is a small exception that we discussed in the case of cloud identities from external AD. By default, Azure AD doesn’t delete Guest users when they are deleted from their home tenant; however, we can set this up manually.

      Administrative independence is when a non-admin user (say the user’s name is John) of tenant A creates a new tenant, say tenant B.

      • John will be the Global Administrator of the tenant B as he created the new tenant. The user will be added as a user from external AD. Here it says external AD, because John is not from tenant B but from tenant A.
      • Administrators of tenant A have no control over tenant B. If the users of tenant A need to access or manage tenant B, then John must invite these users to tenant B and give the necessary role. One thing to note here is that if the admins of tenant A takeover John’s account, they can access tenant B.
      • Adding or removing an admin role in one tenant will not affect the role of the user in the other tenant. Here we’re not removing the user; we are adding or removing the Azure AD roles, which will have no impact on the other tenant, and all roles the user has in the other tenant will be retained.

      When it comes to synchronization independence, you can set up independent synchronization on each Azure AD.

      With that, we have covered all the topics that are within the scope of the exam.

      Summary

      In this chapter, we talked about the identity and access management solution in Azure: Azure Active Directory. We started the chapter looking at the benefits of Azure AD, and then we examined how Azure AD is different from the traditional Windows Server Active Directory deployment.

      As we progressed, we spoke about Azure AD licensing and how administrators can set up custom domains. After that, we learned about user accounts and group accounts. This is a major element of this chapter; understanding user and group management is crucial for cloud administrators. If you are not confident with identity and access management, there can be a chance of security flaws. Security issues are not something welcomed in an organization as they can cause damage to the reputation of the organization, especially when you are dealing with customer data. Along with the impact on the reputation, this can also lead to revenue loss. As an administrator, you should excel in the identity and access management field.

      Then we spoke about Azure AD roles and how administrators should put emphasis on the principle of least privilege. Several other key ideas were reviewed including AD Join and SSPR. You learned about the advantages of incorporating these features in your environment.

      Toward the end of the chapter, we covered multitenant environments and the independence they provide in terms of administration, resources, and synchronization.

      Like with security, implementing governance and compliance is crucial in setting up the environment. In the next chapter, we will cover governance and compliance.

      Regional Pairs – Compliance and Cloud Governance

      As you already know, each region consists of one or more datacenters that are in close proximity and connected via a low-latency network. Now, an Azure geography is defined as an area of the world that consists of one or more Azure regions. Some examples are United States, India, Asia Pacific, United Kingdom, etc. If we take the United States geography, it consists of several regions such as East US, West US, Central US, etc. So, an Azure geography ensures the data residency and compliance requirements are met. If you are an organization working with a US government organization, then you cannot store data outside of the United States. Similarly, the European Union has the General Data Protection Regulation (GDPR) where organizations cannot store personal data of the EU citizens outside EU member states. As an administrator, if your organization is GDPR compliant, you can pick a geography that is within the EU and stay compliant.

      Azure pairs one region with another region within the same geography. Regional pairs play a vital role in business continuity and disaster recovery (BCDR). Whenever there is a planned update on the Azure platform, Azure rolls out the update sequentially across regional pairs. This guarantees that only one region in the regional pair is updated at a time and the other one can be leveraged for the recovery of the services if something goes wrong.

      Figure 2.2 shows a graphical representation of regional pairs in Azure.

      FIGURE 2.2 Graphical representation of Azure regional pairs

      The following are some of the focus points about Azure regional pairs:

      Physical Separation  Three hundred miles is the preferred distance between datacenters that are part of the regional pair; however, this might not be feasible in certain geographies. This isolation will diminish the probability of both regions being affected at the same time due to outages caused by natural disasters, power outages, etc.

      Replication  Services like storage accounts provide georedundant storage (GRS). Using GRS, your data will be replicated to the paired region and thus provide reliability.

      Recovery Order  If a mass outage happens, Microsoft will prioritize the recovery of one region out of every regional pair.

      Serialized Updates  Azure planned updates are rolled out sequentially to the regions in a region pair. As the update is not done simultaneously, even if something goes wrong, one of the regions in the region pair can be used for recovery.

      Data Residency  As the regions in a regional pair are part of the same geography, customers can get the benefit of regional pairs without breaking any of the data residency policies.

      • All region pairs have regions from the same geography; the only exception is Brazil South, and the paired region for Brazil South is South Central US. South Central US is part of the United States geography. However, the South Central US paired region is not Brazil South.
      • All region pairs are paired in both directions. One exception here is West India. West India’s pair is South India; however, South India’s secondary region is Central India.

      Understanding regional pairs and incorporating them into your infrastructure will help you architect highly available solutions with business continuity in Azure. The complete list of Azure region pairs and how services can leverage regional pairs is available here:

      https://docs.microsoft.com/en-us/azure/best-practices-availability-paired-regions

      With that, we will move on to Azure accounts and subscriptions.

      Azure Accounts and Subscriptions – Compliance and Cloud Governance

      We covered Azure AD concepts in Chapter 1, “Identity: Azure Active Directory,” where we defined an Azure subscription as a logical unit for setting up a resource boundary, environment boundary, and billing boundary. Every subscription will have an account that is attached to it. This account can be a work or school account or an account that Azure AD trusts. If you don’t have a work or school account, you can use a Microsoft account to use Azure. The reason behind this is that Azure AD trusts Microsoft accounts. Let’s learn more about Azure accounts and subscriptions.

      Azure Accounts

      Subscriptions will always be mapped to an account. Any identity that is part of Azure AD or a directory trusted by Azure AD is referred to as an Azure account. It could be a work or school account that is created in Azure; you already saw in Chapter 1 how users can be added to Azure AD. Also, it could be a Microsoft account that is trusted by Azure. If you use your personal account, then you will be creating a Microsoft account and using that as the Azure account.

      When you sign up for an Azure account using your work or school account, all subscriptions will be created in the Azure AD that your account is part of. If you are using a personal account, then Azure will automatically create an Azure AD tenant during the account creation process.

      Azure Subscriptions

      We already discussed the boundaries of Azure subscription sets in terms of resources, environment, and billing. In Azure, billing is done per subscription, and this is charged based on the type of subscription you have. We will cover some of the common types of subscriptions that you will be using for personal, development, and production workloads.

      The user who created the Azure account is called the Account Administrator, and a user can have multiple subscriptions inside an account. Reasons for having multiple subscriptions may include environment isolation, project isolation, etc. In Figure 2.3, you can see that the Azure account has multiple subscriptions; these subscriptions are created to separate the workloads in these environments.

      FIGURE 2.3 Types of Azure subscriptions

      By default, only the account administrator will have access to the newly created subscription. If you would like to grant access to others, then you can use the classic administrator role or role-based access control (RBAC). As we are not using classic resources anymore, Microsoft recommends that you use RBAC for granting access to users and external partners to your Azure resources.

      There are multiple channels from which you can get an Azure subscription. Now, we will look at these channels and how each one of these is different.

      Subscription Metering – Compliance and Cloud Governance

      All offers provided by Azure are meant for unique needs and requirements. For people who want to test the services there is a Free Trial, for students there is Azure for Students, and finally for enterprise deployments we have different paid subscription offers like EA, Pay As You Go, etc., which provide service level agreements (SLAs). The most commonly used subscription types are these:

      • Free subscription
      • Pay-As-You-Go
      • Enterprise Agreement
      • Azure for Students

      Azure Free Subscription  You can get a $200 credit to spend on any Azure service for the first 30 days. You have to upgrade your Free Trial if you exhaust your credits or when you complete the trial period (whichever happens first). Along with the credit, you will get selected popular Azure services free for the first 12 months and 25+ services always free. However, this benefit will be applied only if you upgrade to a paid subscription. Signing up for a Free Trial will require a credit card; this is only for the verification purposes, and you will not be charged unless you upgrade to the paid subscription.

      Azure Pay-As-You-Go Subscription  Once you upgrade your Free Trial subscription, your subscription will be converted to a Pay-As-You-Go (PAYG) subscription. In PAYG, you will be receiving invoices monthly based on your consumption. However, this will not be from the first to the last of the month; the billing cycle is dependent on what date you started the PAYG usage. PAYG is ideal for individuals to small businesses; even some large organizations use PAYG. However, there are no discounts applied like with EAs.

      Azure Enterprise Agreement  Customers can buy cloud services and software licenses under one single agreement. These customers are also eligible for discounts on services, licenses, and software assurance. The targeted audience for this is enterprise organizations. Customers need to pay the cost upfront to Microsoft as a monetary commitment, and the consumption will be deducted from this prepayment.

      Azure for Students  As the name suggests, this subscription is ideal for students who want test or develop solutions in Azure for learning purposes. Students will receive $100 as a credit that is valid for 12 months. Along with the credit, there will be free services that users can leverage. Students need to verify their student status using a university email address to activate this subscription. Also, Azure for Students doesn’t require a credit card.

      So far, you have seen the different offer types that are available in Azure and how customers can choose one that suits their needs. You have also seen how usage is computed in each offer; now you will see how you can leverage Azure Cost Management in monitoring and optimizing cloud expenditure.

      Page 1 of 2

      Powered by Dianne & Theme by Diannehill