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
Created attachment 18780 [details] samba-ad pcap