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

On Fri, 24 Oct 2025 06:35:14 +0000
Nicolas Martinussen <nicolas.martinussen at joskin.com> wrote:
> > > This appears to be searching in 'secrets.ldb' and
failing, any
> > > idea what the search command is ?
> > > From what I see in the packet capture I have done, it doesn't
look
> > > like it's searching anything at that moment.
> > 
> > Something must be starting off the process, it is that command I was
> > referring to.
> >
> Oh sorry, hadn't understood that. It's in a webui, but there
isn't a
> lot to configure... On the previous version of FortiEMS, there were
> more things to configure, but it seems they have removed the other
> options (and won't add it back as it works with Windows AD, I've
> already tried opening a ticket). I'm using LDAP (not S) just to have
> clear traffic in the capture, but when I try with LDAPS, I still have
> the same error and the same log. Here is a picture from the UI:
> https://imgur.com/a/LsFwGG2
Sorry, but I cannot see that, I am in the UK
> >
> Yes, it's a very expensive old machine tool... This machine already
> connect to another Samba server (only for the factory) which has one
> way copy that runs every minute from the user Samba server. But it
> strangely cannot take an IP for the server and need a netbios name
> from a WINS server, so that's why I have the WINS enabled on the user
> Samba. But I should maybe put that WINS on the factory Samba too.
I personally have never had to deal with this, but it is usually dealt
with in one of two ways. You either 'air-gap' the machine and take data
to it on USB drives, or you use an intermediate Linux machine that can
talk to the tool in SMBv1 and listen to to the rest of the domain in
SMBv2/3. That intermediate machine is the only one that knows SMBv1.
> Just to be sure, I also just tried removing the lines for SMBv1 to do
> a quick testing, but sadly, I still have the exact same issue...
> 
Samba is supposed to work like Windows, so it should work, but without
knowing just how your FortiEMS device is 'talking' to AD, then it is
hard to know how to fix it.
You also haven't said what version of Samba you are using, but it must
be above 4.20.0 . You could try using the latest version of Samba.

After that, as this is in production, I would suggest you contact an
outside support agency, see here:

https://www.samba.org/samba/support/globalsupport.html

Rowland

> > > > This appears to be searching in 'secrets.ldb' and
failing, any
> > > > idea what the search command is ?
> > > > From what I see in the packet capture I have done, it
doesn't look
> > > > like it's searching anything at that moment.
> > >
> > > Something must be starting off the process, it is that command I
was
> > > referring to.
> > >
> > Oh sorry, hadn't understood that. It's in a webui, but there
isn't a
> > lot to configure... On the previous version of FortiEMS, there were
> > more things to configure, but it seems they have removed the other
> > options (and won't add it back as it works with Windows AD,
I've
> > already tried opening a ticket). I'm using LDAP (not S) just to
have
> > clear traffic in the capture, but when I try with LDAPS, I still have
> > the same error and the same log. Here is a picture from the UI:
> > https://imgur.com/a/LsFwGG2
> 
> Sorry, but I cannot see that, I am in the UK
>
Here is on another site, I hope this one isn't blocked in the UK:
https://ibb.co/q2ZPfvm
> 
> > >
> > Yes, it's a very expensive old machine tool... This machine
already
> > connect to another Samba server (only for the factory) which has one
> > way copy that runs every minute from the user Samba server. But it
> > strangely cannot take an IP for the server and need a netbios name
> > from a WINS server, so that's why I have the WINS enabled on the
user
> > Samba. But I should maybe put that WINS on the factory Samba too.
> 
> I personally have never had to deal with this, but it is usually dealt
> with in one of two ways. You either 'air-gap' the machine and take
data
> to it on USB drives, or you use an intermediate Linux machine that can
> talk to the tool in SMBv1 and listen to to the rest of the domain in
> SMBv2/3. That intermediate machine is the only one that knows SMBv1.
>
The second option is what I planned to do, but I still haven't been able to
do it.
> 
> > Just to be sure, I also just tried removing the lines for SMBv1 to do
> > a quick testing, but sadly, I still have the exact same issue...
> >
> 
> Samba is supposed to work like Windows, so it should work, but without
> knowing just how your FortiEMS device is 'talking' to AD, then it
is
> hard to know how to fix it.
> You also haven't said what version of Samba you are using, but it must
> be above 4.20.0 . You could try using the latest version of Samba.
>
That's right, I forgot to tell about the version, I'm currently using
Samba 4.23.0, but this issue was already present on 4.22.x.
> 
> After that, as this is in production, I would suggest you contact an
> outside support agency, see here:
> 
> https://www.samba.org/samba/support/globalsupport.html
> 
> Rowland
Nicolas