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

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
>

Hello Denis and the Tranquil IT team,

Thanks for your research !
Since your last message I sadly hadn't time (and probably knowledge too) to
do more digging.
I think you have correctly identified the issue. Let's now hope there will
be an (easy ?) fix !

Nicolas
> Hi Nicolas,
> 
> 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