[Samba] Implementation and test of LDAPS
HUET Timothe
timothe.huet at citeos.com
Mon Mar 11 12:38:18 UTC 2024
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
More information about the samba
mailing list