Zero-trust with Cloudflare Access and Azure Active Directory

One of the cool things with Azure Active Directory is the risk indicators that can be collected into from different systems such as Identity Protection, Intune, Azure ATP and Defender ATP. With this information collected it means that systems that integrate into Conditional Access with Azure Active Directory can do real-time checks before users are allowed access to an app or service.

Now combining this, we can integrate with a new feature from Cloudflare called Cloudflare access (Access is free for up to 50 users –> . Access provides zero-trust access to web applications. (Both external and internal using Argo Tunnel, more on that a bit later..) It can do this by collecting device posture from either Azure AD or Tanium, and collecting user information from Azure Active Directory. From an identity perspective it can integrate with the following iDP

So in this example I will be setting up an internal service with Argo tunnel which will then be exposed using Cloudflare access and integrated with Azure Active Directory. Which essentially will look like this. Pretty similiar to Azure AD Application proxy, but provides wider range of support of iDP and wider range of supported protocols. While Cloudflare access is based upon web applications, you can also use Argo to publish RDP/SSH/SMB and other orbitary TCP protocols.

Cloudflare Argo Tunnel · Cloudflare Access docs

1: Setup an integration with an idP

The first time you setup Cloudflare access you will need to define an access URL under the subdomain, remember the name of the URL you use here since you need it when setting up the iDP in the next step. Then go into Cloudflare Access and under Authentication and click Add. Then define iDP of choice in my case I used Active Directory, in which case I need to create an app registration in Azure AD and define the following permissions.

Click Microsoft Graph and then delegated permissions.

  • email
  • openid
  • profile
  • offline_access
  • User.Read
  • Directory.Read.All
  • Group.Read.All

Also remember to enter an reply URI as part of the Azure AD configuration which needs to be in the form of


Then you need to define the Application ID, Application Secret and Directory ID as part of the Cloudflare integration. Then you just need to click Test to verify the permissions.

2: Setup Argo tunnel

Next is that you need to download the cloudflared (Cloudflare Argo Daemon) binary from here –> which will be used to initiate the reverse TCP session to cloudflare and will be connected to your account.

Run the command

cloudflared tunnel login

This will open up a web browser session and require you to login with your account, then you need to authorize it to a server

Then you need to setup the tunnel. From where the cloudflare executable is configured you need to point to the resource which is running the service (example) NOTE the site domain name needs to be linked to a FQDN you have configured within Cloudflare.

cloudflared tunnel –hostname –url http://localhost:8080

It should be noted that this will only run the service as long as the powershell/cli/cmd window is running. If you want to have it persistenly running in the background you need to run the command (cloudflared service install) 

In my example I have a local IIS server running on my computer.
Once it is running propagating, it will add a host name entry into the domain name in cloudflare management console.

3: Define Policies and define access

Next is we need to define this as an application in Cloudflare Access and define policies on who should get access. In the cloudflare teams dashboard define

Add a application

Then choose self-hosted

Then define the application name based upon the URL defined in the setup of the cloudflare tunnel

Then click next and define rules for access. Since we are using Azure AD we also have the option to define Azure AD Groups or UPN’s to get access to the service


Then click next and finish. The application should now be available in the applauncher portal for the defined users which you have provided access to. As I mentioned like with applicaiton proxy this is using a reverse TCP session which will only allow authenticated traffic to reach the application trough Cloudflares Networks.


Now Argo can of of course be used to proxy applications like this, but can also with this be used to provide access to internal applications so that it can be protected against DDoS attacks.



Leave a Reply

Scroll to Top