For a long time now, I’ve been hearing from customers they want a Secure Clientless Remote access solution they can trust. It might shock you just how many times I’ve run across Enterprise IT orgs still dependent on a now deprecated SSLVPN solution from a Hardware Firewall vendor. The only use case for it , is giving 3rd parties access to maintain systems via RDP.

Here’s what I’ve come up with. I’ve actually built this and will continue testing it. Apache Guacamole is open source and really not that hard to deploy in Docker. I used Claude to generate an Install script, so I spent all of 10 minutes installing it. Given how Guacamole works, it’s not something you just want to have open access. So it needs to be well protected.

The Architecture

1. User: Hits the Avi Virtual Service (HTTPS).
2. Avi (SAML SP): Redirects the user to Entra ID for MFA/SSO.
3. Entra ID (IdP): Validates the user and sends a SAML token back to Avi.
4. Avi: Validates the token and grants access to the Guacamole Web Server (Tomcat).
5. Guacamole: Uses its internal guacd proxy to connect to the backend RDP servers.
6. vDefend: Ensures lateral security by only allowing the AVI SE’s to talk to Guac and Guac can only talk to the Internal VMs that vDefend Allows it to.

Aside from the Security that AVI provides with Full SSL Encryption (including LetsEncrypt Certs) and SAML for MFA. AVI also provides you unmatched End to End Analytics so if there was any performance issues, you can quickly find them.

Lastly, I configure a vDefend Distributed Firewall Policy set to ensure maximum security around the whole setup.

An Allow rule so only the AVI Service Engines can talk to Guac

An Allow rule so Guac is only able to RDP to the hosts it must have access to

Block Anything else and don’t let Guac RDP to Anything else

The end result is Clientless access to Only what I want and where I want to be. I can even have AVI pass off the Authentication Header to Guac, so when the user signs in via SSO, it’s mapped all the way through, otherwise you get the standard Guac Ui login.

The testing I’ve done with this setup so far it works well. I need to do more fine tuning. And if I ever get Openclaw running, maybe I’ll have it write a better looking front end interface for Guacamole.

-Britton

This was written by Me. Not an LLM.

For many years now, I’ve been hearing from customers of all shapes and sizes a similar refrain. “Zero Trust is not achievable” , “Segmenting my Apps for Security takes too long”, “We can’t reconstruct the entire network just to make Apps more secure”, “I don’t have visibility of what my Apps are talking to”, “I already have too many security tools”… If you’ve worked in an Enterprise IT organization for any length of time you’ve heard all these too and more.

Having seen how the Data Center Security problem is viewed from multiple angles. I come back to where I started which is VMware (now by Broadcom), and what we now call the vDefend Security Services Platform. This powerful solution encompasses both Best in class defense with the Distributed Firewall and Advanced Threat Prevention services for complete security in the Data Center.

Over the coming weeks I’m going to take on each one of these critical feedback points, and show how customers are able to overcome them. Change is hard, and at some point everyone has to make a decision to this question. What do you want more? To remain the same or do you want real results with trackable metrics? I believe it goes without saying that remaining the same only leaves you vulnerable. So change is your only option. The attackers adapt their strategies constantly, and so must you. Let’s get started.

Leave Comments on my LinkedIN post for this thread. https://www.linkedin.com/posts/gigabrit_new-blog-series-incoming-lets-build-a-secure-activity-7393754339036758016-K5Xn?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAxjQwQBCCc84y2NN2WWIkIqW1s6EbbbmHQ

-Britton Johnson | @vcixnv

VCIX-NV | VCAP-NV

Welcome to Part 4 of my Blog Series on building my Zscaler Lab. We started with the basic essentials of setting up User Authentication via Azure Entra ID as our Identity Provider. Now that we have users and groups sync’d from the on Prem AD to Azure and into Zscaler via Entra ID, we can begin creating policy for what those users can connect to, both on the Public Internet and Private Applications in the data center.

First question I usually get is, “Yeah but how are you getting connected?”

That answer is pretty easy, we deploy a lightweight traffic forwarding agent called the Zscaler Client Connector. No actual data processing happens on device. All it does is make a validated connection to the Zscaler cloud, and then everything happens there.

Your Traffic and Application access are always under Your control.

Simply because Zscaler is a Cloud Network and Security service , many people assume Zscaler takes control of your traffic. This is not the case. Every Zscaler customer is in full control of everything their devices are doing while connected to the Zscaler Cloud. It’s the Policy that is created that dictates where things go. See Reference Architecture for Traffic Forwarding for more information.

Policy Flow

The ZIA service edges feature two main modules: Web and Firewall, for policy enforcement. It’s important to understand the flow order and process by which Zscaler handles Policy Enforcement. Here’s a run down.

■Outbound traffic first encounters the Firewall (FW) module. If it’s web traffic and complies with FW policies, it’s forwarded to the Web module for policy evaluation.

■If web traffic violates a firewall policy, both Firewall and Web Insights logs will show the traffic as blocked.

■Conversely, if the traffic clears the firewall policy but fails a web policy, the Firewall Insights logs will mark it as allowed, while the Web Insights logs will record it as blocked.

■Should a web policy permit a transaction but a firewall policy opposes it, the firewall policy prevails.

■In the Web module, traffic violating a web policy is blocked. This module evaluates policies based on the traffic type—TLS or Plain HTTP.

■For SSL or TLS traffic, the ZIA Public Service Edges’ policy assessment and implementation depend on settings like traffic forwarding method, SSL inspection actions, and policies for CONNECT requests or SNI.

Following these guidelines you’ll start building your Policy Framework.

  Deconstructing Policy Components

High Level Use Case	Security Controls	Notes
Who can access What? (Network level)	Firewall Control, DNS Control, IPS ControlWho? (All)What? (IP Address and FQDN)Access Medium? (Network Services)	No visibility into Application data IPS limited to signatures applicable for visible info i.e. protocol headers barring application data
Who can access What? (Application level)without SSL Inspection	CloudApp Control, URL Control, Browser Control(?)Who? (All)What? (URLs, CloudApps)Access Medium? (Application Protocols, User agent, etc.)	With “SSL Inspection == OFF”, Destination identification and classification limited to “HTTP GET- Host” info for HTTP traffic and “SNI” info for SSL/HTTPS trafficNo visibility into accessed Content (payload) and henceforth following are unavailable,Advanced URL and CloudApp Control (additional context with SSL inspection)File Type controlData Loss Prevention
+ Who can perform What? (with SSL Inspection )Granular controls within a given application for different user activities	CloudApp Control, URL Control;File Type Control, Sandbox;Data Loss Prevention;Who? (All)What? (URLs, CloudApps)Access Medium? (Application Protocols, User agent, etc.)	With “SSL Inspection == ON”, Complete visibility into accessed Content offers Full Control

Hopefully this helps you start to get going on your Policy Framework.

-Britton

Welcome back, so far we’ve stood up our Azure and Zscaler tenants and connected them with SAML Authentication. Next we need to enable the SCIM (System for Cross-domain Identity Management). If you’re an old Systems and Data Center person like me, don’t feel bad if you had to look up what SCIM is. I had to look it up too.

A quick check of the Book of Knowledge (aka Wikipedia) tells us…”SCIM  is a standard for automating the exchange of user identity information between identity domains, or IT systems.”

Easy enough, essentially it’s a trusted method for managing CRUD. With the added benefit of also being about to tell the system it’s updating specific attributes about the user or group that it’s changing.

Let’s get started , Zscaler official documentation for this process is here.

Login to your Zscaler Admin portal , I’m doing this in the ZIA admin portal. Then we’ll navigate to the Administration > Authentication Settings section.

Now let’s go to Identity Providers tab, Edit the IdP we setup before.

Scroll to the Provisioning Options section.

Click Enable SCIM Provisioning.
Copy the Base URL URL and the Bearer Token to your secure notes.
Click Save when complete.
Activate your changes.

Now let’s add in the Exempted URL’s. Browse to Administration → Cloud Configuration → Advanced Settings

Scroll to AUTHENTICATION EXEMPTIONS and add the following URLs.

login.windows.net

login.microsoftonline.com

