[Samba] 'LDAP_PROTOCOL_ERROR' when NTLMSSP_NEGOTIATE bind request

[Denis CARDON]

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