I have a Samba file server attempting to join an Active Directory domain using "$net ads join". The Domain Controller is running Windows Server 2019. I'd like to force samba to use port 636 (LDAPS) when making the LDAP connection. I've tried several settings in the smb.conf file, but when I check the LDAP packets, samba is still using port 389. The join domain call is successful, it's just using the wrong port. I've tried: - "ldap ssl ads = yes" - "client ldap sasl wrapping = seal" - "ldap ssl = no" - Setting the URI in the ldap.conf file with "URI ldaps://test.domain.com" - Passing the domain controller ip address with ":636" to try an force port 636 I've looked through the LDAPS documentation on samba.org<http://samba.org/> but it's usually referencing using the Samba server as a Domain Controller, not as a Domain Member. Most of the related questions that I've found refer to using Samba as the AD DC and they usually involve messing around with the tls* attributes and/or having more changes in the ldap.conf. I'm not sure how much of that is required when Samba is a Domain Member. I'm just trying to understand what parameters are important when attempting to have samba join a domain using LDAPS. It's also very likely that the issue is related to my Domain Controllers, I've only verified that they are accepting connections on port 636 using the LDP.exe tool. see https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc771022(v=ws.11) ~Cordell
On 29/10/2020 22:15, Zebrose, Cordell via samba wrote:> I have a Samba file server attempting to join an Active Directory domain using "$net ads join". The Domain Controller is running Windows Server 2019. I'd like to force samba to use port 636 (LDAPS) when making the LDAP connection. I've tried several settings in the smb.conf file, but when I check the LDAP packets, samba is still using port 389. The join domain call is successful, it's just using the wrong port. I've tried: > > - "ldap ssl ads = yes" > > - "client ldap sasl wrapping = seal" > > - "ldap ssl = no" > > - Setting the URI in the ldap.conf file with "URI ldaps://test.domain.com" > > - Passing the domain controller ip address with ":636" to try an force port 636 > > I've looked through the LDAPS documentation on samba.org<http://samba.org/> but it's usually referencing using the Samba server as a Domain Controller, not as a Domain Member. Most of the related questions that I've found refer to using Samba as the AD DC and they usually involve messing around with the tls* attributes and/or having more changes in the ldap.conf. I'm not sure how much of that is required when Samba is a Domain Member. > > I'm just trying to understand what parameters are important when attempting to have samba join a domain using LDAPS. It's also very likely that the issue is related to my Domain Controllers, I've only verified that they are accepting connections on port 636 using the LDP.exe tool. see https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc771022(v=ws.11) > > ~CordellJust use kerberos, believe it or not, it is more secure. Rowland
On Thu, 2020-10-29 at 22:15 +0000, Zebrose, Cordell via samba wrote:> I have a Samba file server attempting to join an Active Directory > domain using "$net ads join". The Domain Controller is running > Windows Server 2019. I'd like to force samba to use port 636 (LDAPS) > when making the LDAP connection. I've tried several settings in the > smb.conf file, but when I check the LDAP packets, samba is still > using port 389. The join domain call is successful, it's just using > the wrong port. I've tried:Samba 4.13 recently removed this support. The issue is that while it was possible to use LDAPS in some situations, it was not possible to reliably determine the hostname to verify the TLS certificate, rendering the protection moot. Furthermore, extensive work would have been required to fully implement the 'channel bindings' required to tie the Kerberos authentication Samba uses to the TLS channel. Samba secures the LDAP connection it makes with Kerberos and ensures (unless you unwisely configure otherwise) that the session is fully encrypted. Because of this our use of Kerberos encrypted LDAP is actually more secure than LDAPS. Andrew Bartlett -- Andrew Bartlett https://samba.org/~abartlet/ Authentication Developer, Samba Team https://samba.org Samba Developer, Catalyst IT https://catalyst.net.nz/services/samba
> Samba 4.13 recently removed this support. > The issue is that while it was possible to use LDAPS in some situations, it was not possible to reliably determine the hostname to verify the TLS certificate, rendering the protection moot. > Furthermore, extensive work would have been required to fully implement the 'channel bindings' required to tie the Kerberos authentication Samba uses to the TLS channel. > Samba secures the LDAP connection it makes with Kerberos and ensures (unless you unwisely configure otherwise) that the session is fully encrypted. Because of this our use of Kerberos encrypted LDAP is actually more secure than LDAPS.Thanks for the quick response and it's reassuring to hear that Kerberos is more secure than LDAPS. One question, when I was looking at the packets during a join domain, I noticed that the username and domain name appear to be sent in plain text during the Kerberos authentication. Is there any way to encrypt either of those as well? Or is that just part of the Kerberos authentication process? ~Cordell