Needed a small easy setup domain controller and found Turnkey-Linux.

Worked very good, running it as a VM on my QNAP nas. Migrated some workstations to the domain and was satisfied with the outcome and how easy it all came togheter with a pre-configured vm!

I did a snapshot of the VM after this and forgot about it.

A week later I was doing some testing in my network and needed a machine with nmap installed. So i logged on to the turnkey domain controller and without hesitating ran 'apt install nmap'. 

Later that day I noticed that none of my workstations identified the network connection as domain any more. And I started my quest down the rabbithole with regards to repairing windows 10 installs that behaves like this. 

Ended up with reverting to the snapshot after a day of frustration. Voila... it works, the win 10 workstations work again.  

Rubbed my mind about what I've actually done with the domain controller and ended up with the fact that I installed nmap. So I did that again, the domain controller is unreachable with RSAT tools.

Reverted to the snapshot and it works again.

I have not the skills or the time to investigate if this is actually the case. It might be that I just suck and that it's something completly different that's happening here. But anywhay I just wanted to report this. 

I will live my life happily without nmap installed on the domain controller.


turnkey-domain-controller-16.0-buster-amd64
turnkey-install-security-updates => up to date.

 

 

 

 

Forum: 
Jeremy Davis's picture

I'm almost certain that the install of nmap and the domain controller stopping working the same day is coincidental. I'm not sure what might be the issue with your server, but FWIW the most common cause of clients getting booted from an AD domain running on a VM is time drift. The Kerberos authentication mechanism depends on the clocks of both the server and the guests being (more-or-less) the same.

Unfortunately, I no longer have a current Windows 10 machine handy that I can use to test this (an update a few years ago caused a BSOD on my Win 10 Pro install and I never did work out why). Regardless, I had a quick look at the nmap package and I can't see any way that any components of that would interfere. I've also searched extensively online for anybody else having an experience like that (i.e. Samba AD DC breaking due to installation of nmap) and can't find anything (which doesn't make it impossible, but as nmap is a commonly used tool for testing samba, it seems unlikely).

I suggest that you try 2 things:

First, take a snapshot of the system currently. Then install nmap and check the domain members connectivity immediately. If they break immediately, then you may be onto a really weird bug that no one else has hit.

If that doesn't immediately cause any issue, then wait until it breaks again and check both the logs of the WIndows machine that can't connect/isn't connected, as well as teh Domain Controller. By default, the Samba logs are quite verbose but hopefully should contain info about the failure (IIRC logs should be in /var/log/samba or similar).

I would say that are correct, and I'm truly sorry to have wasted your time!

I 'm now certain that this was a DNS configuration issue. And I suspect that the 'apt install ...' initiated DNS queries that in turn resulted in issues with the DC DNS because of the error in configuration that I made initially.

I think that I've sorted this now by setting the DNS server specified for ethernet interface to itself. The forwarder dns is set in the samba configuration when using internal samba/winbindd DNS service.

/etc/networking/interfaces

iface eth0 inet static
        address 192.168.1.11
        netmask 255.255.255.0
        network 192.168.1.0
        gateway 192.168.1.1
        dns-nameservers 192.168.1.11
        dns-domain [mydomain].com

I do not know how much of the inital configuration script that's a Turnkey specific solution, but if possible this should be set like this automatically. If the machine is used as a Domain Controller, the internet has told me this is how it must be in order to function properly. So for other n00bs like me trying to setup a domain controller for the first time, this would have been a nice feature. (or it might even have been printed right before my eyes during config but I missunderstood something...)

The external DNS is set in the samba/winbindd config.

I hope I have time to try your suggested test in the end of the week, but I needed the domain controller up and running and stable to be able to continue with my work (that pays the bills). The last time the trust relationship between the (most important) workstation and the DC got messed up, and I do not have time for any more hick-ups.

 

 

 

 

Jeremy Davis's picture

Yes, all AD DCs and all the clients, need to get their DNS from the/a DC. There are special AD DNS records required. IIRC it should be correctly set up by default, but there is also more some additional detail on the TurnKey AD DC doc page. The Samba wiki (as linked to on that page) is also an invaluable resource.

Good luck with it all. And no need to follow my test suggestions if you're up and running again. Good luck with it all.

Add new comment