*.windowsazure.com

Click SAVE, and of course, Activate your changes!

Next we’re going to login to Azure and connect everything together. On your Azure Portal, browse to your Entra ID service > Manage > Enterprise Applications , then Select your Zscaler ZIA Tenant Cloud we setup earlier. In my case it’s Zscaler Two.

From there, expand under Manage and select Provisioning.

Select the Get Started button to launch the Provisioning wizard. First change the Provisioning Mode to Automatic.

Under Admin Credentials enter the following:

Tenant URL: Paste in the Base URL from your Secure Notes

Secret Token: Paste in the Bearer Token from your Secure Notes

Click Test Connection

You should get a message indicating a success. If you get an error, double check your Tenant URL and Bearer Token are correct. If needed re-generate a new Bearer Token in the ZIA Admin Console.

After getting a Confirmation of a Successful Test, Click Save.

Now Exit the Provisioning by clicking the X in the right corner. Then we need to re-enter Provisioning by Edit Provisioning. This is because the Settings section won’t update without exiting first.

Once back in the Provisioning page, Expand the Settings section and set the Scope to Sync Only assigned users and groups make sure the Provisioning Status is On, then click Save at the Top. Exit the Provisioning pane.

Assigning users and groups

Now in the Enterprise Application in Azure for your Tenant, Select Users and Groups. We will add the appropriate Users/Groups that we want to use Entra ID for IdP into Zscaler.

Select Add user/group and assign your resources. Be sure to save of course.

At this point you should be able to Test Logging into Zscaler Client Connector with your Entra ID Credentials.

When you sign if you are brought to your iDP sign in page, Success!

Next series of Posts we’ll start digging into some additional lab content and how the services for Secure Internet and Remote Application Access work.

We’re getting closer to the real fun where we can start provisioning Application access and Securing traffic with Zscaler. Before we can do that we have some work to do.

Let’s connect an Identity Provider (IdP) to our Zscaler Tenant.

If you’ve seen a Zscaler presentation at all , you’ve probably seen the above image. This effectively maps out the Zero Trust process for Authentication and where it fits in the overall scheme of establishing connections. I’ve highlighted the piece covered in this post in the slide above. See the official documentation here. https://help.zscaler.com/zia/adding-identity-providers

Step 1: Login to your Zscaler Admin Portal for the Cloud your tenant is provisioned on. Assuming you are a customer , partner, or working with your Zscaler team on setting up a PoV test, use the link provided to you.

On the Admin page, go to Administration> Authentication

Then on the “Identity Providers” tab, we’ll select the “+ Add IdP” , if you already happen to have one setup, and are prompted with another option, just select “Add another…” and Next.

On the Add IdP page we’ll need some of the info we saved from Azure before, if you didn’t save it you’ll need to go back into your Azure Tenant and get it.

Enter the following required details:

• Name: Azure (or whatever you want)
• Status: Enabled
• SAML Portal URL: <Paste in Login URL link you saved.>
• Login Name Attribute: NameID <– This is case-sensitive.
• IdP SAML Certificate: Upload .pem file you saved from before
• Vendor: Microsoft Azure Active Directory

You should end up with an IdP profile that looks something like the following.

Now that we’ve connected our Azure IdP, we need to set Zscaler to use it. Navigate back to Administration>Authentication , then just select the SAML Authentication Type. Select Save at the bottom of the page, then be sure to “Activate” your changes.

That’s really it for enabling an authentication source. Next Post I’ll cover off enabling SCIM for updates and changes.

Everything in the world of Zero Trust comes down to a few basic ideas. The first and probably most important is Identity. Network and Application access in Clouds has long been primarily controlled strictly based on WHERE a given connection is coming from not WHO is initiating it.

I won’t detail the creation of an M365 Tenant here, but for detail sake here’s what I have. It’s just a Trial Licensed M365 Business Standard tenant. It comes with everything we need to get the ball rolling. I’ve activated a custom domain name inside it already. I’ve also installed and connected the Entra ID Sync tool from my on prem AD Controller and am syncing user accounts.

SAML

