How to configure Active Directory server with bridged external IP?

NethServer Version: 7.7.1908
Module: users-groups

I use cloud server and provider give me internal IP address for network interface (eg 10.130.0.4), that is bridged to external white static IP address (eg 84.201.1.1) via cloud network service. So all traffic to external IP are bridged to local IP on server.

I want to configure Active Directory server on it (all clients will connect via internet, not via local network), so I select Active Directory » Create domain and become DC, on next step I must fill IP address. For external connections works well, I must fill external IP address (84.201.1.1), but NethServer don’t allow me to do this via warning:

* The IP address must be in the same subnet range of a green network: e.g. 168.32.2.0/24

So, the question is how to configure AD server on bridged external IP address via NethServer?

I could think of several tricks to connect the different subnets.
Can you clarify a bit more how you configured your NethServer and AD container?

Do I understand correctly that your NethServer is installed on a VPS (cloud server) with an external IP adres that is bridged with a internal private IP address. This is your RED interface. Now you need a GREEN interface to make it possible to create a linux container to host Samba4 AD.
You could create a dummy interface that you can give an IP address in a subnet of your choice. This could be the same subnet as your local subnet at home.
There is a howto for that dummy interface. I did this too for my NethServer instance as VPS where I wanted to run Samba4 AD accountprovider.

When you have created the dummy, you can create a site-to-site VPN from your home router to your cloud NethServer instance.
@support_team you think this is possible and are there any special configs in this scenario to take care of?

Thanks for quick reply!

Yes, all right, but I want to use my current (one) interface as GREEN for make all connections to it directly, without VPN or other proxy points. Is this possible?

Before NethServer, I use Zentyal server, that works well with one network interface, and AD connected directly to it. So all clients connects to external IP directly and AD works well. Now I want to configure same setup, using NethServer instance.

So, comparing to Zentyal, where Samba4 are launched as native system app and reuse same IP as system, NethServer always launch AD server only inside container (docker?) with separate IP address?

Also can you please describe, how can I configure my server network interface, that now have internal IP (10.130.0.4) to match my static external ip ( 84.201.1.1), and make port forwarding from it to Samba4 (that will be launched inside container with ip 10.130.0.5)?

And second task will be configure DNS server to return external IP address ( 84.201.1.1) for my AD domain and all SRV-TXT records needed for AD, instead of internal (10.130.0.x).

Yes this is right.

You can use it as green, but you have no firewall rules on green network. The way @robb described is much safer and I would advise you to use it with vpn. Don’t open your server for everyone.

I understand, that opening server for everyone is not so good, but force all users to make VPN connection before they make autorization in my AD server is too hard rule for most of users. Also other external services, that must use Kerberos auth or other LDAP queries, must connect via VPN too? This is not possible, because most of external services don’t have VPN configuration!

So, at least, I must open Samba LDAP (389, 636) and Kerberos (88) ports to all world, yes? And if those ports will be open, users will can connect to my AD without VPN, yes?

Is this right configuration, or not secure?

If not secure, can you please describe how to configure LDAP and Kerberos, that will be available from any IP, in right way?

No no no…
Create a site-to-site vpn so your server is continuously connected with your LAN. So your clients don’t need to set up a separate VPN.
Then on your VPS/cloud NethServer instance you still need a RED interface for your external IP and a virtual interface for the GREEN subnet that is also used on your LAN.

My clients don’t have LAN, they work from different offices and homes, and I want to make connection to AD simple. So all connections must work via one (RED?) interface.

IMO it is highly unsafe to have your AD directly connected to Internet.
Can you elaborate a bit what services you need to use for your clients? It might be possible to connect with the services without having a full blown AD log-in.
If I look at my own server, which is installed on a VPS also, I don’t log in AD with my laptop but still can use my email with Thunderbird as client or SOGo webinterface as client.
Also all other services (I have almost a dozen different services running on the server) I can use without loggin in with my laptop to AD. Of course I do have to authenticate with my AD account to the servies. This might be a vialbe option for your clients too?

I need to have list of all active company users on each computer (for right file owners, SSO, and other tasks, for centralized creating-blocking accounts, etc). This can be done via SSSD and simple LDAP on linux (with opening only one 363 port), but on Windows I need full AD.

I think you can build a script which installs openvpn, copied the config file and the keys to the right directory, and starts openvpn as service (It should be set to automatically as start type). Send these files to your users.
After executing the script and restarting windows they should have an active vpn connection. This should be the safest way for your connection. With vpn they are at the same LAN with your server and you can create a virtual green network-interface like @robb described.

1 Like

I would like to remind that if the “application” server lose connection to “external AD” server, anyway this connection is accomplished about protocol, routing or tunneling, only cached logins will continue to operate.
Every login attempted after detach won’t succeed due to lack of connection to authentication server.
Mind this behavior before build the infrastructure. Or create a test environment to simulate any kind of issue.

1 Like

I understand this, so I use SSSD on Linux with Zentyal, that cache AD user lists and logins for long time, and users don’t have any problems when working offline long time.

But I don’t understand why keeping AD server opened to whole internet is so large security problem, as all you describe? All connections are encrypted, passwords are not sent as plaintext, so what is the main security problem?

I know, that hiding all services behind VPN and Firewall are more secure by design, that direct access to service. But if all service owners will think like this, connecting to any web service must be done via VPN :slight_smile:

Bugs.
And routing.
And DDOS.
And bad luck.
And brute force
Whatever.
And i forgot: CRAPPY PASSWORDS FROM USERS
And i forgot Act 2: people who are keeping to enable SMB v1 as the “right way” to troubleshoot SMB connection between their clients and the server.
IMVHO SMBv1 is like lead: it works, does something useful but it’s poison and you don’t really want to get in touch with. Expecially on WAN/RED.

Long story short: the wider is the possible access, the bigger are the possible problems that you can bring on your setup. Microsoft choose (wisely) transform the authentication infrastructure from private to public, for allow the concentration of datacenters into bigger structures and not on premises (so less money spent on branch offices for large companies)
NethServer is… Small/medium business, so it can be hosted on VPS/Hosting services BUT this arrangement is good only for some user cases and not for everyone.
Again: do a lab config. And try to break it or became a “penetration poor-tester”. If you succeed once or more without any kind of hardening possible… that’s not a viable path.

2 Likes

Of course you are free to choose to expose your Samba4 AD accountprovider directly to the internet. I just can’t advice strong enough against this.
Here some valid points you might want to read before you throw some real pains all over your solution: