Tutorial: Use CloudConnexa for Zero Trust Network Access (ZTNA)
Configure CloudConnexa as a full ZTNA solution — enforce least-privilege access with SAML/Entra ID group mapping, device posture checks, location context policies, Cyber Shield filtering per Shield Policy, and Access Groups for private apps and SaaS.
Overview
Use CloudConnexa to implement Zero Trust Network Access (ZTNA) for private applications, SaaS applications, and internet access.
A Zero Trust approach follows the principle: never trust, always verify. Instead of granting access because a user or device is on a trusted network, CloudConnexa can evaluate identity, group membership, device security, and location before providing access to resources.
In this tutorial, you'll configure CloudConnexa to:
Provide least-privilege access to private applications based on User Group membership.
Protect sanctioned SaaS applications by routing their traffic through a controlled network egress.
Authenticate users with Microsoft Entra ID (formerly Azure Active Directory).
Provision users with System for Cross-domain Identity Management (SCIM).
Require authorized devices with Device Posture checks.
Restrict connections by location with Location Context.
Apply Cyber Shield Domain Filtering with Shield Policies.
Monitor access and DNS activity.
This architecture supports both Zero Trust Network Access and secure remote access without requiring users to be physically connected to a trusted office network.
How the ZTNA configuration works
CloudConnexa combines several controls to determine who can connect and what they can access.
Control | Purpose |
|---|---|
Microsoft Entra ID and SAML | Authenticate users and map identity attributes to CloudConnexa User Groups. |
Access Groups | Provide least-privilege access by defining which User Groups can reach specific Applications and IP Services. |
Device Posture | Require devices to meet security requirements, such as an approved client certificate or antivirus software. |
Location Context | Allow or block CloudConnexa connections based on the device's public IP address or geographic location. |
Shield Policies | Apply different Domain Filtering and Traffic Filtering protection to User Groups. |
DNS logs and Access Visibility | Provide information for monitoring DNS activity and access to resources. |
Device Posture can evaluate attributes including the operating system, antivirus software, client certificates, and disk encryption. Location Context can control connections using IP address ranges or countries determined from IP geolocation.
Protect private applications
Don't rely on physical presence on the office network as authorization to access private applications.
Isolate private application servers so that application traffic must pass through the CloudConnexa Connector. Users then connect to CloudConnexa before accessing those applications, whether they're working remotely or from the office.
Configure private applications as CloudConnexa Applications and use Access Groups to grant access only to the User Groups that need it. Applications can also restrict the protocols permitted for the service.
Protect SaaS applications
For SaaS application protection, configure selected SaaS domains as Applications and route their traffic through a private network connected to CloudConnexa.
The SaaS service then sees the public source IP address of that network. Where supported by the SaaS provider, allowlist that public IP address so users must access the service through the approved CloudConnexa path.
Before you begin
Before starting this tutorial, ensure you have:
A CloudConnexa account and Cloud ID.
Administrative access to your WPC.
Administrative access to Microsoft Entra ID.
A private network that you can connect to CloudConnexa.
A system or compatible router for the Network Connector.
The private applications and SaaS applications you want to protect.
The User Groups and access requirements for your organization.
For this example workflow, you'll also need a client certificate if you want to reproduce the certificate-based Device Posture check.
Step 1: Create your User Groups
Create User Groups that represent roles requiring different access.
For example, create separate groups for users who need access to different private applications or who require additional location restrictions.
Navigate to Users → Groups.
Select Add Group.
Enter a unique Group Name.
Configure the User Group settings.
Select Add Group.
Repeat these steps for each required User Group.
You'll use these User Groups later to assign access and security controls. For example, an Access Group can use a User Group as its source to control which Network resources those users can access. You can also apply Device Posture, Location Context, and Shield Policies based on User Group.
For details, refer to Add a User Group. The current User Group configuration also supports assigning Device Posture and Location Context policies.
Step 2: Set the WPC topology to Custom
Set the WPC topology to Custom before creating the Network. Custom topology enables Access Groups to control connectivity between resources in your WPC.
Navigate to Settings → WPC.
Set Topology to Custom.
Save the change.
You'll configure the Access Groups that provide least-privilege access while creating the Network.
Step 3: Create the Network and configure access
Create a Network for the private resources you want users to access through CloudConnexa.
Configure the Network
Navigate to Networks → Networks.
Select Add Network.
Select Remote Access.
Select Continue.
Enter the Network details.
Select OpenVPN or IPsec for the Connector tunneling protocol.
Configure and deploy the Connector.
Verify the Connector is online.
For the complete workflow, refer to Add a Network for Remote Access Using the Network Wizard.
Add private and SaaS Applications
Add the private and sanctioned SaaS applications that CloudConnexa should route through the Network.
Add private applications
For each private application:
Add an Application using its domain name.
Select the protocols users are allowed to use.
Configure DNS so the application's domain resolves to the appropriate private resource.
Using Applications instead of exposing broad private network routes supports least-privilege access and reduces the routes exposed to connected clients.
Add sanctioned SaaS applications
Add each sanctioned SaaS service as an Application using its public domain name.
Traffic for those domains is routed through the connected Network before reaching the internet. This gives the traffic the public source IP address of that Network, which you can later allowlist in the SaaS service.
Add IP Services
Add an IP Service when users or CloudConnexa need to reach a resource by IP address or subnet rather than by domain name.
For example, if you're using a private DNS server on the connected network, add its IP address so CloudConnexa has a route to the DNS server.
Select Add IP Service.
Enter a Name and, optionally, a Description.
Select the Protocol, or leave the default All to allow all supported network protocols.
Enter the IP Address or Subnet for the resource.
Select Add IP Service.
Repeat these steps for additional IP addresses or subnets that users need to access.
Configure least-privilege access with Access Groups
Use Access Groups to control which User Groups can access the Applications and IP Services in your WPC. This provides least-privilege access by giving users access only to the resources they need.
Tip
A User Group organizes users and provides the source for an access rule. An Access Group defines which sources can access which destinations. For example, you can create an Access Group that allows one User Group to access a specific private Application without giving that group access to the entire Network.
When you reach Configure Access Groups in the Network Wizard:
Review the existing Access Groups.
Note
The list includes the Default Full Mesh Access Group, which allows unrestricted connectivity between WPC resources.
Select Add Access Group.
Enter a Name and, optionally, a Description.
Under Selected Source, expand User Groups.
Select the User Group that should receive access.
Tip
You can select multiple User Groups when they require the same access.
Under Selected Destination, expand Networks.
Select the Network containing the resources those users should access.
Select Add Access Group.
Repeat these steps to create additional Access Groups when different User Groups require different access.
Review the configured Access Groups.
Delete the Default Full Mesh Access Group.
Important
The Default Full Mesh Access Group allows connectivity between all WPC resources. Removing it ensures that access is controlled by the Access Groups you configured for your Zero Trust model.
Select Finish to complete the Network Wizard.
Step 4: Configure private DNS
If your private Applications use domain names that are resolved by a DNS server on your private network, configure CloudConnexa to use that server.
Tip
Before configuring the DNS server, ensure its IP address is reachable through your WPC. The DNS server can be connected directly as a Host or be reachable through a connected Network.
Navigate to Settings → DNS.
Select Edit DNS Server Details.
Under DNS Servers, select Custom.
Enter the IPv4 address of the Primary DNS Server.
If applicable, enter the IPv4 address of the Secondary DNS Server.
Select Update.
Review the configuration and select Confirm.
CloudConnexa now sends DNS queries that require your private DNS server to the configured server.
For more information, refer to Set Private DNS Servers.
Step 5: Configure Microsoft Entra ID authentication and provisioning
Configure SAML authentication with Microsoft Entra ID (formerly Azure Active Directory) so users authenticate to CloudConnexa with your organization's identity provider.
Configure CloudConnexa as an enterprise application in Microsoft Entra ID.
Configure SAML authentication between Microsoft Entra ID and CloudConnexa.
Configure User Group mapping to map identity attributes from Microsoft Entra ID to the CloudConnexa User Groups you created for this deployment.
Test authentication with a user assigned to the enterprise application.
Verify that the user is assigned to the expected CloudConnexa User Group.
For the complete SAML configuration, refer to Tutorial: Authenticate Using SAML with Azure Active Directory (a.k.a. Microsoft Entra ID).
Provision users with SCIM
You can also configure System for Cross-domain Identity Management (SCIM) to automatically provision and manage CloudConnexa users from your identity provider.
Configure SCIM if you want Microsoft Entra ID to create, update, and manage users in CloudConnexa instead of managing them separately.
Refer to About SCIM for the provisioning requirements and configuration options.
Step 6: Require compliant devices with Device Posture
Create a Device Posture policy to allow connections only from devices that meet your organization's security requirements.
Navigate to Users → Device Posture.
Select Add Policy.
Enter a Name and, optionally, a Description.
Under Apply To, select the User Groups that require the policy.
Under Configuration, locate the operating system you want to configure.
Add the required Device Posture checks.
For example, for company-owned Windows devices, configure checks for Microsoft Defender and a client certificate issued by your organization.
Add additional checks as required.
Select Add Policy.
CloudConnexa evaluates Device Posture when the device establishes a tunnel and periodically while the connection remains active. A User Group can be assigned to only one Device Posture policy.
For additional configuration options, refer to Add a Device Posture Policy.
Step 7: Restrict connections with Location Context
Create a Location Context policy if users should connect to CloudConnexa only from approved locations.
For example, you can allow connections for a User Group only when the connecting device uses your office's public IP address. CloudConnexa can evaluate the device's IP address or its country based on IP geolocation.
Navigate to Users → Location Context.
Select Add Policy.
Enter a Name and, optionally, a Description.
Under Apply To, select the User Groups that require the location restriction.
If needed, configure the policy to Allow connections when the device's IP address matches the approved IP address or subnet.
If needed, configure country-based rules for additional location restrictions.
Configure the action to take when the device doesn't match an IP address or country in the policy.
Save the policy.
For more information about how CloudConnexa evaluates IP address and country rules, refer to About Location Context Policy.
Step 8: Configure Cyber Shield with Shield Policies
Use Shield Policies to apply Cyber Shield protection based on the security requirements of each User Group.
Every WPC has a Default Policy. Create custom Shield Policies when specific User Groups require different Domain Filtering or Traffic Filtering settings.
Configure Domain Filtering
Navigate to Shield → Policies.
Configure the Default Policy with the baseline filtering you want to apply.
If a User Group requires different filtering, select New Policy.
Enter the policy details.
Select the Domain Filtering tab.
Turn on Domain Filtering.
For Protection Level, select Custom.
Set the content categories required by your organization's internet-use policy to Blocked.
Assign the appropriate User Groups to the policy.
Save the Shield Policy.
Repeat these steps for Shield Policies with different filtering for different User Groups.
User Groups that aren't assigned to a custom Shield Policy continue to use the Default Policy.
With the Custom Protection Level, you can configure each of CloudConnexa's 43 Domain Filtering content categories as Monitored or Blocked.
Configure Traffic Filtering
If you also want to detect or block threats in tunneled traffic:
Edit the appropriate Shield Policy.
Select the Traffic Filtering tab.
Turn on Traffic Filtering.
Select Per Priority to apply protection based on threat severity, or Per Category to select specific threat types.
Configure the protection required for the User Group.
Save the policy.
Traffic Filtering inspects tunneled traffic and can use IDS to monitor threats and IPS to block them.
Step 9: Prepare devices to meet the Device Posture policy
Prepare company-owned devices to meet the requirements of the Device Posture policy you configured earlier. The exact steps depend on the checks you enabled in that policy.
On a company-owned device, verify that it meets the requirements of the assigned Device Posture policy.
Note
For example, if you configured the policy to require Microsoft Defender, verify that Microsoft Defender is installed and running. If you configured operating system or disk encryption requirements, verify that the device meets those requirements.
If you configured a certificate check in the Device Posture policy, install the required certificate on the device.
Install or update OpenVPN Connect.
Distribute the user's CloudConnexa connection profile according to your organization's profile distribution method.
Import the connection profile into OpenVPN Connect.
Connect to CloudConnexa.
Verify that the device passes the assigned Device Posture policy and connects successfully.
Tip
To verify that Device Posture is enforcing your requirements, repeat the connection test from a device that doesn't meet one of the configured checks and verify that it can't establish or maintain the connection.
If you centrally manage OpenVPN Connect on Windows, you can use a global configuration file to control supported OpenVPN Connect settings.
Step 10: Allowlist the network egress IP address in SaaS applications
Restrict supported SaaS applications to connections originating from the public IP address of the Network you configured earlier. Because traffic to the SaaS Application is routed through that Network, the SaaS provider sees the Network's public egress IP address as the source of the connection.
Verify the public IP address that the SaaS application sees
Connect a test device to CloudConnexa using a connection profile for a user who has access to the SaaS Application.
Access the SaaS application from the connected device.
In the SaaS application's audit, sign-in, or access logs, locate the connection from the test user.
Note the public source IP address recorded for the connection.
Verify that the address matches the public IP address used by your private Network to access the internet.
Configure the SaaS application.
Sign in to the SaaS application's administrative interface.
Locate its network, trusted IP, or source IP access controls.
Add the Network's public egress IP address to the application's allowlist.
Save the configuration.
Test access while connected to CloudConnexa.
Test access from a connection that doesn't use the allowlisted egress address and verify that the SaaS application rejects it.
This adds a second access control: CloudConnexa determines who can reach the SaaS Application, while the SaaS provider accepts connections only from the approved network egress IP address.
Note
The exact configuration steps depend on the SaaS provider.
Step 11: Verify the ZTNA configuration
Test the completed configuration before deploying it more broadly.
Ideally, test with users from different User Groups and with both compliant and noncompliant devices.
Connect with a test user and verify that authentication completes through Microsoft Entra ID.
Verify that the user is assigned to the expected CloudConnexa User Group.
Attempt to access each private Application or IP Service that the User Group should be permitted to use.
Attempt to access a resource that the User Group shouldn't be permitted to use and verify that access is denied.
Connect from a device that doesn't satisfy the assigned Device Posture policy and verify that CloudConnexa rejects or terminates the connection as expected.
For a User Group with a Location Context policy, test from an allowed and a disallowed location.
Access a SaaS application through CloudConnexa and verify that traffic uses the allowlisted network egress.
Test domains or traffic covered by the assigned Shield Policy and verify that the expected filtering applies.
Review DNS logs, Access Visibility, and Cyber Shield metrics to confirm access and security policies behave as expected.
What happens next
Your WPC now combines identity-based authentication, least-privilege access, device security, location restrictions, and Cyber Shield filtering in a Zero Trust Network Access (ZTNA) model.
As users, devices, and protected resources change, review your User Group mappings, Access Groups, Device Posture and Location Context policies, and Shield Policy assignments. Update SaaS application allowlists when your network egress configuration changes.
Use Access Visibility, DNS logs, and Cyber Shield metrics to monitor access and investigate unexpected activity.