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

> > 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
> 
> >
> > Why 'WINS' ? Your clients should be using DNS, not NetBIOS.
> > It's due to an old machine that really needs WINS (an old Windows
NT
> > Embedded). I would really like to disable that, but I sadly can't
> 
> Are we talking about something like a very expensive machine tool ? If
> so, you would probably be better off setting up an intermediate Samba
> server that can talk to the tool in SMB1, but can only listen to the
> rest of the domain in SMBv2/3.
>
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.
> 
> >
> > >
> > >???????? # TLS
> > >???????? tls enabled? = yes
> > >???????? tls keyfile? = tls/dc-01.2023.key
> > >???????? tls certfile = tls/dc-01.2023.crt
> > >???????? tls cafile?? = tls/CA/MYDOMAIN.2023.crt
> > >???????? # TLS
> > >
> > >???????? ntlm auth = ntlmv1-permitted
> > >???????? lanman auth = yes
> > >???????? client lanman auth = yes
> > >???????? server min protocol = NT1
> > >???????? client min protocol = NT1
> >
> > Why are you using SMBv1 ?
> > It's also some configuration that I need to disable, but a
production
> > machine is still using SMBv1. As soon as this machine is migrated to
> > another SMB server (for old machines), I'll remove those 5 config
> > lines
> 
> All that SMBv1 stuff may be your problem.
> 
> Rowland
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...

Nicolas

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