Connecting to Microsoft GraphAPI Using PowerShell

Recently I have been looking to use Microsoft Graph to query specific information for Microsoft 365 services.

Microsoft Graph is an development tool that connects to multiple Microsoft 365 services to allow querying data and automate tasks.

There are a few steps required to start using Graph which involves creating a app registration on Azure to issue authentication tokens and API permission to view data.

Use the Microsoft Graph API – Microsoft Graph | Microsoft Docs

I also used a blog post by adamtheautomator as this was very good at explaining the process and goes more in depth.

Using the Microsoft Graph API with PowerShell (adamtheautomator.com)

In this post we will be going through configuring the app registration and query some data from Azure AD.

First step is to logon to the Azure portal > Azure AD > App registration and click on New registration.

Give the app a name and specify the support account type in this case we only want account from our tenant.

Once completed, we should now see the app has been created.

Next step we need to configure the API permissions, depending on the type of access required we will use either delegated or application permission as some data can only be access by either permission types.

below is a extract from the Microsft Docs on permission types

Microsoft identity platform developer glossary | Microsoft Docs

permissions

client application gains access to a resource server by declaring permission requests. Two types are available:

  • “Delegated” permissions, which specify scope-based access using delegated authorization from the signed-in resource owner, are presented to the resource at run-time as “scp” claims in the client’s access token.
  • “Application” permissions, which specify role-based access using the client application’s credentials/identity, are presented to the resource at run-time as “roles” claims in the client’s access token.

To assign permission go to the app registration we created earlier and go to API permissions > Add a permission and select Microsoft Graph.

To check which permissions are required I used the below Microsoft Docs .

Microsoft Graph permissions reference – Microsoft Graph | Microsoft Docs

Select the permission type and the required permission in this case I want to be able to read groups, users and directory so.

Once the required permissions are added if they required admin permission those will need to be granted using the grant admin consent option below.

There are many different way’s to connect to Microsoft Graph but in this post we will be using client secret.

We will need the application ID

We will create a client secret

Give the client secret a name and set the expire in this case we will use 1 year.

There should now be client secret and the value is used to authenticate. (Take note of the value and save in secure location like a password vault or Azure Key vault as once you leave the app blade the value will be hidden and if you lose will have to be recreated.)

Once we have the above configured we can connect to GraphApi to generate a token. We will used Invoke-RestMethod.

The secret can be hardcoded but I decided to use read-host so that I could add the secret manually, as it’s not recommend to have any password/secret hardcoded in script.

Below is the command I used to get the token.

$ApplicationID = ""
$TenatDomainName = ""
$AccessSecret = Read-Host "Enter Secret"


