WIN10x64 21H1 can't join Turnkey Domain Controller v16.1 (LXC; VM and bare metal ok).

[AdalbertKing]

Both Turnkeys are in default configuration with changing domain name to NET.LAN (ver.15) and NET1.LAN (ver. 16) with
other DNS (192.168.9.100 - ver. 15, 192.168.9.57 -ver.16) Joining to the ver. 15 is success

(Asking about creditentials of Administrator)

Trying join to the ver. 16 returned the message: "Can't contact with domain controller oo Active Directory (AC DC) for "net1.lan " Looks like WIN10 can't find DC in ver.16 -because of Kerberos ? any protocol ? The same machine join to the turnkey domain controller in ver. 15.00 without any issue.

Any ideas?

[JedMeister]

I haven't tested it since we released the most recent version (v16.1) back in May (~3 months ago). All I had to do was complete the set up and then add the TurnKey AD DC IP address as the primary DNS in Windows and it "just worked".

The only thing that occurs to me is that perhaps Windows have changed something (e.g. within an update) that has broken it?

Although that doesn't explain why it still works with the old v15.x release?! So perhaps it's a TurnKey (Debian) security update that has broken something? If you haven't already, perhaps try it with no security updates installed on firstboot? (They will automatically be installed within 24 hours, but at least it will allow you to test).

I'm not a Windows user and don't have a Windows machine handy to double check.

However, there is a thread on our forums that has been active relatively recently. Within that Juan stated that he has had it working with Windows XP, Vista, 7, 8 , 8.1, 10 and even with the trial version of Windows 11!

[AdalbertKing]

Ok. I have tested more.

Problems with joining to the TDC ver. 16.1-1 is in LXC containers instalation of TDC.

Everything works fine if you have TDC running on metal, or full VM.

If your TDC is running under the container - joining don't work.

Conclusion is, that something wrong is in the container LxC.

I'will open task on those forum for Windows user. For your information.

Anyway I tested under VM like that:

1. I made two domains TDC domain controller:

2. Joined WIN10 machine, and RSAT running under the WIN10 shown that all that points were fine:

W dniu 09.08.2021 o 04:34, Jeremy Davis pisze:

I haven't tested it since we released the most recent version (v16.1) back in May (~3 months ago). All I had to do was complete the set up and then add the TurnKey AD DC IP address as the primary DNS in Windows and it "just worked".

The only thing that occurs to me is that perhaps Windows have changed something (e.g. within an update) that has broken it?

Although that doesn't explain why it still works with the old v15.x release?!

I'm not a Windows user and don't have a Windows machine handy to double check. But there is a thread on our forums https://www.turnkeylinux.org/forum/support/mon-20210517-0129/domain-controller that has been active relatively recently. Within that Juan that has had it working with Windows XP, Vista, 7, 8 , 8.1, 10 and even with the trial version of Windows 11 https://www.turnkeylinux.org/forum/support/mon-20210517-0129/domain-controller#comment-49982!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/turnkeylinux/tracker/issues/1637#issuecomment-894915607, or unsubscribe https://github.com/notifications/unsubscribe-auth/AR5EZCDD7LNR655LSNTPCP3T345DTANCNFSM5BWNN3GQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.

[JedMeister]

I have updated this issue to reflect the fact that it appears to be a confirmed bug. Let's keep discussing in the forums.

(Or we can move the discussion here instead if you rather?)

[raspitoaster]

I just hit the same problem when I tried to join a second DC and a Win10 client to a fresh TKL domain controller 16.2 LXC. After several tries to get DNS name resolution working, I found that the blocked port 53 caused SAMBA to start only partially. netstat -tulpn | grep LISTEN pointed to systemd-resolved, so I set DNSStubListener=no in /etc/systemd/resolved.conf and then SAMBA started its internal DNS server. I verified the setup with W10-20H2 and W10-21H1 computers and a TKL domain controller 16.2 LXC and all three were able to join.

[JedMeister]

Hi @raspitoaster - thanks for your post.

When you say:

I found that the blocked port 53 caused SAMBA to start only partially.

By default no ports should be blocked (the firewall is configured, but not enabled by default). Although actually, it seems not that the port is blocked (in the sense of not listening on that port), but in the sense that systemd-resolved is already using the port. So I guess that's what you meant?

Also you note that you:

set DNSStubListener=no in /etc/systemd/resolved.conf

So it seems that we should configure that by default for the domain controller appliance then?!

[JedMeister]

I have had a little more look at this and it seems that again, this is another issue with running within a container! Specifically it seems realted to the way that Proxmox sets the DNS config (from the host at launch time).

