Microsoft Graph: Restrict Access Using Conditional Access Policy

In this post we will be going through setting up a conditional access policy to allow connection’s to a Microsoft App Registration that will be used for calling Microsoft GraphAPI from only certain countries / public IP’s.

Microsoft has a preview feature in Conditional Access for workload identities. A workload identity is an identity which allows an application or service principal access to resources.

When an App Registration is created, it will create a service principal. This service principal is what we will use in the conditional access policy.

First we need to create the named location to define where we want to allow the access from.

To create a named location go to endpoint management admin page.

https://endpoint.microsoft.com/

Go to Endpoint security > Conditional access.

Once in Conditional access, go to Named location and add the required countries locations and or IP ranges.

To add as single IP use /32 bit subnet mask.

Once we have the named locations we can create the Conditional access policy.

Go to the policies tab and click on new policy.

Give the policy a name and set the assignment to workload identities.

Next select the service principal for the Graph App registration.

Next on Cloud apps or actions select, All cloud apps

Next we need to specify which location will be included, which we set to any location as we will use the exclude to allow access from the named location we will connect from.

Next select the location that will be excluded from the policy in my case it will be the public IP we added earlier to the named location.

Next we set the access, I will be blocking access as I only want to allow access from the one public IP we specified in the excluded location.

With any conditional access policy I would recommend setting the policy to Report-only to confirm that only the access that we excepted to be blocked is.

To check if the policy is applying correctly against the service principal we can check the sign-in logs.

First connect using Graph query and then go to sign-in logs.

Select service principal sign-ins.

Click on the request ID and look at the Report-only tab to see if the access would have been blocked or allowed.

Once we confirm that the policy is applying the correct access, the conditional access can be set to on.

Now once we try to connect from an IP or location not on the excluded list, it will be blocked from accessing.

When we connect from an allowed location, we will get back the access token and be allowed to connect.

When creating App registration we should look at access controls for these as this can be over looked and lead to a security risk, most application do not need access from any location and should be limited to only the require location or IP address to give greater access control.

Create Azure conditional access policy with named location

In this post we will be going through creating an Azure conditional access policy to restrict logging on to Azure / Office 365 from specific locations.

Conditional access policies are used to set requirements for accessing Azure or Office 365 resource, when using Named locations we can then set based on IP range, Trusted locations or Countries and regions.

Below diagram is from Microsoft on how conditionals access works.

What is Conditional Access in Azure Active Directory? | Microsoft Docs

Conceptual Conditional Access process flow

First step is to logon to Azure and go to Azure AD conditional access

Create a named location that will be used to restrict access.

Once in named location we can either create a location based on IP range or countries / regions. In this case we will be using a country.

Next we will create the conditional policy

Give the policy a name, we will be using a group to apply the policy but this could be change to all users or by directory role. (We can use select users or groups to apply the policy to a specific group as if applied to all users there could be a risk of locking yourself out of Azure portal)

Next we can apply the policy to specific apps or all apps. (If applying to all apps there will be a warning to not lock yourself out)

Next we set the conditions in this case we will be using location, I will be applying the policy to any location.

We can then set the named location as excluded in the policy so that it wont be applied if the access is coming from a country that is on the allowed named location.

This image has an empty alt attribute; its file name is image-26.png

Next we can set the access control settings, in this case we will block access but this could be changed to require MFA or other settings below.

Last step is to set session options to use conditional access app control, force sign-in frequency, Persistent browser session. We wont be setting any of the session settings as this policy is to block access.

There are three options report-only, on or off. To test the policy and check what will be blocked without running the risk of blocking real users set to report-only (This would be recommend for testing policy before rolling out to all users.)

Click create and the policy should now show and the state should be report-only.

To test if the policy is going to be applied we can check a users sign-ins, click on a signing log and go to Report-only, click on the three dots and show details.

This will show what part of the policy has been satisfied and not satisfied. Since the location has not been satisfied (as we are connecting from a excluded location) and the policy is not applied.

This image has an empty alt attribute; its file name is image-31.png

When the users tries to access from a country that is not in the allowed location, the result will be a failure and the users would be blocked from accessing.

Once testing has been completed and there are no unexpected blocks we can then go back to the conditional access policy and change the state to on, to apply the policy to users.

Now when a restricted user try’s to access an Azure / Office 365 resource from country not in the named location they will receive a message like the below.

Configure Azure ATP

In this post we are going to go through configuring Azure Advanced Threat Protection (Azure ATP), ATP is a cloud tool that can be used to detect security issue with on-premises active directory.

https://azure.microsoft.com/en-us/features/azure-advanced-threat-protection/#security

Azure ATP is available as part of Enterprise Mobility + Security 5 suite (EMS E5), and as a standalone license. You can acquire a license directly from the Microsoft 365 portal or through the Cloud Solution Partner (CSP) licensing model.

Azure ATP uses agent sensor installed on domain controllers or as standalone deployment that used port mirroring to monitor and analyzes user activities and information across your network.

We will be using the agents in this post since I can installing software on my DC if you have a policy that restrict agents installed on DC then you can use standalone deployment.

To configure Azure ATP first step it to setup an ATP workspace.

