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

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

Hi Nicolas,
>> 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.
>> ...
>> 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.
|After some more digging here and comparing MS-AD and Samba-AD wire 
trace, here is what we found up to now : |
||
|* the issue is due to the client trying to do NTLM / Sicily 
authentication mechanism (Sicily [1] is a old and insecure auth protocol 
that is not accepted by MS-AD either). Sicily is not SASL based [2].|
||
|* Samba does not implement Sicily AT ALL, so it drops the connection 
when the initial packet is coming to the server because it is 
"malformed" (since Samba has no knowledge of this auth mech)|
||
|* MS-AD, on receiving a Sicily auth packet will start negotiating and 
then send a StrongerAuthRequired to the client (like I said above MS-AD 
is not accepting Sicily anymore, but is know about the protocol and 
properly answer to a client asking for it)|
||
|* I guess that FortiEMS once receiving StrongerAuthRequired answer then 
use SASL for authentication.|
||
|So in order for Samba to support this kind of corner case, there is 
some code to write just to be able to tell the client to use a better 
auth mechanism. Python ldap3 supports Sicily auth mech, so it is easy to 
make a test case that work on Linux.|
||
|We'll open a Bugzilla entry shortly with wire trace and the initial 
debug we have made here. But it is very strange for Fortinet to use this 
auth mechanism, so there may be some other stuff that trigger this 
behavior... |
||
|Cheers,|
||
|Yohann?s, Thomas and Denis|
||
|[1] 
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/8b9dbfb2-5b6a-497a-a533-7e709cb9a982|
||
|[2] 
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e7d814a5-4cb5-4b0d-b408-09d79988b550|
||
||
||
>
> 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
>