So is that a bind type not mentioned in the chart he referenced for ldp.exe? <https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc771022(v=ws.11)#understanding-bind-options-for-ldap-authentication>Understanding bind options for LDAP authentication There are several authentication methods available in ldp that allow a client to bind to an LDAP server. The best method depends on several factors. Method Description Simple Cleartext password. Try not to use this, as it is not secure. MSN MSN (Microsoft Network) authentication. This package brings up a dialog box to prompt the user for MSN credentials. DPA Normandy authentication, new MSN authentication. Same usage as MSN. NTLM Windows NT domain authentication. Use NULL credentials and attempt to use default logged-in user credentials. Sicily Negotiate with the server for any of: MSN, DPA, NTLM. Should be used for LDAPv2 servers only. Negotiate Use GSSAPI Negotiate package to negotiate security package of either Kerberos V5 or NTLM (or any other package the client and server negotiate). Pass in NULL credentials to specify default logged-in user. If Negotiate package is not installed on server or client, this will fall back to Sicily negotiation. On Fri, Oct 30, 2020 at 1:57 PM Andrew Bartlett via samba < samba at lists.samba.org> wrote:> On Fri, 2020-10-30 at 13:53 +0000, Zebrose, Cordell via samba wrote: > > > 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? > > Not currently, and certainly not for the domain join. > > Once joined, for subsequent user authentication we would like to > improve that. Samba could and should in the future use FAST, a secure > tunnel for Kerberos (compound authentication) where user authentication > from the Samba server (think pam_winbind etc) is wrapped by the machine > account, but the machine account will always be cleartext in the AS- > REQ. > > Again, none of this really matters if you are not starting user > authentication on the newly joined host (as opposed to accepting > tickets), but to complete the story: > > Currently a big main blocker to adding FAST to Winbindd (and so > pam_winbind) is the Samba's AD DC doesn't support that, which in turn > means we can't test it. Many of us would love to get our internal > Heimdal upgraded (and once that is done I have patches for the server > side), but it is a big task. > > I hope this helps, > > 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 > > > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
On Fri, 2020-10-30 at 14:10 -0500, Rob Townley wrote:> So is that a bind type not mentioned in the chart he referenced for > ldp.exe?Kerberos authentication is mentioned as:> Understanding bind options for LDAP authentication > There are several authentication methods available in ldp that allow > a client to bind to an LDAP server. The best method depends on > several factors. >> Use GSSAPI Negotiate package to negotiate security package of either > Kerberos V5 or NTLM (or any other package the client and server > negotiate). Pass in NULL credentials to specify default logged-in > user. If Negotiate package is not installed on server or client, this > will fall back to Sicily negotiation.This is what we use in Samba, Kerberos with a fallback to NTLMv2. Andrew Bartlett> On Fri, Oct 30, 2020 at 1:57 PM Andrew Bartlett via samba < > samba at lists.samba.org> wrote: > > On Fri, 2020-10-30 at 13:53 +0000, Zebrose, Cordell via samba > > wrote: > > > > 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? > > > > Not currently, and certainly not for the domain join. > > > > Once joined, for subsequent user authentication we would like to > > improve that. Samba could and should in the future use FAST, a > > secure > > tunnel for Kerberos (compound authentication) where user > > authentication > > from the Samba server (think pam_winbind etc) is wrapped by the > > machine > > account, but the machine account will always be cleartext in the > > AS- > > REQ. > > > > Again, none of this really matters if you are not starting user > > authentication on the newly joined host (as opposed to accepting > > tickets), but to complete the story: > > > > Currently a big main blocker to adding FAST to Winbindd (and so > > pam_winbind) is the Samba's AD DC doesn't support that, which in > > turn > > means we can't test it. Many of us would love to get our internal > > Heimdal upgraded (and once that is done I have patches for the > > server > > side), but it is a big task. > > > > I hope this helps, > > > > 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 > > > > > > > >-- Andrew Bartlett https://samba.org/~abartlet/ Authentication Developer, Samba Team https://samba.org Samba Developer, Catalyst IT https://catalyst.net.nz/services/samba
Thanks Andrew, that will help for security reviews. On Fri, Oct 30, 2020 at 2:14 PM Andrew Bartlett <abartlet at samba.org> wrote:> > On Fri, 2020-10-30 at 14:10 -0500, Rob Townley wrote: > > So is that a bind type not mentioned in the chart he referenced for > > ldp.exe? > > Kerberos authentication is mentioned as: > > > Understanding bind options for LDAP authentication > > There are several authentication methods available in ldp that allow > > a client to bind to an LDAP server. The best method depends on > > several factors. > > > > > Use GSSAPI Negotiate package to negotiate security package of either > > Kerberos V5 or NTLM (or any other package the client and server > > negotiate). Pass in NULL credentials to specify default logged-in > > user. If Negotiate package is not installed on server or client, this > > will fall back to Sicily negotiation. > > This is what we use in Samba, Kerberos with a fallback to NTLMv2. > > Andrew Bartlett > > > On Fri, Oct 30, 2020 at 1:57 PM Andrew Bartlett via samba < > > samba at lists.samba.org> wrote: > > > On Fri, 2020-10-30 at 13:53 +0000, Zebrose, Cordell via samba > > > wrote: > > > > > 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? > > > > > > Not currently, and certainly not for the domain join. > > > > > > Once joined, for subsequent user authentication we would like to > > > improve that. Samba could and should in the future use FAST, a > > > secure > > > tunnel for Kerberos (compound authentication) where user > > > authentication > > > from the Samba server (think pam_winbind etc) is wrapped by the > > > machine > > > account, but the machine account will always be cleartext in the > > > AS- > > > REQ. > > > > > > Again, none of this really matters if you are not starting user > > > authentication on the newly joined host (as opposed to accepting > > > tickets), but to complete the story: > > > > > > Currently a big main blocker to adding FAST to Winbindd (and so > > > pam_winbind) is the Samba's AD DC doesn't support that, which in > > > turn > > > means we can't test it. Many of us would love to get our internal > > > Heimdal upgraded (and once that is done I have patches for the > > > server > > > side), but it is a big task. > > > > > > I hope this helps, > > > > > > 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 > > > > > > > > > > > > > -- > Andrew Bartlett https://samba.org/~abartlet/ > Authentication Developer, Samba Team https://samba.org > Samba Developer, Catalyst IT > https://catalyst.net.nz/services/samba > > > >