Bug 15956 - Samba-AD does not properly refuse connection when a LDAP client request Sicily auth mechanism
Summary: Samba-AD does not properly refuse connection when a LDAP client request Sicil...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.23.3
Hardware: All All
: P5 critical (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-11-20 14:15 UTC by Denis Cardon
Modified: 2025-11-24 21:37 UTC (History)
4 users (show)

See Also:


Attachments
pcap on msad server (1.47 KB, application/vnd.tcpdump.pcap)
2025-11-20 14:15 UTC, Denis Cardon
no flags Details
samba-ad pcap (120 bytes, application/vnd.tcpdump.pcap)
2025-11-20 14:16 UTC, Denis Cardon
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Denis Cardon 2025-11-20 14:15:37 UTC
Created attachment 18779 [details]
pcap on msad server

Hello everyone,

this bug report follows two of my posts on the mailing list [1] [2]. FortiEMS VPN appliance seems to have badly implemented their LDAP client auth and is trying to do a Sicily [3] type auth mechanism against the Domain Controller. In their documentation they seems to call this NTLMSSP auth, but it is not SASL based. As usually they say it is a Samba issue, while I would argue that using a old decrepit auth mech is an issue per se, but well, behaving differently than a MS-AD is an easy WONTFIX answer for many vendors.

Sicily [3][4] is an old Microsoft proprietary auth mechanism which is an alternative to SASL that is now considered insecure and shouldn't be used (by Microsoft own words).

When asked for a Sicily mech base authentication, an MS-AD will starts negotiation and then send a "stronger auth mech required to the client". There is a NTLM challenge and response that goes by in clear if the connection is not over TLS (cf. the pcap trace).

On a Samba-AD, when receiving a Sicily auth mech negotiation, the connection is dropped straight away by the Samba Server, and we see a LDAP_PROTOCOL_ERROR in the samba log. Which is understandable since the Samba server does not implement it.

I've attache pcap trace prepared by my collegue Thomas. In the MS-AD network trace we can see the negotiation, in the samba-AD network trace, the connection is dropped straight away by the Samba Server, and we see a LDAP_PROTOCOL_ERROR in the samba log.

Thomas took a quick look at the code base and the issue probably rely in the ldap_decode function in ldap_message.c [5], the function expect to have a  ASN1_CONTEXT_SIMPLE(0) or ASN1_CONTEXT(3), but with Sicily we get a ASN1_CONTEXT_SIMPLE(9), or ASN1_CONTEXT_SIMPLE(10)

I definitely think it would be a bad idea to fully implement this deprecated old auth mech, but it would be good for Samba to properly answer to such request so we don't have this kind of issues like with FortiEMS. 

Would a direct "Stronger auth required" sent directly after the first packet could be an option?

Cheers,

Denis

It is easy to reproduce the issue with this small Python script (you need to first install ldap3 pip package):

from ldap3 import Server, Connection, ALL, NTLM, SIMPLE
server = Server('127.0.0.1', get_info=ALL)
username="SAMBAAD.LAN\\toto"
password="xxxx"
conn = Connection(server, user=username, password=password, authentication=NTLM, auto_bind=True)
conn.extend.standard.who_am_i()


[1] https://lists.samba.org/archive/samba/2025-October/252262.html
[2] https://lists.samba.org/archive/samba/2025-November/252311.html
[3] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e7d814a5-4cb5-4b0d-b408-09d79988b550
[4] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/8b9dbfb2-5b6a-497a-a533-7e709cb9a982
[5] https://github.com/samba-team/samba/blob/master/libcli/ldap/ldap_message.c#L1191
Comment 1 Denis Cardon 2025-11-20 14:16:12 UTC
Created attachment 18780 [details]
samba-ad pcap