Zscaler’s preferred method for user authentication uses Security Assertion Markup Language (SAML). Though ZIA allows other authentication methods, ZPA only supports SAML. Zscaler supports any SAML 2.0+ (POST Binding) compliant Identity Provider (IdP).

There are many IdPs, however the ones Zscaler sees most often are Azure AD, ADFS, and Okta. This post will focus on integrating authentication with Azure and what it takes to setup Azure as your IdP inside Zscaler.

In your Azure Tenant, view the Entra ID Overview page, then begin the process of adding your custom domain name. Microsoft Instructions here.

Once your custom domain is active and if you are syncing AD resources to Azure , make sure the users and groups are all populated in Entra ID.

Now the fun part begins, building the actual SAML connections to your Zscaler Tenant.

Back on the Entra ID Overview page select the Enterprise Applications option.

Then select + New Application

At the search box for the Catalog of applications, enter “zscaler”, then select the correct Zscaler Cloud for your Instance. Click the “Create” button to add it. For Zscaler Internet Access on zscalertwo.net select Zscaler Two.

After the Zscaler application is created, select the “Single Sign-On” option. Then click the SAML box.

On the Basic SAML Configuration click Edit.

This is where things get a bit more specific. On the Basic SAML Config page, you’ll need to copy down a few bits of information as you’ll be copying and pasting information between Azure and your Zscaler Tenant. It’s a good idea to have a Secure Notepad document that can hold some of this information.

First update the Reply URL (Assertion Consumer Service URL) it’s conveniently listed where it says “Patterns”.

Copy the Patterns URL, then select “Add reply URL” and paste it there. As well as in the Sign on URL area below. Click “Save” at the top, then click the X to close the window. When prompted to Test single sign-on, click “No, I’ll test later”.

Scroll down to the SAML Certificates section. Click the Download link for the Certificate (Base64) and save that in your Secure Storage with your other setup information.

IMPORTANT NOTE: Zscaler only supports certificates that end with the .pem extension. So we’ll need to modify the Base64 certificate from Azure before we can use it in the Zscaler Admin portal. Simply enough, just change the file extension to .pem from .cer

Back on the SAML page, scroll down again, and copy the Login URL, save it in your Notepad for later.

That’s the Azure side for enabling SAML for Zscaler, next post I will walk through the Zscaler side, which is detailed here in the very useful Zscaler Help site.

Welcome to my Blog on building out my Zscaler Personal Tenant. I will walk through the required steps to create and connect my Home Lab environment to my Zscaler Cloud Zero Trust Exchange Tenant.

Here’s the breakdown.

Identity:

My lab has two main Identity Sources or Providers. (IdP)

Azure AD now called Microsoft Entra ID will be my primary Identity Provider with Local User accounts synced from my On Prem Microsoft Active Directory. Technically you could say this is only one ID Source but I see distinctly different uses here even though they are synced together.

Datacenter:

I have two Datacenter locations, each of them operating as independent locations. Each has its own Edge Firewall in place. They are interconnected via an IPSEC VPN tunnel for ease of access and management during deployment. This however will prove to be our first major use case for connecting to the Zscaler Zero Trust Exchange. Enabling secure communications between each Datacenter WITHOUT a VPN and WITHOUT opening any External Firewall Ports.

Inside each Datacenter is a Nested VMware ESXi Cluster of vSphere Hosts with a Single NSX Manager controlling both environments. The goal here is to show how and where adding Zscaler to your Datacenter Environment can increase the level of Security that protects your most critical Infrastructure. While at the same time enabling Secure connectivity to the Applications inside each location and Secure Connectivity to the Management Plane (vCenter, NSX Manager, etc).

Existing Infrastructure for this Build:

• VMware vSphere Hosts (nested)
• VMware vCenter Servers (1 in each site, not linked)
• VMware NSX Manager
• Microsoft Server 2022 Active Directory
• Microsoft Certificate Authority Services (offline Root with Issuing CA)
• Firewalls for Connectivity
• VLAN backed networking for ease of initial deployment
• Simple BGP Pairing between NSX T0 and pFsense Gateway
• M365 Account with Entra ID
• Open EMR
• WordPress