QNAP NAS Community Forum

Posted: **Fri Nov 27, 2020 2:37 am**

Hallo all,

This is my first post and I’ like to start it by thanking all the contributors. Information on the forum has helped me numerous times!

My head is about to explode with the following question: Is it possible to establish a bind to the QNAP ADDC on port 389 or 636 via LDAP and TLS 1.2?

I am using a TVS-882-i5 with Firmware 4.5.1.1495 and and have a self-signed certificate installed. I have activated the Domain Controller, which overall has done a decent job for a few years in the small network I operate. At present, I try to authenticate domain users in docker applications in container station, some of which require TLS 1.2 as a minimum.

I am puzzled that the above ports on the native ADDC work as a maximum with TLS 1.1 on my system. They also respond with an autogenerated samba-certificate rather than the self-signed certificate for my domain. On all other ports I have tried (Admin Interface, Web Server, even the native LDAP-server with ADDC disabled) I can connect with TLS 1.2 and the server responds with the self-signed certificate. The same is true on an older TS-459 Pro II, which does not have the ADDC functionality. When I reset the Domain Controller, it also only responds with TLS 1.1.

Can anyone help me with shedding some light on this behaviour? Is TLS 1.1 the highest version for ADDC LDAP? If not, how can it be changed?

Your answers will be much appreciated, cheers Avx055

Posted: **Thu Sep 09, 2021 8:41 pm**

Did you find a solution to this? It's now heading towards end of 2021 and it's still TLS 1.1 maximum on LDAPS I'm finding on the QNAP. No wonder they have security issues when they aren't keeping their software and configurations up to date.

Can we manually fix this in the configuration somewhere for Samba?

Posted: **Sat Sep 11, 2021 3:02 am**

Answering my own question but using tls_priortity in /etc/smb.conf I can turn on TLS v1.2 but it doesn't actually work as it doesn't seem to support the required TLS 1.2 ciphers clients to connect. No amount of fiddling seems to solve this.

Checking gnutls-cli on the NAS I see in theory the OS does support the ciphers you'd need for TLS v1.2 and why no doubt other services can use it, I can only conclude Samba is being statically compiled against a very old gnutls library.

Nothing to be done here that I can see, it doesn't seem fixable. Here's to hoping QTS 5.0 resolves this but really QNAP need to up their game with security and maintaining the underlying OS / software.

**UPDATE**

OK solving my Docker Container issue where I've LDAP services that won't connect without TLS 1.2 or higher. Can manually force them all back to TLS 1.1 or try but that's a huge pain, especially as might break updates in places so instead using a HAProxy container to add TLS 1.2 infront the QNAP's Samba. Obviously it doesn't really secure the QNAP but it at least unblocks me using the LDAPS properly.

I'm using the QNAP's SSL certs in this example but obviously you could easily replace them. Here's the various files I'm using. These go in a directory on the NAS, you need Container Station installed and then just run docker-compose up -d

docker-compose.yml

Code: Select all

version: "3.5"

services:
  haproxy-ldaps:
    image: haproxy
    container_name: haproxy-ldaps
    restart: unless-stopped
    volumes:
      - ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro
      - /share/CACHEDEV1_DATA/.samba_target/private/tls/ca.pem:/usr/local/etc/haproxy/ca.pem:ro
      - /share/CACHEDEV1_DATA/.samba_target/private/tls/cert.pem:/usr/local/etc/haproxy/cert.pem:ro
      - /share/CACHEDEV1_DATA/.samba_target/private/tls/key.pem:/usr/local/etc/haproxy/cert.pem.key:ro
    environment:
      - TZ=Europe/London
    ports:
      - "637:637"

haproxy.cfg - Replace your NAS IP at the bottom where it says **NAS-IP**. 127.0.0.1 or localhost won't work as it's inside a container.

Code: Select all

# Allow TLS 1.2 LDAPS connections and forward onto QNAP's TLS 1.1 max Samba service

global
  log 127.0.0.1 local0 info
  ssl-default-bind-options ssl-min-ver TLSv1.2

