[Documentation../index.md / Tutorials

Accessing on-premise Active Directory servers using Enclave

Keywords: Domain Controller, Active Directory

This article provides guidance on how to set up access for remote devices to an on-premise Active Directory servers using Enclave to allow remote users to:

• Log in to their laptops using Active Directory credentials (or smartcards) from anywhere.
• Authenticate to other on-premise resources using their Active Directory credentials via Kerberos authentication.

It's not recommended to install Enclave directly on the Active Directory server, largely because Active Directory can get confused about the additional network adapter, leading to unexpected/undesirable behaviour.

The fundamental idea is to deploy at least one Enclave Gateway adjacent to the Active Directory server that provides connectivity; here's a reference architecture that allows access to an Active Directory server, with a High-Availability Gateway pair and an example on-premise file server authenticated with Kerberos tokens from the Active Directory host.

Note

In all Enclave reference architecture diagrams, the presence of the Enclave logo ( ) against a device indicates it is running the Enclave agent.

High Availability

While it is perfectly acceptable to deploy a single non-redundant Enclave Gateway when testing/proving access to the Active Directory server, we typically recommend deploying a high-availability pair for a critical use-case like Active Directory access, to prevent a loss of connectivity caused by a failure of the underlying hardware.

If you already have automatic fail-over support for the Gateway VM through the use of a hypervisor automatic fail-over feature (for example, VMWare High Availability), that will be sufficient, and only a single Gateway is needed.

Enclave Gateway High-Availability is configured simply, by adding more than one Gateway to the list when configuring the gateway access policy.

Gateway Requirements

Gateways are any Linux device that can run the Enclave Agent, be that a VM, a Raspberry Pi or a physical server.

Tip

If you cannot deploy a Linux VM or device, Enclave can run as a gateway inside WSL2 on a Windows Server, but note that WSL2 places a number of requirements on the environment in which the Windows instance is running that may make this option more complicated for you than just deploying a Linux VM.

For information regarding the resource requirements of a gateway device, consult the section on gateway requirements in our docs.

Important

If your Active Directory domain has a .local suffix, consult our documentation on configuring the gateway so DNS names ending in .local can be resolved.

Required Ports

Active Directory requires a set of ports to be accessible for clients to function correctly (taken from Microsoft docs).

Note

By default, RPC services on Windows Server 2008 and later use the dynamic port range 49152-65535 for RPC and NetLogon.

Exposing the entire high-port dynamic range via Enclave on your Active Directory server is not likely to cause any security issues.

That said, you may wish to restrict your Active Directory RPC calls to a fixed port, by choosing a port (e.g. 40001), then following the Microsoft documentation on How to restrict Active Directory RPC traffic to a specific port.

Here is the full set of ports you need in your Enclave Gateway Policy:

Service	Protocol(s)	Port
RPC Endpoint Mapper	TCP	135
RPC for LSA, SAM and NetLogon	TCP	49152-65535*
LDAP	TCP + UDP	389
LDAP SSL	TCP	636
LDAP GC	TCP	3268
LDAP GC SSL	TCP	3269
Kerberos	TCP + UDP	88
Kerberos Password Change	TCP + UDP	464
SMB	TCP	445

(*) If you opted to lock down your RPC port to a fixed port, specify that here instead of the range.

Note

You do not need to add port 53 for DNS. We take care of gateway DNS for you.

Step-by-step

This step-by-step guide assumes you're deploying the architecture described at the top of the this article, with a high-availability pair of gateways. We'll assume that we have:

• An office network subnet defined as 10.0.0.0/24.
• An Active Directory server available at 10.0.0.1.

We also presume you are using VMs as gateways, but the same steps apply if you are using physical devices.

1. Provision two Linux VMs inside the same network as your Active Directory server to act as your Gateways.

   The VMs do not necessarily have to be in the same subnet/VLAN, provided that the VMs can route packets to the subnet containing the Active Directory server.

   If you have intermediate firewalls between the gateways and the Active Directory server, ensure all of the listed ports described above are reachable.

2. Install Enclave on both gateways as per the normal Linux installation process, and enrol them into your Enclave organisation.

3. Within our portal, navigate to the detail view of the first linux gateway VM, and configure it as a gateway:

   

   If the subnet containing your Active Directory server is not directly available to the gateway, you may need to add a subnet and specify the target subnet explicitly.

4. Repeat the configuration for the second gateway; ensure that all the subnets available to the first gateway are also available to the second.

5. Define a Gateway Access Policy from a users tag to both of the gateways you've deployed.

   

   Tip

   This is how high-availability / load-balancing is set up for gateways; put more than one gateway on the receiver side with the same subnets. The rest is automatic.

6. Configure a subnet filter on the policy to only allow access to your Active Directory server (10.0.0.1) within your 10.0.0.0/24 subnet:

   

7. Finally, configure the required set of allowed ports on your policy (these are listed in the table above for easy copying):

   

For Users

Once the policy described above has been configured, all user devices enrolled and tagged with the users tag will automatically be able to connect to the Active Directory server, logon, retrieve group policy, and so on, regardless of their location.

If you define an enrolment key with:

• Automatic Approval
• An Auto-Tag that includes the users tag.

then enrolling the system will give it access to Active Directory without any further admin action needed.

Combine that with deployment using our unattended installer via your RMM, and you can roll out remote Active Directory connectivity very quickly to the entire user estate.

Access to other resources that require Active Directory credentials

To access other resources within the network that require Active Directory credentials, define another gateway policy that provides access to the resources you require.

For example, you can provide access to a file share (as in the diagram at the start of this article) by providing a separate gateway access policy that allows users to reach whichever resources they need, but only on port 445.

The Active Directory connection already in place means users will get Kerberos authentication tokens for other network resources as if they were in the network as normal.

Tip

You can add a User Authentication Trust Requirement to other policies that requires user login before connectivity will establish.

Provided the 'Active Directory' gateway policy is enabled, the user login to the Enclave client will be able to use the user's authenticated Active Directory credentials before network access to the resource takes place.