27. Conditional access in Azure AD
Gone are the days when security was focused on a strong perimeter defense. In order to keep malicious hackers away, anything outside the perimeter was treated as hostile, whereas inside the walls, the organizations were trusted. Today’s security mantra is to assume a breach. Now, assume that breach is a mindset that guides your security, security investments, design decisions, and operational security practices. Now, in a sense, an assumed breach guides you to think differently, to change your mindset, and makes you think that you’re already breached.
During an interview in 2012, a former Director of the CIA and a retired National Security Agency general stated that, fundamentally, if someone wants to get in, they will get in, and they are most likely already there. and we need to accept that. During that time, several people didn’t quite understand what it really meant. But the sentence is the core of an assumed breach.
Data breaches, as you know, have caused devastating financial losses and affected organizations’ reputations for years. People have lost businesses, paid regulatory fines, incurred remediation costs, and experienced data breaches, with disastrous results. That’s where Azure Active Directory comes in, with its zero-trust model, which states that you should never trust but always verify. Zero Trust helps secure corporate resources by eliminating unknown and unmanaged devices, and any kind of lateral movement is limited. As a result, you must have a strong identity structure, a strong device structure, adhere to the principle of least privilege, and ensure that all of your services are operational at all times.
That’s what a “zero-trust” environment is all about. In order to implement a zero-trust model, you need to have several features of the identity and access management solution, which is Azure Active Directory, in place. and one such feature is conditional access. Conditional access is the heart of the security strategy in Azure Active Directory. In today’s work environment, we have seen that several users work from different devices. It could be a laptop that’s provided by the organisation, or somebody is using a personal phone from a different location. When working from home, office personnel keep moving from one point to another. Employees expect to have seamless access to what they need to do to do their job. With conditional access, you are adding another layer of security before allowing authenticated users to access the data in their assets. Conditional access is implemented through policies.
These are created and managed in the Azure Ad console. A conditional access policy analyses signals, including the user’s location device, and also looks at the applications that the users are trying to access and if there is any risk for the user. And that will help automate the decision-making process for authorizing access to the resources. A conditional access policy may state that if a user belongs to a certain group, they are required to provide multifactor authentication to sign in to an application. The entire engine of conditional access is looking at multiple signals. Signals like users’ or groups’ membership, names, locations, devices, the applications that they’re trying to access, or any kind of risk also the applications that they are trying to access, like the cloud apps, and also the user risk. In the next lesson, we’ll go over each of the minor details.
28. Conditional access in Azure AD – II
When a user gets authenticated from Azure Active Directory, it carries a lot of information to Azure AD to get authenticated and authorised on a particular app. That information could be the location from which the traffic originated, where the user is located, the device from which the traffic is generated, or where the user is accessing the application that the user wants to access. In addition, Azure Active Directory can retrieve the user’s group membership. Now, all these items that I just mentioned are called signals. Based on these signals, a user’s access can be allowed or denied. Let’s talk about these individual signals. Conditional access is all about following these signals to control who, what, and where the policy should be executed.
The most simple conditional access policy is the first one, which is user or group assignment. Users can be included or excluded from conditional access policies. So if you want to grant application access to a certain set of users, you can do that. These users can be either guests or external users, referred to as “B to B guests.” Or you can target it at specific groups. Let’s say the HR department needs access to an application, so you would allow only the members of the HR group to access the HR app. If you can include the users, you can also exclude the users. You can say that this set of users is excluded from the conditional policy. The next one is the named location or the location condition. So you can have conditional policies based on their geographical location or their IP addresses. So you can go ahead and set up the conditional policy for your headquarters and allow the application access only from your headquarters’ IP address. You can also whitelist and blacklist countries.
So let’s say you’re not doing business with North Korea, for example. You can just blacklist all the traffic coming from or originating from that location. So what will happen when a user signs in to Azure? Will Azure resolve that user’s IPV6 address to a country or a region? And if that mapping is incorrect or if it’s coming from that blocked location, then the traffic will be blocked as well. By this time, you already know about devices. Devices that are active directory registered. And some of these are Azure adjoining hybrid devices. You can have the conditional policies set up in a way to allow the application access only from certain devices that are hybrid Azure ad-joined devices, or at least they should be Azure adjoining devices or registered devices. Anything else that has not been joined or registered may be denied access. That means that if you want users to have access only to that application, you can map that group to an application in Azure Active Directory. So that way, you are protecting your application and mapping it to that specific user or group. The next one is real-time sign-in risk detection. So most users will have a normal behaviour that can be tracked, and when they fall outside of this norm, it could be risky to allow them to sign in. So you can block a user who is not using multifactor authentication.
So that’s one kind of risk. And of course you need to have two AzureAd P licenses, and you will get a specific feature or a service called “Azure Ad Identity Protection” in Risk Detection. And this will allow you to integrate risky assignments with conditional access. Well, it means that anybody who has not done multifactor authentication, for example, will not be allowed to access the application. So there is quite some deep integration here with Azure AD Identity Protection, which is allowing conditional access policies to identify risky sign-in behaviors. You can have policies created and then force users to change their passwords or use multifactor authentication in order to reduce their risk level, or they can sometimes be blocked from access until an administrator takes a manual action. Cloud apps or actions are a key signal in a conditional access policy.
Conditional access policies will allow administrators to assign controls to specific applications or take certain actions. There are several Microsoft cloud-based applications, for example, Office 365, Azure Analysis Services, and Azure DevOps, and the list is very long, so we can include these applications in the whitelist form. Thereafter, administrators can assign a conditional access policy to the list of cloud applications in Azure. The next one is user risk for customers with access to identity protection. Customers with two Azure ADP licences may have user risk that can be evaluated as part of the conditional access policy. But what is “user risk”? Well, user risk is the probability that a given identity or a given user account is compromised. By doing so, you can have the user marked as high risk, medium risk, or low probability. These are all the conditional access signals, and that shows Azure Active Directory will know who will have access to what kind of application in Azure.
29. Conditional access in Azure AD – III
Now you know about conditional policies. Once the conditional access policy is in place, the Azure Active Directory must make an informed decision about blocking or granting access, or it may require additional verification. So these are the three items that block, grant, or request additional verification. The additional verification, again, has multiple categories. For example, requiring multifactor authentication or require that the device to be marked as compliant.
Or Azure Active Directory wants that your device be an AzureAd Joint Device, which is a hybrid one; or it requires that it’s an approved client app; or it requires an app protection policy; or it forces the user to change the password. Now, these control user access based on session controls to enable limited experiences within specific cloud applications. As an example, you can have conditional access app control, which will then use signals from what’s called Microsoft Cloud App Security, or MCAs, and which can then block, download, or even prevent you from doing any kind of cut, copy, or printout of sensitive documents, or even force you to label the sensitive files.
Other session controls will include the sign-in frequency, which determines how frequently you can access an application. You can also choose applications and enforce device-based restrictions so that a user can have a limited or full experience, depending on the state of the device. So conditional access policies can be applied to a specific group member or even to your guest B to B accounts. For example, you can create a policy to exclude all guest accounts from accessing sensitive applications or sensitive resources. The bundle that it provides, conditional access, is not a free one. It’s a paid Azure Active Directory feature. Let’s go ahead and understand Azure Active Directory roles. So we’ve got built-in roles, custom roles, and even Azure Active Directory role-based access controls, right? So that’s an additional layer of defense. Let’s go ahead and understand that in the next chapter. Thanks for watching so far. I’ll see you in the next lesson.
30. Azure AD Roles & Custom Roles
So what comes to mind when you think about roles? Roles are a set of permissions that will let you do or take part in certain activities. For example, with a role called “global administrator,” you will be able to do or rule basically the entire Azure Active Directory tenant with full permissions on Azure ad tenant. The global administrator has the keys to the kingdom. Think about a user administrator. A user administrator is also a role that has limited permissions to manage all the aspects of users and groups. Not only that, but a user administrator can manage support tickets and monitor the service.
Right? So we’re thinking about roles here like globaladmin, user admin, and then let’s say billingadmin as well, which is a role that will be helpful to make purchases, manage subscriptions, manage support tickets, and also monitor service health. So we are attaching permissions to roles, and we’ll then attach these roles to groups and then later on add users to the groups. Now, these roles that I just referred to—the global admin, user admin, and billing administrator—are built-in roles that come along with the Azure Active Directory tenant. There are many different built-in roles with different areas of responsibility. And all the built-in roles are preconfigured bundles of different sets of permissions designed for specific tasks. Along with built-in roles, you can also create custom roles so you can mix and match certain permissions and make your own custom role.
So, although there are several of these built-in roles that come along with Azure Active Directory, the custom roles will give you flexibility when granting access. Granting permissions using custom Azure Active Directory is a two-step process that involves creating a custom role definition, which consists of a set of permissions that you add from a preset list. And then these permissions are the same ones used in the built-in role.
So once you have created your role definition, you can assign it to a user by creating a role assignment, or you can assign it via a group. But keep in mind that a custom role requires that Azure Active Directory tenant to have a P1 or P2 license. I’d like to share some best practices, such as the fact that you will only grant access when necessary. And it is a best practice and a more secure practice to grant users the least privilege to get the work done. You don’t want everyone to be a global admin; you want people to have fewer permissions so that they have just enough to do their job. So instead of assigning an administrator role, you’ll give Help Desk the user administrator role, and what do you get? Well, you will be mitigating the risk of a user account being compromised and a hacker locking you out of your account. So by assigning lease privileges, you limit the damage that could be done with a compromised account.
31. Chapter Summary
So, what did we learn about? Well, you learned about conditional access and how it protects your resources. You have seen how conditional access uses if-then statements along with signals to determine whether to grant access, block access, or ask for more information. We also learned about pre-configured and custom admin roles. You also learned about least-privileged access and how it protects your resources in Azure Active Directory. So now you’re in a better position to explain conditional access, its benefits, and Azure Active Directory roles. Thanks for watching so far. I hope this lesson has been informative to you. I’ll see you in the next lesson, where we’ll talk about the identity protection and governance capabilities of Azure Active Directory. Stay.
32. Describe the identity protection and governance capabilties of Azure AD
The title here is quite a mouthful of words. Identity Governance. Right? Identity governance. Now, what is it all about? This is concerned with balancing your identity security with user productivity in a way that it can be justified and audited.
Azure Active Directory provides many identity protection and governance capabilities, including uploading a wonderful feature called Privileged Identity Management and Identity Protection and another thing called Terms of Use statements. We’ll go ahead and talk about these three in this lecture. And after completing this lecture, you will fully understand about the identity governance capabilities of Azure Active Directory, the benefits that PIM provides, which is privileged identity management and the capabilities of Azure Ad identity protection. Let’s get started without any further delay. Thanks for watching.
33. What is Identity Governance
At times, it becomes very important for the administrator of an organisation to know four key questions. For example, which users should have access to which resources? What are those users doing with that access? And are there any effective organisational controls for managing the access given to the users? And finally, through auditing, can auditors verify that the controls are actually working? There needs to be some tool or service that can answer these questions. Azure Active Directory Identity Governance is something that gives you the ability to do all these tasks.
And these tasks include identity lifecycle governance, access lifecycle governance, and privileged access for administration. Now, all these actions can be completed by employees, business partners, and vendors, and across services and applications, both on premises and in the cloud. So if you’re using Azure Active Directory Identity Governance, it’s good to go for your on-premise solutions as well. and, of course, the ones in the cloud. Let’s talk about these individual points, like the identity lifecycle and what it is, the access lifecycle, and also understand the privileged access lifecycle, in the upcoming lessons. Thank you.
34. What is Identity lifecycle
Employees join the company, move between the departments, and at times also leave the organization. There must be some kind of process that takes care of this cycle, or, better yet, the lifecycle of identities. We need to plan identity lifecycle management for the employees. And this is the heart of identity governance. So when an individual first joins an organisation, a new digital identity is created if one is not already available. And when I’m talking about a digital identity, I’m talking about a user account. So when an individual moves between organisation boundaries, there will be more authorization changes. New authorizations and permissions will be added and removed based on what the individual’s permissions are needed for, and sometimes they are not. When an individual leaves the company at that time, access may need to be removed and the identity might no longer be required other than for auditing purposes.
Let’s now take a look at the picture here, which is pretty much self-explanatory, focusing on the first section, which is “no access.” That means the identity does not exist in your directory. They are created when they join, a couple of days before they join, and that’s their first job role. The identity may choose to move between departments for business purposes, and that’s when their title will change and their job description will change. And based on that, the permission sets also need to be changed. So although they will always have access to the directory, because their permission sets change, their authorization levels will also change. Finally, when an employee leaves the company due to retirement or another opportunity, we must disable the account and remove the access granted as a result of their job roles. And finally, the retiree or the person who leaves the company is an identity that will eventually have no access.
So this is the lifecycle of an identity and access management suite for many organizations. This identity lifecycle for employees is tied to the representation of that user in an HR system. There are several HR systems, like Workday and Success Factors, that are predominant in the world of identity lifecycle management. And the HR system is authoritative for providing the current list of employees. Some of their properties, like their department telephone number, photographs, et cetera, We’re now talking about Azure Active Directory. Azure Active Directory Premium The P1 and P2 offer integration with cloud-based HR systems. When a new employee is added to the HR system, Azure Active Directory can create a corresponding user account automatically.
Similarly, when their properties, like department employee status, change in the HR system, then synchronisation of those updates to Active Directory will ensure consistency between the systems. Azure Active Directory Premium also includes Microsoft Identity Manager, which can import records from on-premises HR systems. For example, in SAP HCM or Oracle Ebusiness, as well as in Oracle PeopleSoft in general, managing the lifecycle of an identity is about updating access to meet user needs, whether through integration with an HR system or through user provision applications.
35. Access Lifecycle
Access lifecycle. Now what is it all about? Organizations occasionally require a process to manage a user’s access. Users require different levels of access throughout their life cycle, from the time they join the organisation to the time they leave. And at various stages in between them, they will need access rights to different resources depending on their role and responsibilities. Organizations can automate this access lifecycle process through technologies, of course. And then we’ll use something called “dynamic groups.”
And dynamic groups will enable administrators to create attribute-based rules to determine membership in the groups. So when an attribute of a user or device changes, the system evaluates all the dynamic group rules in the directory to see if the change would trigger any users to be added to or removed from the group. If a user or a device satisfies a rule from the group, they are added as a member, and if they no longer satisfy the rule, they are then removed from the group. That dynamic group can then be used to assign permissions to various other objects and resources. So the user will automatically have certain permissions, and as they move on to different roles, their attributes change, and based on the changed attribute, their group membership will also change automatically. Now, this is a much more mature solution as opposed to doing things manually.
36. Privileged access lifecycle
So what is it that you can do with the privileged access lifecycle? What is it all about when you’ve granted privileged access? Monitoring it is a key part of identity governance. So when employees, vendors, and contractors are assigned administrative permissions or administrative rights, there should be some kind of governance process because of the potential for misuse. There is a feature in Azure Active Directory called PIM. which stands for Privileged Identity Management. And this provides extra controls which are tailored to secure access rights.
Privileged Identity Management will help you minimise the number of people who have access to resources across Azure Active Directory and other Microsoft Online Services that are available and that integrate very well with Azure AD. Now, Pi M for Privileged Identity Management is providing a lot of governance controls to help secure your company’s resources. So external users who are using Microsoft 365 or other SaaS-based applications that are integrated with Azure AD or PIM can very well control access to them.
You can have wonderful features like enforcing just-in-time access or time-bound access to ensure that resource access happens at a particular time and date. Approvals can also be in the works. For example, when an employee tries to access a resource, there could be an approval stage in the middle. You can enforce multifactor authentication. You can also use a justification column to explain why users need to access the resource and get notified if the privileged roles are activated. Finally, good news for auditors: audit histories for internal and external audit can be downloaded. That’s great. So you don’t have to run around multiple interfaces to get that audit report. All of these things can be handled by the Azure Active Directory. Privileged Identity Management is used for a variety of reasons. The number one reason is to reduce the chances of a malicious actor getting access to your sensitive resource.
37. What is Entitlement management
Let’s talk about three more important concepts. They are entitlement management, access reviews, and terms of use. Entitlement Management is a feature of identity governance that will assist your organisation in managing identities and access lifecycles at scale. Now, think about how you can automate the access request workflows. How can you automate the access, access assignments, reviews, and exploration? You cannot have personnel sitting there constantly looking at users, creating them, and then accessing and giving permissions to people, right? There must be some kind of automation. The management of entitlements does just that.
When it comes to managing employee access to resources, enterprise organisations frequently face difficulties. And this could be, for example, because users may not know what access they should have. And even if they do, they might have difficulty locating the right individuals to approve it. So when users find and receive access to a resource, they may hold on to it longer than it’s required for business purposes. Now, that’s not right. There’s another challenge, which is managing access for external users. could be your vendors, consultants, et cetera. These are the challenges that are often faced by enterprise organizations. Let’s look at how entitlement management can help us solve and address these issues. With entitlement management, you can delegate the creation of access packages to nonadministrators.
Now, these access packages contain resources that users can request through the Delegated Access Package Manager. Then you can define policies that include rules such as which users can request access, who must approve their access, and when the access should expire. With entitlement management, you can also manage external users. For example, when a user who is not in your directory requests access and it is approved, they are automatically invited to your directory, and then the accesses are assigned to the resources. Now, when their access expires, for example, and if they have no other access package permissionsor assignments, then their B to B accountin your directory can be automatically removed. Keep in mind that entitlement management is a feature of Azure Active Directory Premium Services. We also need to understand access reviews, and let’s do that in the next lesson.
38. Azure AD access reviews
This is the world of disclaimers. Legality and compliance Terms of Use is a feature of Azure Active Directory that will ensure that users read the relevant disclaimers for legal or compliance requirements. The Terms of Service feature will allow users to be presented with information before accessing data or an application.
Employees or guests can be required to accept the Terms of Use in certain situations, and those situations could be scenarios when they are trying to access sensitive data or an application on a recurring schedule so that they are reminded of regulations. You can also have those Terms of Use in different languages based on the user’s attributes, such as terms applicable to certain roles in the company. Finally, you can present the terms for all users in your organisation without any exceptions as well. Usually, the Terms of Use are presented in PDF format using content that you create, such as an existing contract document.
Terms of service may also apply to mobile device users. You need to have contact with your legal team within your organisation to finally present what the legal and compliance requirements of your organisation are and what your applications are. Conditional Access Policies Talking about the Terms of Use, you may be thinking, “How do you push the Terms of Use document to the users?” Well, that’s where conditional access policies come into play. You can have the Terms of Service statement displayed through conditional access, ensuring that the user has agreed to those terms before accessing the application. via conditional access. Admins can also view who has agreed to the terms of use and who has declined. And based on that, you can have access granted or denied to the application. It’s time we talk about privileged identity management, and let’s do that in the next section. Thanks for watching so far. Hopefully, everything has been explained to you. I’ll see you in the next section.
39. Azure AD terms of use
This is the world of disclaimers. Legality and compliance Terms of Use is a feature of Azure Active Directory that will ensure that users read the relevant disclaimers for legal or compliance requirements. The Terms of Service feature will allow users to be presented with information before accessing data or an application.
Employees or guests can be required to accept the Terms of Use in certain situations, and those situations could be scenarios when they are trying to access sensitive data or an application on a recurring schedule so that they are reminded of regulations. You can also have those Terms of Use in different languages based on the user’s attributes, such as terms applicable to certain roles in the company. Finally, you can present the terms for all users in your organisation without any exceptions as well. Usually, the Terms of Use are presented in PDF format using content that you create, such as an existing contract document.
Terms of service may also apply to mobile device users. You need to have contact with your legal team within your organisation to finally present what the legal and compliance requirements of your organisation are and what your applications are. Conditional Access Policies Talking about the Terms of Use, you may be thinking, “How do you push the Terms of Use document to the users?” Well, that’s where conditional access policies come into play. You can have the Terms of Service statement displayed through conditional access, ensuring that the user has agreed to those terms before accessing the application. via conditional access. Admins can also view who has agreed to the terms of use and who has declined. And based on that, you can have access granted or denied to the application. It’s time we talk about privileged identity management, and let’s do that in the next section. Thanks for watching so far. Hopefully, everything has been explained to you. I’ll see you in the next section.
40. Capabilities of Privileged identity Management
Let’s understand the capabilities of privileged identity management. PIM is an acronym. Now, this is a service in Azure ActiveDirectory that will help you manage, control, and monitor access to important resources in your organization.
These include resources in Azure Active Directory. It could be in Azure. You’ve probably built a web app service, a virtual machine in Azure, or even a database. It could be resources outside Azure. For example, Microsoft 365 or Microsoft Intune PIM will mitigate the risk of excessive permissions, unnecessary permissions, and misused access permissions. It requires justification to understand why users want certain permissions. It can also be used to enforce multifactor authentication to activate any role. To talk more about PIM, we can use it for providing just-in-time access, which means providing privileged access only when needed and not before that. You can also have time-bound access by assigning start and end dates that will indicate when a user can access a resource. You can also have approval-based access, which means that you’ll require specific approvals to activate privileges.
Notifications can be sent when privileged roles are activated. Finally, auditable. That means that you can have a full access history that is ready to be downloaded. So, why do we need PIM with all of these features? PIM reduces the chance of a malicious actor getting access by minimising the number of people who have access to your secure information or secure resources. By using this feature of time-limiting authorised users, it reduces the risk of an authorised user inadvertently accessing or affecting sensitive resources. PIM also provides oversight of what users are doing with their admin privileges. With all of these features, PIM reduces the organization’s risk of elevated privileges. Another wonderful security feature that comes bundled with Azure Active Directory Premium is Azure Identity Protection. Let’s learn about that and understand its features in the next lesson. Thanks for watching so far.