defaults
  timeout client      60000   # maximum inactivity time on the client side
  timeout server      30000   # maximum inactivity time on the server side
  timeout connect     8000    # maximum time to wait for a connection attempt to a server to succeed

# Connect out to the LDAP server
listen ldaps
  log global
  bind :637 ca-file /usr/local/etc/haproxy/ca.pem ssl crt /usr/local/etc/haproxy/cert.pem verify none
  mode tcp

  server qnap **NAS-IP**:636 ssl verify none

I also had to add permission to the allow HAProxy to access the SSL key file. Run this on your NAS:

Code: Select all

setfacl -m u:httpdusr:r /share/CACHEDEV1_DATA/.samba_target/private/tls/key.pem

Now when setting up an LDAPS service, instead of using port 636 on the QNAP which is the TLS 1.1 only, hit port 637 instead and enjoy TLS 1.2 and 1.3 connections to LDAP

Posted: **Sat Sep 11, 2021 3:39 am**

Complain to QNAP via ticket .. they do not come here ..

Posted: **Sat Sep 11, 2021 4:29 am**

Hi FastLaneJB,

I opened a ticket and was advised that I need to await a Firmware with Samba 4.13, which would solve the issue. No date was given and I was disappointed that QTS 5 Beta did not take the firmware to that step.

I tried the tls priority settings as well and that does not work.

Cheers

Posted: **Sat Sep 11, 2021 4:32 am**

Ah I was hoping this would be solved with QTS 5.0 but that's really disappointing that it's not going to be there either.

I updated my post above with a workaround so you can connect to LDAPS using TLS 1.2 so no need to modify all upstream systems you want to connect in. A stop gap solution but will cover me for now.

I'll look at raising a ticket though as they need to sort this, they are years behind the times on this.

Posted: **Sat Sep 11, 2021 6:27 am**

Thanks for the workaround, interesting solution. Let’s keep the fingers crossed that we won’t need it for too long!
Cheers

Posted: **Sun Sep 12, 2021 9:28 pm**

I won't hold my breath on this but for my home usage it'll cover me for now.

Posted: **Thu Sep 16, 2021 5:00 am**

Just updated to QTS 5.0.0.1785 Build 20210908. Release notes stated that this release includes Samba 4.13 and a quick test suggests that this version will support TLS 1.3! I'll only have time for more extensive tests over the weekend but am very hopeful that our above issues are now resolved. It is only a public beta but I had no issue with that so far.
Cheers

Posted: **Sat Oct 16, 2021 7:28 am**

Did this work as I noticed this also on the release notes? I'm holding off on QTS 5.0 for the moment as simply I'm not sure I yet trust their updates to not break something so giving them a bit of time for fixes.

Posted: **Sun Oct 17, 2021 4:23 pm**

Hi, in part is the answer. The binding of the containers works well and I have no issues with it. However, I have issues with the upgrade as access to apps such as Qfile or Qumagie currently does not work with domain users. I also experience the DNS error, which is mentioned elsewhere in the forum. As yet I am not certain, whether parts of the DC got corrupted during the upgrade or whether it is an issue with QTS. I think I'll wait for the next release and keep testing before I open a ticket and your choice to wait a bit longer is probably the smart way to go.
Cheers

QNAP NAS Community Forum

Bind ADDC via LDAP TLS 1.2?

Bind ADDC via LDAP TLS 1.2?

Re: Bind ADDC via LDAP TLS 1.2?

Re: Bind ADDC via LDAP TLS 1.2?

Re: Bind ADDC via LDAP TLS 1.2?

Re: Bind ADDC via LDAP TLS 1.2?

Re: Bind ADDC via LDAP TLS 1.2?

Re: Bind ADDC via LDAP TLS 1.2?

Re: Bind ADDC via LDAP TLS 1.2?

Re: Bind ADDC via LDAP TLS 1.2?

Re: Bind ADDC via LDAP TLS 1.2?

Re: Bind ADDC via LDAP TLS 1.2?