Browse Docs
ONLINE DOCUMENTATION

Using with Active Directory

Overview

When enabling Active Directory (AD) services over the DefensX ZTNA network, certain configuration parameters must be set carefully to ensure proper functionality.

This document provides step-by-step guidance on how to create a Secure Access Service that makes Active Directory resources accessible through the ZTNA network.

Ports Used by Active Directory

To enable Active Directory services over ZTNA, it’s essential to understand which ports and port ranges are required for specific AD functions. The table below lists the commonly used ports and their corresponding purposes within Active Directory operations:

Port Protocol Service Description

53

UDP

DNS

Domain Name System is used for locating the Domain Controller and resources.

88

TCP/UDP

Kerberos

Used for authentication between the client and the DC

135

TCP

RPC Endpoint Mapper

Used to locate the port of a specific RPC service. The client queries this port to find out which dynamic port a service (like Task Scheduler for remote GP update) is listening on

389

TCP/UDP

LDAP

Lightweight Directory Access Protocol, used for reading policy information from the DC

636

TCP

LDAPS

Secure LDAP (LDAP over SSL)

445

TCP

SMB

Accessing to the shared files, crucial for accessing the SYSVOL share, where the actual Group Policy templates and files are stored.

49152–65535

TCP/UDP

RPC

Dynamic Ports (High Ports) Used by various RPC services after the client contacts the RPC Endpoint Mapper (Port 135). Services like NetLogon, LSA, and SAM use these dynamic ports for communication.

Creating the Secure Access Service for Active Directory

To enable Group Policy updates, domain join, and domain leave operations over the DefensX ZTNA network, you must create a Secure Access Service as described below.

In the example configuration:

  • DNS Server IP: 10.20.1.1

  • AD Domain Name: defensx.us

Note: Replace these values with those corresponding to your own environment.

Configuration Steps

  • Navigate to the Configuration page under the Secure Access section in the DefensX Backend

  • Click New Secure Access Service.

  • In the Name field, enter a descriptive name such as Active Directory

  • In the Agent field, select the Connector that can reach your Active Directory services on the local network. If you don’t have a connector yet, go to Policies & Deployments, open the desired deployment, locate the agent, and mark it as a Connector.

  • In Application Restrictions, select No Restriction

  • In Status, select Active

  • In DNS Hostname or IP Address, enter the local IP of your Microsoft DNS Server (e.g., 10.20.1.1)

  • In Protocol, select TCP_UDP

  • In Target Service IP or Hostname, enter your Microsoft DNS Server IP again (e.g., 10.20.1.1)

  • In Port(s), enter 53, 88, 135, 389, 445, 636, 49152-65535

  • Under the ports field, click Add DNS Overrides

  • In DNS Suffix, enter your domain name prefixed with a dot (e.g., .defensx.us)

  • In Nameserver, enter the Microsoft DNS Server IP (e.g., 10.20.1.1)

  • Click Create Secure Access Service to save the configuration

After creating the service:

  • You must enable it under a Secure Access Policy.

  • If no policy exists, click New Secure Access Policy, give it a name, and then add this service to that policy.

Microsoft DNS Server Configuration

By default, Microsoft DNS Server is configured to listen on all available network interfaces. While this simplifies initial setup, it can lead to unintended behavior in environments where virtual or tunnel interfaces are present.

When the DefensX Agent is installed on a Windows Server, Windows may detect the DefensX tunnel interface (IP address 100.80.0.1) as a valid network interface. Due to the default “listen on all IP addresses” configuration, Microsoft DNS Server may begin advertising this virtual IP as a DNS endpoint.

As a result, when an Active Directory client performs a DNS query, it may receive a DNS response that references 100.80.0.1. Since this IP is a virtual tunnel address and not directly reachable by clients, DNS resolution can fail or behave inconsistently.

This behavior is a side effect of Microsoft DNS Server’s default configuration, not a DefensX-specific defect. Listening on all interfaces is generally not considered a best practice for production DNS servers, especially in systems with VPN adapters, tunnel interfaces or virtual network overlays.

Resolution

To prevent Microsoft DNS Server from advertising the DefensX tunnel interface, explicitly bind DNS to the appropriate physical or production IP addresses:

  • Open DNS Manager on the Windows Server.

  • Right-click the server name and select Properties.

  • Navigate to the Interfaces tab.

  • Change Listen on from All IP Addresses to Only the following IP addresses.

  • Select only the valid local IP addresses intended to serve DNS requests.

  • Ensure that 100.80.0.1 is excluded

  • Click OK and restart the DNS Server service.

  • (Optional) On client machines, run the ipconfig /flushdns command to clear cached DNS entries for quicker testing.

microsoft dns server listen interfaces

If clients continue to receive the 100.80.0.1 address when resolving a Domain Controller, even after applying the configuration changes above, verify the static DNS records in the relevant zone on the Microsoft DNS Server.

Review the zone for any records that reference the 100.80.0.1 IP address. If such records exist, delete them and restart the DNS Server service to ensure the changes take effect.

microsoft dns server static records
Secure Industries, Inc 101 Avenue of The Americas, Floor 9 New York, NY 10013