samba - Oct 2025 - 'LDAP_PROTOCOL_ERROR' when NTLMSSP_NEGOTIATE bind request

I've found a way to reproduce the issue I have with a small C# code executed
on Windows. It gets me almost the same packets when I do a capture, I also get
the 'LDAP_PROTOCOL_ERROR' in the Samba logs, and when I try it against a
Windows DC, it works.

Here is the code:

using System.DirectoryServices.Protocols;
using System.Net;

class Program
{
    static void Main()
    {
        string ldapServer = "dc-01.ad.mydomain.com";
        
        LdapConnection ldap = new LdapConnection(ldapServer);
        ldap.AuthType = AuthType.Ntlm;
        ldap.Credential = new NetworkCredential("ldap",
"PASSWORD", "MYDOMAIN");

        ldap.Bind();
    }
}

It seems like AuthType.Ntlm isn't supported by the Samba code. When I try
the same code with AuthType.Basic, in that case, it works (I get the
"Strong authentication is required for this operation.", but
that's normal as I use LDAP and not LDAPS).
> I wonder if this could be an authentication problem ?
> If I run this ldapsearch on a Unix domain member against one of my DCs:
> 
> ldapsearch -x -H ldap://dc03.samdom.example.com -D
> CN=rowland,CN=Users,dc=samdom,dc=example,dc=com -w xxxxxxxxxxx -b
> 'dc=samdom,dc=example,dc=com' -s sub
> 
> I get this:
> 
> ldap_bind: Strong(er) authentication required (8)
> ??????? additional info: BindSimple: Transport encryption required.
> 
> If I go to the DC and add this to its smb.conf:
> 
> ldap server require strong auth = no
I've also tried that but it still sadly doesn't work...
> Then restart it, if I then rerun the ldapsearch on the Unix domain
> member, I get the entire AD domain dumped.
> 
> After that, I am lost :-)
> 
> Rowland
Nicolas

On Fri, 24 Oct 2025 11:44:49 +0000
Nicolas Martinussen <nicolas.martinussen at joskin.com> wrote:
> I've found a way to reproduce the issue I have with a small C# code
> executed on Windows. It gets me almost the same packets when I do a
> capture, I also get the 'LDAP_PROTOCOL_ERROR' in the Samba logs,
and
> when I try it against a Windows DC, it works.
> 
> Here is the code:
> 
> using System.DirectoryServices.Protocols;
> using System.Net;
> 
> class Program
> {
>     static void Main()
>     {
>         string ldapServer = "dc-01.ad.mydomain.com";
>         
>         LdapConnection ldap = new LdapConnection(ldapServer);
>         ldap.AuthType = AuthType.Ntlm;
>         ldap.Credential = new NetworkCredential("ldap",
"PASSWORD",
> "MYDOMAIN");
> 
>         ldap.Bind();
>     }
> }
> 
> It seems like AuthType.Ntlm isn't supported by the Samba code. When I
> try the same code with AuthType.Basic, in that case, it works (I get
> the "Strong authentication is required for this operation.", but
> that's normal as I use LDAP and not LDAPS).
> 
I am also fairly certain it is supported, but I am also running out of
ideas. My last idea is, you are using 'ldap at ad.mydomain.com' for the
username, what if it expects the samaccountname ? try it with just
'ldap' (which I presume is an AD username).

Rowland

Hi Nicolas,

Le 24/10/2025 ? 13:44, Nicolas Martinussen via samba a
?crit?:
> I've found a way to reproduce the issue I have with a small C# code
executed on Windows. It gets me almost the same packets when I do a capture, I
also get the 'LDAP_PROTOCOL_ERROR' in the Samba logs, and when I try it
against a Windows DC, it works.
>
> Here is the code:
>
> using System.DirectoryServices.Protocols;
> using System.Net;
>
> class Program
> {
>      static void Main()
>      {
>          string ldapServer = "dc-01.ad.mydomain.com";
>          
>          LdapConnection ldap = new LdapConnection(ldapServer);
>          ldap.AuthType = AuthType.Ntlm;
>          ldap.Credential = new NetworkCredential("ldap",
"PASSWORD", "MYDOMAIN");
>
>          ldap.Bind();
>      }
> }
>
> It seems like AuthType.Ntlm isn't supported by the Samba code. When I
try the same code with AuthType.Basic, in that case, it works (I get the
"Strong authentication is required for this operation.", but
that's normal as I use LDAP and not LDAPS).
in the RootDSE, it seems like Samba is advertising NTLM as a 
supportedSASLMechanisms, while I think it shouldn't be there. I think it 
should use GSSAPI as an extra layer below.

* on a win2k16 (forestLevelFunctionality=7) the supportedSASLMechanisms 
list is : GSSAPI, GSS-SPNEGO, EXTERNAL, DIGEST-MD5

* on a Samba 4.22 (don't have a 4.23 handy) 
(forestLevelFunctionality=7), the supportedSASLMechanism list is : 
GSSAPI, GSS-SPNEGO, NTLM

It seems that the non-GSSAPI-encapsulated-NTLM auth mechanism on an AD 
is not SASL based (even if the attribute is called 
supportedSASLMechanism), but based on a mechanism called Sicily [1][2], 
which may explain why the connexion dropped just after if Sicily is not 
implemented in Samba.

By the way we have seen the exact same issue at a client yesterday like 
you on a FortiEMS. However we won't have much time to investigate this 
issue before early next week.

Thanks for the debugging.

Cheers,

Denis

PS : there are many other differences in the RootDSE entry 
(supportedControl list, SupportedLDAPPolicies list, etc.). Something to 
investigate later :-)

[1] 
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e7d814a5-4cb5-4b0d-b408-09d79988b550

[2] 
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/8b9dbfb2-5b6a-497a-a533-7e709cb9a982

>
>> I wonder if this could be an authentication problem ?
>> If I run this ldapsearch on a Unix domain member against one of my DCs:
>>
>> ldapsearch -x -H ldap://dc03.samdom.example.com -D
>> CN=rowland,CN=Users,dc=samdom,dc=example,dc=com -w xxxxxxxxxxx -b
>> 'dc=samdom,dc=example,dc=com' -s sub
>>
>> I get this:
>>
>> ldap_bind: Strong(er) authentication required (8)
>>  ??????? additional info: BindSimple: Transport encryption required.
>>
>> If I go to the DC and add this to its smb.conf:
>>
>> ldap server require strong auth = no
> I've also tried that but it still sadly doesn't work...
>
>> Then restart it, if I then rerun the ldapsearch on the Unix domain
>> member, I get the entire AD domain dumped.
>>
>> After that, I am lost :-)
>>
>> Rowland
> Nicolas