When running on bare metal or in a "proper" VM, the /etc/resolv.confis a symlink to /etc/resolvconf/run/resolv.conf (which is generated) and is automatically configured to use the local (Samba) DNS server as the default DNS server (then the built in Samba server is configured to forward to Google public DNS). When running as a container though, the resolve.conf file is written by the host, as a raw file (thus wiping out the symlink to the generated DNS config).

You can easily "fix it" by replacing the static file with (the original) symlink, i.e.:

ln -sf /etc/resolvconf/run/resolv.conf /etc/resolv.conf

But unfortunately, that doesn't survive a reboot...

So the "proper fix" is to set the desired DNS config within the Proxmox UI (either at launch time, or via the container's DNS setttings). The 'DNS domain' needs to be set to the AD domain you plan to use and 'DNS server' needs to be set to '127.0.0.1'.

Also, by default systemd-resolved shouldn't be running?! Did you explicitly enable that?

[raspitoaster]

By default no ports should be blocked (the firewall is configured, but not enabled by default). Although actually, it seems not that the port is blocked (in the sense of not listening on that port), but in the sense that systemd-resolved is already using the port. So I guess that's what you meant?

Yes - systemd-resolved is blocking this port because of its built-in responder. This one can be disabled with the setting.

    `set DNSStubListener=no in /etc/systemd/resolved.conf`

So it seems that we should configure that by default for the domain controller appliance then?!

Yes. So the "proper fix" is to set the desired DNS config within the Proxmox UI (either at launch time, or via the container's DNS setttings). The 'DNS domain' needs to be set to the AD domain you plan to use and 'DNS server' needs to be set to '127.0.0.1'. Yes Also, by default systemd-resolved shouldn't be running?! Did you explicitly enable that? No, I did not explicitly enable it - it is enabled by default (just checked with a new container 16.2 TKL domain controller)

[JedMeister]

Also, by default systemd-resolved shouldn't be running?! Did you explicitly enable that?

No, I did not explicitly enable it - it is enabled by default (just checked with a new container 16.2 TKL domain controller)

Hmm, that's weird. When I launch one it's disabled?! Although I'm still using PVE 6.x so perhaps that's a factor? Also, I'm only running unprivileged containers, so perhaps that's a factor too?

The more I think about it, the more I suspect that your experience is a result of running as a privileged container.

FYI the systemd-resolved.service should not be running. The resolvconf.service is the one that should be providing DNS config?! It shouldn't be possible to start systemd-resolved.service without

On a CT:

root@v16-test-ct ~# systemctl status systemd-resolved.service 
* systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/systemd-resolved.service.d
           `-resolvconf.conf
   Active: inactive (dead)
     Docs: man:systemd-resolved.service(8)
           https://www.freedesktop.org/wiki/Software/systemd/resolved
           https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
           https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

root@v16-test-ct ~#  systemctl status resolvconf.service 
* resolvconf.service - Nameserver information manager
   Loaded: loaded (/lib/systemd/system/resolvconf.service; enabled; vendor preset: enabled)
   Active: active (exited) since Tue 2022-02-15 03:18:29 UTC; 36min ago
     Docs: man:resolvconf(8)
 Main PID: 62 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   Memory: 0B
   CGroup: /system.slice/resolvconf.service

Feb 15 03:18:29 v16-test-ct resolvconf[62]: /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /etc/resolvconf/run/resolv.conf
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

On a VM:

root@v16-test-vm ~# systemctl status systemd-resolved.service 
* systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

root@v16-test-vm ~# systemctl status resolvconf.service 
* resolvconf.service - Nameserver information manager
     Loaded: loaded (/lib/systemd/system/resolvconf.service; enabled; vendor preset: enabled)
     Active: active (exited) since Mon 2021-12-20 06:08:22 UTC; 1 months 26 days ago
       Docs: man:resolvconf(8)
   Main PID: 221 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 2337)
     Memory: 0B
        CPU: 0
     CGroup: /system.slice/resolvconf.service

Warning: journal has been rotated since unit was started, output may be incomplete.

[raspitoaster]

I just deployed an unprivileged container and the service is also enabled/started, so unless we see a clear pattern we should set DNSStubListener=no in /etc/systemd/resolved.conf as it does no harm if resolved is disabled but solves the problem if the service is enabled.

root@dnstest ~# systemctl status systemd-resolved
* systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/systemd-resolved.service.d
           `-resolvconf.conf
   Active: active (running) since Tue 2022-02-15 21:05:20 UTC; 38s ago