Go to https://portal.atp.azure.com/ and use your Azure AD logon ATP0 Once the workspace has been created we need to configure the on-premises connection account. ATP1 Put in details for the domain account, I used a service account that has read access to AD so that I could restricted the logon to the account to only be used for ATP ATP2 Once AD details are added next step is to download and install the sensor agent. Go to sensors and download the setup exe and copy the access key as this will be required during the install. ATP3 Copy the installer to the DC and run. ATP4 Select required language. ATP5 Deployment type will be sensor I am running on VMware and this will generate the below warning which will redirect to a guide to disable IPv4 TSO Offload. ATP6 This is where we need to put in the access key so that the sensor is associated to the correct workspace. ATP7 The agent should now start to install. ATP8 ATP9 Once the agent has install it can take some time for it to respond in Azure ATP. ATP10 Now the agent should start to notify of any suspicious activity that run’s like reconnaissance on SMB, DNS and other malicious reconnaissance.

We can also create HoneyToken account that will be dummy account that can be used to attracted attackers and will automatically generated an alert as they should never be used.

Go to Entity tags >Honeytoken and select the account that will be used as the Honeytoken ATP13 We can also add sensitive account and group, there are default groups/ accounts that are considered sensitive by default like Administrators, Domain admins, Enterprise admins…, a full list of these can be found in the below link.

https://docs.microsoft.com/en-us/azure-advanced-threat-protection/sensitive-accounts ATP14 If we now logon with the HoneyToken account it will then alert the activity by this account. ATP15 We can also run reports or schedule reports for schedule reports. To run a report go to the reporting blade and change the date to the range you want and click download. ATP16 Below is an example of the modification to sensitive groups. ATP17 To scheduled reports go to configuration and scheduled reports. ATP18 ATP19

Configure MFA For Azure Application Proxy

On the last post we setup Azure Application Proxy to allow internal application’s to be made available externally using AAD integration.

To add additional security to the setup we can enable MFA for the group or users that will be allowed access.

To enable MFA we need to create a conditional access policy and enable on the application proxy.

First step Login to Azure

Go to Azure Active Directory (AAD) AZ1

Go to Enterprise applications

AZ3

Select the Application proxy that will require MFA to be enabled

Once in the Application proxy go to Conditional Access and select New policy MFA1

Give the policy a meaningful name as it will appear in the overall Conditional Access policy’s aswell as on the Application. This will make it easier to manage if there are multiple policy’s.

Then select Users and groups and select the required users or group MFA2

Next select the cloud apps that will require MFA in this case it is the Exchange ECP application that was configured previously MFA3

We will not setup conditions but if this is required it can be set to only allow access from certain devices types, location & sign-in risk level.

Next go to Access controls and then Grant tab. Select Grant access, tick Require multi-factor authentication and Requires one of the selected controls MFA4

Last step is to Enable the policy

MFA7

Click create at the bottom of the policy

The policy should now show and have tick under Enabled MFA5

Now when we try to access the ECP Application proxy URL,

we should be prompted for MFA MFA8

and asked to register and verify a device to be use for MFA MFA9

It is a good idea to enable MFA for application as it gives an additional layer of security.

Azure Network Security Groups (NSG) to Restrict Management Access

For security reasons it is good practice to lock down access to Azure resources and not leave management ports open to the internet.

One way to restrict access to remote access protocols like RDS / SSH is to create a Network Security Groups (NSG) and apply this to either virtual machines or virtual network subnets.

To create a NSG

Logon on to the Azure portal: https://portal.azure.com

Once logged on go to All Services > Network security groups

If you have created VM’s or other resources there might already be some pre-existing NSG’s. NSG1

To create a new NSG click on Add

Give the NSG a name, assign subscription, resource group and location NSG2

Once the deployment has completed, click on the NSG this will bring up the configuration page.

First part is to configure the inbound security rules. NSG4

Go to settings > Inbound security rules

Once in Inbound security rules. To add a rule click add.

I want to restrict access to a specific Public IP for RDP access. Set the source as IP Addresses and add in the IP that will be allowed this can be a full range or a single IP depending on network subnet bit. I am only going to add one address so I used /32 below is an example 10.10.10.92/32.

I left source port ranges and destination as default as I don’t want to restrict these. Choose the required port in this case its 3389, set protocol to Any if you require both TCP/UDP I only need TCP. Set action to allow, set priority value and last step is give the port a name / description. NSG5

Below is the updated rule I have marked out my public IP NSG6

The outbound rule is set to allow any/any by default so if there is a requirement to lock down certain ports then create a new rule here to block the required ports.

Last step once all rule have been configured is to apply the NSG against resources. I am going to apply the policy to both my subnet and NIC’s assigned to both my test VM’s.

The policy should only need to be applied to either the subnet or VM’s, I just want to show how to apply to both. If you apply a rule to both VM and subnet they need to match or any port that is not allowed on both wont be work.

To assign to subnet: go to settings > Subnets NSG7

Select virtual network and subnet. NSG8 NSG9

To apply to each VM Nic: Go to settings > network interfaces

As I already had NSG’s associated from the VM deployments I need to re-associate to the new NSG.

Select the NSG of the VM you want to move and go to network interfaces NSG10 NSG11

Chose the required NSG

NSG12

Once applied I can now only access the VM’s from my own network.