WPNinjas HeaderWPNinjas Header

Azure AD Conditional Access – Advanced Access Protection for Enterprise Remote Access and SaaS Apps

Azure AD Condition Access is a Microsoft solution to dynamically grant or deny access to Applications based on the User, Device, Location and Risk Levels. In this post, I will tell you how to implement Conditional Access in your environment based on notes from the field.

First of all, we have to discuss the use cases before implementing Conditional Access. Then, when we know the issue to solve, then we should talk about the risks, which must be known before implementing the solution. After that, the real implementation is really easy and will bring you a big benefit for your security concept.

Use Cases

In this section, I will try to give you some examples, where Conditional Access can help you. The best System to protect, are SaaS Apps or Apps, which were published with Azure Application Proxy, but you are also able to protect RDS, exchange or skype for business, but there you need to know, that you have to disable legacy authentication on these systems to really protect them. To explain you the difference between legacy and modern authentication, I will need another blog post, because this is a longer story. For now, Modern Authentication is required for Conditional Access. So, web based apps should be your first targets, because all of them just work, when they use Azure AD for Authentication.

Possible goals of your implementation could be:

  • Enforce MFA (Multifactor Authentication) from outside your Company Network.
  • Enforce MFA for all Admin Accounts regardless of their location or device state.
  • Only allow Admin Access from Company Managed Devices (Intune or Domain Joined)
  • Or the most restrictive one, allow only access from company managed device for all users and all apps.

All of these rules can help you to not lose control over your infrastructure. It does not encrypt data, but it does restrict access for example from untrusted devices.

Implementation Risks

Start small!!! If you begin by restricting your account for testing and then perhaps loose access to the Azure Portal by using a to restricting rule. Then you must open a support case and wait until they removed the rule for you. I always follow these golden rules for testing:

  • target to a single app which is not used often
  • apply the rule to a single test user or group

For production, I use the following rule:

  • Don’t target a rule to all users until the rules is really good tested. I have always an Azure Admin which, I exclude in every rule. With that admin I never work, so it is really a backup account.

Limitations

When building your rules, you will get to the point, where your requirements can not be met. A few limitation’s but important things, which are not possible at the moment are in the following list:

  • Device Condition à You can only check for Compliance or Domain Join. You cannot check for example, if a device is personally or company owned.
  • General Conditions à You cannot build complex conditions with multiple and/or’s. You can only choose to use “or” or “and”. At the moment that is ok, but when you can check for other things, then that is not enough.
  • Location à You can check for IP’s not for Locations. So you have to define, which IP belongs to which Location. Nice would be if you can say for example, if the IP is outside of my country, then force an MFA.

But, keep in mind, you can do a lot more, than with your current solution. So, switching to this technology will be a big advantage for the future. These limitations will be gone in future, you have also to check out, what partners are bringing to Conditional Access. See for example Lookout or Checkpoint, which have solutions to bring more security checks to your endpoints, which can be included in Conditional Access Rules.

Implementation of Conditional Access

I will show you how to improve the security for administrators, when they use administrative tools, like the Syntaro Portal. The goal is, that they can only access when the Computer they are using is compliant in Intune or they have done an MFA.


The entry point for Conditional Access can be found at various places in the Azure Portal. At the moment, you see it in the Active Directory or also in the Intune part.

If you have no rules created, then you will see an empty list or as in my example a list of existing rules. Click on New Policy to create a new Rule.
Now we have to specify all the settings for the new policy.

First we have to choose which users should be targeted by the policy. As learned in the Risks section of this blog, we know to target it only to a single test user.

Then we should select the application, which should be protected, which is in my case the Syntaro Demo Environment. Later I can add other administrative apps like the azure portal to the list.

Next, we can choose under which conditions the rule should apply. Normally you can leave here all sections on their default values.

Then in the Access Controls, we can define the requirements to get access to the app. In my example, I require MFA or an Intune compliant device. The logic or operator can be selected with the last option in the following screenshot.

Tip: if you require a domain joined device, then you must ensure, that your devices are Azure AD Registered or Azure AD Joined! In my environment, all devices have to be managed by Intune, so I will just use the compliance check.

Result of my Conditional Access Rule

As you can see in the following screenshots, there are more security Questions, when your environment (User or Device) in that case is not secure enough.

Device compliant Device not compliant, MFA ok Device not compliant and MFA not successful









Now, I can access the Syntaro Portal and deploy Applications to my MDM managed Windows 10 devices. I hope you enjoyed reading this blog and it could show you how easy Conditional Access can be implemented and raise your security level.

Follow me

0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.