Hello, I want to implement a Samba4 server and enable an LDAPS. Context : I am trying to strengthen the security of a network with hundreds of devices (computer, switches, routers, FW ...). To do that I thought of : * Samba4 as an AD DC with LDAPS enabled * PacketFence will serve as a RADIUS * Apache Guacamole will serve as a bastion solution * LDAP Account Manager (LAM) as a web interface to manage LDAP entries I've never had to deal with any of those software, but I have understanding of the concept behind them. So I will thoroughly explain how I have implemented Samba so far. OS, package and other version will be listed at the end of this mail. So first, I used a Debian 12.5 installation and followed the instruction of "Distribution-specific Package Installation". Then the wiki page to set it up as an Active Directory Domain Controller. I changed the value of samdom.example.com and IP address but do not want to share them. I have provisioned it in Interactive mode, using with the following parameters, also note that I did not used the --use-rfc2307 option, would * Realm [SAMDOM.EXAMPLE.COM]: SAMDOM.EXAMPLE.COM * Domain [SAMDOM]: SAMDOM * Server Role (dc, member, standalone) [dc]: dc * DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: SAMBA_INTERNAL * DNS forwarder IP address (write 'none' to disable forwarding) [10.99.0.1]: 8.8.8.8 I then followed by creating a reverse zone and a PTR reverse DNS record. I tested it all with the command to Verifying DNS, Testing DNS resolution (in Linux and Unix DNS Configuration) and also verified Kerberos, everything worked as intended. For the NTP, I used and configured chrony by adding the following to the .conf file : # bind the chrony service to IP address of the Samba AD bindcmdaddress 10.99.0.1 # allow clients on the network to connect to the Chrony NTP server allow 10.99.0.0/24 # specify the ntpsigndsocket directory for the Samba AD ntpsigndsocket /var/lib/samba/ntp_signd Then, I proceeded by "Configuring LDAP over SSL (LDAPS) on a Samba AD DC", still using the Samba wiki. Since I installed it using the package software, the certificate are located under /var/lib/samba/private/tls/ Here, I have chosen to use the default parameters, which is "Using the Samba autogenerated self-signed certificate". I added the specified line in smb.conf. To test it out, I choose to use a curl command, but before that, I added the ca certificates with the following command : cp /var/lib/samba/private/tls/ca.pem /usr/local/share/ca-certificates/samba4.crt update-ca-certificates Then tried this curl ldaps://samdom.example.com Here I do get the information regarding the LDAP. So I think that it means LDAPS is enabled and functioning. I wanted to port this test further, and for that I added a Windows 10 client to the domain created. I then proceeded to connect on it with RDP using the Administrator account of the ldap. Let's assume the windows client address is 10.99.0.2. I therefore RDP on 10.99.0.2 with Administrator at example.com and his password. I managed to connect to it with the account, proving that LDAP was functioning. But I have no idea if he connected using LDAP or LDAPS. To test that, I thought of using openssl and try to connect on the LDAPS server and port. For that I think I need to import the ca.pem and add it to the different certificate store, so that the windows client trust the Samba server. On the windows client, I then get the ca.pem and cert.pem. I did the same as on the server, meaning I just renamed the extension from .pem to .crt. The reason why I did that is because when I tried openssl x509 -outform der -in certificate.pem -out certificate.crt the certificate wouldn't be taken into account with the update-ca-certificates command. This is a different matter and is just here to provide context. Still on the windows client, with my newly ca.crt and cert.crt I tried all the combination of : * Adding ca.crt to the Trusted Root Certification Authorities, the Intermediate Certification Authorities, the Personal certificate store * Adding cert.crt to the Trusted Root Certification Authorities, the Intermediate Certification Authorities, the Personal certificate store * Manually combine ca.crt and cert.crt to combined.crt and adding them to the Trusted Root Certification Authorities, the Intermediate Certification Authorities, the Personal certificate store When adding the certificate, I used the Win+r "mmc" command to add them to the "computer account" and not to the "user account". In my understanding, to be sure that everyone connected to the computer get access to the certificate. I then used openssl to test the connection : openssl s_client -connect samdom.example.com:636 but it doesn't seems to be working. Here is the output of the command : Output : Connecting to 10.99.0.1 CONNECTED(000001BC) depth=0 O=Samba Administration, OU=Samba - temporary autogenerated HOST certificate, CN=SAMDOM.example.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 O=Samba Administration, OU=Samba - temporary autogenerated HOST certificate, CN= SAMDOM.example.com verify error:num=21:unable to verify the first certificate verify return:1 depth=0 O=Samba Administration, OU=Samba - temporary autogenerated HOST certificate, CN= SAMDOM.example.com verify return:1 --- Certificate chain 0 s:O=Samba Administration, OU=Samba - temporary autogenerated HOST certificate, CN= SAMDOM.example.com i:O=Samba Administration, OU=Samba - temporary autogenerated CA certificate, CN= SAMDOM.example.com a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Mar 6 13:28:52 2024 GMT; NotAfter: Feb 4 13:28:52 2026 GMT --- Server certificate -----BEGIN CERTIFICATE----- (I removed the print here) -----END CERTIFICATE----- subject=O=Samba Administration, OU=Samba - temporary autogenerated HOST certificate, CN= SAMDOM.example.com issuer=O=Samba Administration, OU=Samba - temporary autogenerated CA certificate, CN= SAMDOM.example.com --- Acceptable client certificate CA names O=Samba Administration, OU=Samba - temporary autogenerated CA certificate, CN= SAMDOM.example.com Requested Signature Algorithms: RSA+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:Ed448:RSA+SHA512:RSA-PSS+SHA512:RSA-PSS+SHA512:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1 Shared Requested Signature Algorithms: RSA+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:Ed448:RSA+SHA512:RSA-PSS+SHA512:RSA-PSS+SHA512:ECDSA+SHA512 Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 2453 bytes and written 431 bytes Verification error: unable to verify the first certificate --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 4096 bit This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 21 (unable to verify the first certificate) However, when I specify the CA file, it works as intended : openssl s_client -CAfile C:\tls\samba4_ca.crt -connect sampb.uca.lan:636 Output : Connecting to 10.99.0.1 CONNECTED(000001D0) depth=1 O=Samba Administration, OU=Samba - temporary autogenerated CA certificate, CN= SAMDOM.example.com verify return:1 depth=0 O=Samba Administration, OU=Samba - temporary autogenerated HOST certificate, CN= SAMDOM.example.com verify return:1 --- Certificate chain 0 s:O=Samba Administration, OU=Samba - temporary autogenerated HOST certificate, CN= SAMDOM.example.com i:O=Samba Administration, OU=Samba - temporary autogenerated CA certificate, CN= SAMDOM.example.com a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Mar 6 13:28:52 2024 GMT; NotAfter: Feb 4 13:28:52 2026 GMT --- Server certificate -----BEGIN CERTIFICATE----- (I removed the print here) -----END CERTIFICATE----- subject=O=Samba Administration, OU=Samba - temporary autogenerated HOST certificate, CN= SAMDOM.example.com issuer=O=Samba Administration, OU=Samba - temporary autogenerated CA certificate, CN= SAMDOM.example.com --- Acceptable client certificate CA names O=Samba Administration, OU=Samba - temporary autogenerated CA certificate, CN= SAMDOM.example.com Requested Signature Algorithms: RSA+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:Ed448:RSA+SHA512:RSA-PSS+SHA512:RSA-PSS+SHA512:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1 Shared Requested Signature Algorithms: RSA+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:Ed448:RSA+SHA512:RSA-PSS+SHA512:RSA-PSS+SHA512:ECDSA+SHA512 Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 2453 bytes and written 431 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 4096 bit This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) So, as far as I am understanding things, I think that the certification chain is broken and need something between the ca.crt and the cert.crt, but I don't know what or why. I am sorry if I have gone on a tangent but I want to try to be as descriptive as possible. Feel free to tell me if I have put too much/too less/irrelevant information. So my questions are : * Is there a way to test that LDAPS is used to connect on the different client (Windows primarily but some Linux machine too) ? I feel like I may have used a way too much complicated way. * Is the method of taking the ca.pem and putting it as a ca.crt on all clients the right way of doing ? * Am I right to assume there is a problem with my certification chain implementation, and if so, what did I do wrong/should have done ? Version recap: OS : Debian 12.5 (VM Inside VMWare Workstation 17 pro, for testing purpose) Kernel: Linux 6.1.0-18-amd64 Package : samba-ad-dc/stable,stable-security 2:4.17.12+dfsg-0+deb12u1 Windows client : Windows 10 Pro 22H2 Thank you for having read this email, hoping for potential guidance and wishing you a good day. Yours sincerely, Timoth? HUET