$Body = @{    
Grant_Type    = "client_credentials"
Scope         = "https://graph.microsoft.com/.default"
client_Id     = $ApplicationID
Client_Secret = $AccessSecret


$ConnectGraph = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenatDomainName/oauth2/v2.0/token" `
-Method POST -Body $Body

$token = $ConnectGraph.access_token

To verify we have a token run the variable $ConnectGraph to view.

Now that we have a token we can run a query against GraphAPI. The below we will be running for groups and selecting display name.

$GrapGroupUrl = 'https://graph.microsoft.com/v1.0/Groups/'
(Invoke-RestMethod -Headers @{Authorization = "Bearer $($token)"} -Uri $GrapGroupUrl -Method Get).value.displayName

To view some examples we can use Graph Explorer.

Graph Explorer – Microsoft Graph

In a future post we will be going through more query’s and automating tasks using GraphAPI.

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.

MECM 2002 Cloud Management Gateway Configuration

I have been looking at setting up MECM cloud management gateway (CMG) for a while but haven’t been able to, due to the need for PKI or Azure AD joined.

With the recent release of MECM 2002 this has added a new feature,  that allows token based authentication. I decided to do a test deployment in my lab to see how this would work before deploying to our production environment.

With a CMG we can manage clients that don’t regularly connect back to the cooperate network which has become more of a priority recently.

There is a cost for running the VM’s in Azure that will be used as the CMG and for outbound data transfers. Johan Arwidmark has done a good real world cost estimates for a CMG.

https://deploymentresearch.com/real-world-costs-for-using-a-cloud-management-gateway-cmg-with-configmgr/

First step should be to have a read of the docs for planning a CMG

https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/plan-cloud-management-gateway

To use token base authentication require MECM 2002, so that is a pre-requisites for deploying a CMG in this way.

https://docs.microsoft.com/en-us/mem/configmgr/core/clients/deploy/deploy-clients-cmg-token

There will be some required permission in Azure also for deploying the CMG.

  • Account that has Global Admin and Subscription Owner roles.
  • Content filter rules to allow outbound access (If there is a proxy or Firewall filtering traffic)

There will also be a requirement for a cert to be applied to the CMG, it is  recommend to have a third party cert as it should automatically trusted by clients.

From looking through the documents below are the required URL https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/network/internet-endpoints#cmg-connection-point

*.cloudapp.net

*.blob.core.windows.net

login.microsoftonline.com

Once all pre-requisites have been confirmed we can start to configure the CMG. We will need to pick a unique cloud service name as this will be required later, easiest way to check if the name you have select is unique is to logon to Azure go to cloud services (classic)

CloudService

Once the cloud service has been checked,  then we need to configure the Azure services.

Logon to the MECM console and go to Administration > Cloud services > Azure services.

Click configure Azure servicesCMG1

Give the service a name and select cloud management CMG2

We need to configure a server and client applications CMG5Give the applications a name and sign in to Azure using a account with the required permission CMG3CMG4I just left user discovery enabled. CMG6Click next to finish configuring the Azure services. CMG7Once finished the Azure service should now be showing CMG8The Azure AD tenant should also show with both application we just created. CMG9

 

Once this has all been configured we can now start to setup the CMG.

To start the configuration go to Administration > Cloud services > Cloud Management Gateway

Click Create Cloud Management GatewayCMG10

Select AzurePublicCloud and sign in. (If the subscription ID doesn’t show it might be the account you are using is not an owner of the subscription.)CMG11

Now we need to configure the cloud services, this is where we will use the name we checked earlier.

  • Select the cert file, this needs to be a PFX with the private key (I am using one created on my internal CA but in production I will be using a third party CA like digicert or godaddy)
  • The cert name will be automatically set the deployment services name so this is why we should confirm the name before hand so we can generate the cert with the same name.
  • Select the region the CMG will be configured in
  • Either select a existing or create a new resource group (I chose new one to keep the CMG separate from my other Azure resources)
  • Select the required amount of VM’s this can go up to 16 (for high availability it recommend to configure 2 VM’s at least)
  • Tick the required security authentication I just ticked Enforce TLS 1.2
  • I also ticked using CMG and cloud distribution point

CMG12I left the alerting as default CMG13Just follow the wizard to complete. CMG15

Once completed the CMG should show as provisioning started 

This slideshow requires JavaScript.

We can also logon to Azure to verify the cloud service has been created. CMG18

After the CMG has been configured we then need to install the Cloud management connection point to connect MECM to the CMG.

Go to Administration > site configuration > servers and site system roles, Add the Cloud management gateway connection point to the primary site server in MECM

This slideshow requires JavaScript.

After the role has been configured we need to configure a few steps on the site server, management point and software update point (if installed and configured)

Open the management point properties and tick the allow configuration manager cloud management gateway traffic. (If the tick box for is greyed out there is an additional step required.) 

Go to Administration > site configuration > sites, then configure the primary site to use configuration manager generated certificate in communication security. Once this is done go back to the management point and the tick box should now be available.

CMG27

CMG23CMG24To allow the software update point to communicate with the CMG, tick the allow configuration manager cloud management gateway traffic. CMG26After this has been configured the clients should now pick up a the CMG as a internet based management point in the network tab of client agent properties. CMG25

Once the client moves off the internal network and does a location lookup we should see that the connection type will change to internet from internal. CMG29

We can also check the location services log to see if the CMG is being picked up. CMG28

Connect Windows Admin Center to Azure

In this post we will be going through connecting Windows Admin Center to Azure to allow management of Azure VM’s. To install WAC see previous post.

The Azure integration allows the management of Azure and on-prem servers from a single console.

First step is to register WAC with Azure, Open the WAC admin console and go to settings tab. AZ1

Go to the Azure in the  gateway settingsAZ2Copy the code and click on the enter code hyperlink and enter the codeAZ3AZ4

Sign-in using an admin account on the Azure tenant. AZ5AZ6

Now go back to WAC and click connect to finish the registration AZ7

Once WAC is registered it require admin application permission to be granted to the application registration in Azure AZ8

Now that the registration is completed we can now add Azure VM’s to WAC go to add and select Azure VMAZ9

Select the subscription (if there are multiple subscription in your tenant),  resource group  and VM that will be added. AZ10

Once the Azure VM is added, to allow management there will need to be management ports opened to allow a connection between WAC and the Azure VM. If you are using a site to site VPN you can just allow the ports over the VPN connection.

I have a public IP associated with my VM and I will be modifying my network security group to allow the ports from my public IP.

I wont be going through configuring an NSG as this was covered in a previous post. AZ15

On the VM itself you need to enable winrm and allow port 5985 through the windows firewall if enabled. This can be done by running the two command below from an admin PowerShell session.

winrm quickconfig
Set-NetFirewallRule -Name WINRM-HTTP-In-TCP-PUBLIC -RemoteAddress Any

Once the NSG is configured we should then be able to connect to the VM. AZ12

Below shows the overview of the VMAZ14We can also now connect to the VM using integrated RDP console in WACAZ13

WAC also allows us to manage services, scheduled tasks, backups, check event logs and other admin task, along with connecting using remote PowerShell directly from WAC.AZ16

 

 

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 logonATP0Once the workspace has been created we need to configure the on-premises connection account. ATP1Put 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 ATP2Once 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. ATP3Copy the installer to the DC and run. ATP4Select required language. ATP5Deployment 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. ATP6This is where we need to put in the access key so that the sensor is associated to the correct workspace. ATP7The agent should now start to install. ATP8ATP9Once the agent has install it can take some time for it to respond in Azure ATP.ATP10Now 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 HoneytokenATP13We 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-accountsATP14If we now logon with the HoneyToken account it will then alert the activity by this account. ATP15We 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. ATP16Below is an example of the modification to sensitive groups. ATP17To scheduled reports go to configuration and scheduled reports. ATP18ATP19

 

 

Configure Azure Arc for servers

Azure Arc for servers is a tool that can be used to add on-prem physical / virtual servers or servers running in other cloud providers to Azure, this allow these servers to be centrally organised and to be connected to Azure services like Azure policy or log analytics.

Azure Arc for servers is in public preview, so this should not be used on production system until there is a full release version. Currently the only support OS version’s are below.

  • Windows Server 2012 R2 and newer
  • Ubuntu 16.04 and 18.04

If there is a content filter or proxy, the URL’s in the below link will  need to be white-listed all traffic will go over HTTPS (Port 443)

https://docs.microsoft.com/en-us/azure/azure-arc/servers/overview#networking-configuration

To add a server to Azure Arc, logon to the Azure portal.

Go to All services > Machines – Azure ArcArc13

Click on create machine – Azure ArcArc1There are two options add machines using interactive script or add machines at scale. In this post we will be using the scripted method. Arc2

Select the subscription, resource group and region. When selecting  the operating system we can chose between Windows or Linux. Windows will create a PowerShell script and Linux will create a Linux .sh script.Arc3

As this feature is currently preview it will ask you to register before completing the download. Arc4Arc5Once the registration is completed, we can either copy the command or click download to get a copy of the PowerShell script. Below is how the script should look the only difference would be the Azure specific setting like resource group, tenantid…Arc6Once the script has run and the connect command has completed it will request that we connect to the device login site https://Microsoft.com/devicelogin and put in the authentication code. Arc7Arc8

Once completed go back to the PowerShell windows that the script was run from and we should see successfully onboarded to Azure resource.Arc9After a few minutes the device should show in Azure Arc. Arc10We can now apply Azure policies .Arc11

There are some additional steps required to configure the servers to integrate with Azure log analytics.

First step is to install the MMA (Microsoft Monitoring Agent) agent, to download the agent go to Log Analytics workspace and select the require workspace > Advanced settings

Arc14

Select the required connection source, then OS version. We will also need to take note of the workspace ID and Primary Key which will be used during the agent install to connect to the log workspace.Arc15

Go through the agent install.Arc16

Select Azure connect the agent to Azure Log Analytics (OMS).Arc22

To connect to Azure log analytics put in the workspace id and key.Arc18

Once the install has finished we can check the agent in control panel > All Control Panel Items > Microsoft monitoring agent.Arc20

We should now be able to query log from the server in Azure Arc for servers. Arc21

 

Configure Azure Site Recovery for VMware

Azure site recovery (ASR) is a DR / Migration tool from Microsoft and can be used to configure DR between data centers or Azure.

In this post we will be going through setting up ASR to replicate a VM from VMware to Azure.

There are some limitations for ASR these are listed the below link

https://docs.microsoft.com/en-us/azure/site-recovery/vmware-physical-azure-support-matrix

The main limits for VMware are guest disk need to be less than 4TB and vCenter needs to be at least 5.5.

I have a previous post on how to configured a recovery service vault so I wont be going over that again but if you need to configure here is the previous post.

https://thesleepyadmins.com/2018/11/23/azure-vm-backup-using-azure-recovery-service-vault/

Logon to Azure

Go to Recovery Services vaults

ASR1Go to the already configure vault, select Site Recovery and click on prepare infrastructureASR2Once the wizard has started select the require goalsASR3I am not running the planning tools as this is a test but it is recommended to run before starting a deployment to verify the required bandwidth. ASR4Next we will download the OVA appliance that will be imported to VMwareASR5Once the OVA has been downloaded and imported to VMware on boot up the server will require you to read / accept a licence agreement and provide an administrator password.

Give the server a name (this will show up in as the configuration server in Azure after the setup as been completed)ASR6Next step is to sign in to Azure tenant that the server will connect to for replicationASR8Next we will go through the configuration steps first step is to set the interface that will be used to connect to on-prem devices & connection back to Azure there can be two different NIC’s assigned if required. ASR9Next is to configure the Recovery vault that will be used, select the subscription, the recovery vault RG and recovery service vault that has been configured. ASR10Install the MySQL software ASR11Next a validation test will run. (I am getting a warring for memory and CPU as I didn’t have enough memory / CPU and had to edit the VM to run on less resource but it will still complete)ASR12Next is to connect to the vCenter server that is running the VM’s that are to be replicated to Azure. ASR13Last step will configure the configuration server in Azure.ASR15Once this has been completed we can go back to the Azure portal and we should now see the configuration server show under prepare infrastructure setupASR16

Select the subscription and deployment model to be used for failover I am using Resource ManagerASR17Next create a replication policy to apply to the ASR configuration server. ASR18ASR19Once the configuration is done we can now protect and replicate our on-prem VM’s , go back to site recovery and select step 1: Replicate Application ASR20Select source, source location (Configuration server on-prem)Machine type (Physical / virtual), vCenter (If virtual) and the process serverASR21Select the subscription, RG that the VM will replicate too and the deployment modelASR22Next select the server that will be replicated the VM must be powered on and be running VMware tools be available for replication other wise they will be grey-outASR23Select the required disk type, storage account ASR24last step is to assign the policy required (Multiple policy can be created base on the recovery time requirements and retention times)ASR25

Last step is to enabled replication

ASR26

Once enabled check the site recovery jobs to see the progressASR27Once replication has completed we can create a recovery plan, go to recovery Plans (Site Recovery and select Recovery planASR28Give the plan a name, select source, target , deployment type and select the VM’s that will be added to the recovery.ASR29ASR31

Azure Migrate Services Setup

With more companies looking to move workloads from on-prem to cloud providers, it can be difficult to work out the cost for current workloads.

In Azure we can utilize Azure Migrate Services.

At the time of this post VMware is only supported, this will be extended to Hyper-v in future releases. VMware VMs must be managed by vCenter Server version 5.5, 6.0, 6.5 or 6.7.

In this post we will be going through the process off assessing the on-prem VMware environment and view the assessment report.

The environment we will be assessing is VMware vCenter 6.7 and ESXi 6.7 and a VM running Windows Server 2016.

The architecture of the Azure Migrate Service is shown in the following diagram

AZMIG

Below is the process

  • Create a project: In Azure, create an Azure Migrate project
  • Discover the machines: Download collector VM as an OVA and import to vCenter
  • Collect the information: The collector collects VM metadata using VMware PowerCLI cmdlets. Discovery is agentless and doesn’t install anything on VMware hosts or VMs. The collected metadata includes VM information (cores, memory, disks, disk sizes, and network adapters). It also collects performance data for VMs
  • Assess the project: The metadata is pushed to the Azure Migrate project. You can view it in the Azure portal.

Logon to Azure

Go to All services search for migration projectAZMIG_1

Select Create migration project

AZMIG_2

Give the project a Name, subscription, Resource group & Geography

AZMIG_3

Select Discover & Assess AZMIG_4

Select Discover and Assess. then Discover machines AZMIG_5download OVA. The system requirement for the OVA are:

CPU: 8 vCPU’s; Memory: 16GB; HardDrive: 80GBAZMIG_6

Next step is to import the OVA to VMware

Go to vCenter

AZMIG_7

Browse to the OVA file location and selectAZMIG_8Select the Name and location of the OVAAZMIG_9Select the destination cluster AZMIG_10Click NextAZMIG_11Select destination data store and specify either thick or thin provisioned diskAZMIG_12Select the port group tha the VM will useAZMIG_13Review and confirm settingsAZMIG_14

Once the OVA is imported, power on the VM

Read and accept the license terms and give the collector an admin password.

Log into the VM and run the connector utility on the desktop.

AZMIG_15

Got through the prerequisites checksAZMIG_16

Next step is to connect to the vCenter. Put in the vCenter IP or hostname, Username / Password and once connect select the cluster or host that is currently running the VM’s that need to be assessed for migration.

AZMIG_17

Next step is to connect back to Azure using the migration project credentials that were generated when creating the projectAZMIG_19AZMIG_18

Click continue and the last screen will start the discovery this can take a while to complete (60 minutes or so)AZMIG_20

Once the discovery has completed, we then need to Create assessmentAZMIG_21

Create a new group and select the VM that will be assessedAZMIG_22

Once this has completed go to Overview and click on the assessmentAZMIG_23

Once in the assessment you can see the readiness of your VM and the Monthly estimated cost for running the workloads and AZMIG_24

Click on the VM to view specific details and performance statsAZMIG_25

We can now see what the cost will be for migrating workloads to Azure and this can be presented to give a better understanding of the cost savings that can be achieved with cloud migrations.

 

 

 

 

Azure Configure vNet peering

To allow communication between vNet’s in Azure we can set up peering connections. This is useful if there is a need to have different vNet’s for things like web app’s and backend database zones.

To configure peering we will require two different vNets both must be in the same Azure region.

Currently when I try to ping a VM that is running in a different vNet there is no communication.vNet01

Logon to Azure

Go to All services > Virtual networksvNet04

Once in Virtual networks select the network that will be configure for peeringvNet02

Once the network blade is open go to peering > AddvNet03

Enter a Name, select the Subscription that the other vNet is in. Then Select the Virtual Network. Under configuration select Enabled and the last step tick Allow forwarded trafficvNet05

Below are some details on three options:

Allow forwarded traffic: This setting allows the peer’s forwarded traffic (traffic not originating from inside the peer virtual network) into your virtual network.
Allow gateway transit: Allows the peer virtual network to use your virtual network gateway. The peer virtual network cannot already have a gateway configured, and must select ‘use remote gateway’ in its peering settings.
Use remote gateway: You will need to Select this option if you wish to use your peer’s virtual network gateway. The peer virtual network must have a gateway configured, as well as ‘allow gateway transit’ enabled. Only one peering in this virtual network can have this enabled. You cannot use this setting if you already have a gateway configured in your virtual network.

Once all settings are confirmed click ok to create the peeringvNet06vNet07

Two allow communication both ways, there will need to peering setup on the App network aswell.

Once both are enabled we can now see response to ping requestsvNet08

To lock down communication between the networks we can add NSG’s to restricted what inbound and outbound traffic is allowed from the subnet’s.

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 enabledMFA6

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

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 groupMFA2

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

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 MFAMFA9

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