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: 2026-01-13 21:44 UTC (History)
5 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
Comment 2 Ralph Böhme 2026-01-12 08:28:28 UTC
Iirc someone has patches for this somewhere. Volker?
Comment 3 Volker Lendecke 2026-01-12 08:42:01 UTC
(In reply to Ralph Böhme from comment #2)
> Iirc someone has patches for this somewhere. Volker?

Yep. I'm waiting for Tranquil to send me updates whether my patches help for their customer :-)
Comment 4 Denis Cardon 2026-01-12 08:55:24 UTC
Hi Ralph, Volker,

sorry for not coming back earlier on this one. The end of the year was quite busy. 

The patch of Volker sends back the proper message, but it is not enough to make FortiEMS happy. It looks like we have to implement the whole handshake before returning a "StrongAuthRequired" otherwise the FortiEMS fails anyway.

In the mean time it seems that Fortinet realized that they did something wrong and provided the option to enforce the usage of SASL/GSSAPI auth rather than Sicily. The current fix is available on the latest 7.4 series (in the current fix one cannot set a preferred DC, so it must be hardcoded in /etc/hosts to target the right one, but it works).

So the issue for FortiEMS is mostly "fixed". But we might see this issue again on other products, so having the patch from Volker would at least tell people that Sicily is not implemented and should not be used. 

Is there a web page on the wiki where we can list what part of MS-AD is not implemented in Samba-AD, saying if it is planned, or if it will never be implemented (like Sicily)?

Cheers,

Denis
Comment 5 Volker Lendecke 2026-01-12 10:31:43 UTC
I wouldn't say sicily will never be implemented. It should be a matter of at most a few days to implement the full protocol exchange. From what I saw when looking at it we should have all the difficult pieces available via gensec, it's "just" a matter of properly plumbing them into the LDAP server. Famous last words: How hard can it be? :-)