Re: Stablising the winbind interface for squid's NTLM code

Henrik Nordstrom wrote:
>
> Andrew Bartlett wrote:
>
> > Being a seperate execuable, licencing issues are overcome (not an issue
> > for squid, but we
> > can now allow the same thing for apache). I hope that we can also use
> > the same NTLMSSP implementation inside Samba - which should ensure its
> > maintainence into the future.
>
> The Squid ntlm helper protocol is effectively raw NTLMSSP exchanges plus
> a status code telling the type of NTLMSSP message.

Which is exactly why I'm interested in using it, it looks like a
reasonably well-designed interface that other applicateions can work
with sanely.

> Any interface using NTLMSSP would be fine for us, preferably in a manner
> that releases the application from having to understand anything about
> NTLMSSP formats. Today the Squid ntlm authentication core needs to
> understand a bit of NTLMSSP to extract the username which is a pain as
> there is many possible username formats, and may be problems for non-GPL
> licensing..

I see no reason why the helper can't return this as part of its status
respose.

> > Conceptually, it would be a simple code import from squid's current
> > helper's directory. In practice, a lot of the code will need to be
> > reoganised and rewritten (simply due to differences between the
> > projects). In particular, I would like to leverage tridge's RPC
> > encoder/decoder, and try to get a relitivly simple code-path going.
>
> I don't think there is much in Squid's helper directory to pick up,
> except for some far from complete NTLMSSP decoding/encoding routines.

Hence why I intend to pick it up in concept, not in implementation ;-)

> > One change I would make: Allow one helper to issue a challange, and
> > another to pick it up. This could be done by sending the second helper
> > the challange packet, with a tag to say 'pretend you sent this'.
>
> Be careful to not block implementation of NTLMv2 NTLMSSP in such
> approach.

I'll need to see how NTLMv2 works, but knowing how the NT backends do
it, I don't expect a problem.

> We do not need such statelessness in Squid as we already have the code
> to track which helper issued the challenge, needed for other backends.
> And for things like Apache 1.X such interface would be overly complex I
> think..

Granted, this extension might not prove that useful.

> What you needs to decide upon is if the winbind interface should use
> NTLMSSP exchanges, or just LM/NTLM/NTLMv2 challenge+response exchanges.

The winbindd interface will match the NETLOGON interface provided by NT.

The job of the helper is (as in squid) to provide NTLMSSP to the client
app, and through that to the client.

> If it is decided that winbind is to use a basic LM/NTLM/NTLMv2
> challenge+response interface, then it needs to be decided upon how
> NTLMSSP is to be provided
>
> a) Not at all, having each application implement what they need
> b) Separate "reference" implementation
> c) Shared or link library shipped with Samba (static/dynamic linkage
> to not bother us)
> d) Separate daemon acting as a NTLMSSP frontend to winbind.

This is why the app is to provide the NTLMSSP, and why I think samba
should (with assistance) maintin and ship it. It is not intended to be
a 'reference' but the official winbind interface for NTLMSSP packets.

Samba cannot really provide shared library interfaces on all the
platforms it supports, and a seperate deamon makes no sense (same
issues, no extra benifit).

> What I think I would like to see is winbind to start with a simple
> interface for verifying LM/NTLM/NTLMv2 response packets, optionally
> including the MD4(NT#) for use by MS CHAPv2. Access to this interface
> should be restricted to local pipes only. It is probably ok if different
> interfaces is used for each of LM / NTLM / NTLMv2. The application
> really should only care about the strongest provided so I don't see the
> need of being able to verify a combined LM + NTLM reponse.

Writing such an app, or (more likaly) including it as a 'mode' in the
new NTLMSSP helper does not pose any particular problems as far as I can
see.

> Then let a NTLMSSP implementation evolve ontop of this, starting out as
> a reference implementation but with the ultimate goal of becoming a
> official winbind interface, either directly in the winbind daemon, or as
> a separate daemon, having a interface along the lines of MS SSP when
> using the LM/NTLM SSP.

I'm not talking about yet another deamon here. I'm talking about a
command line/input driven execurable that can link to samba's knowlege
of NTLMSSP in order to provide that to clients. It will (if adopted) be
an offical winbind interface, and talk over the winbind socket.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet@pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet@samba.org
Student Network Administrator, Hawker College   abartlet@hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net