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. 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.. > 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. > 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. 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.. What you needs to decide upon is if the winbind interface should use NTLMSSP exchanges, or just LM/NTLM/NTLMv2 challenge+response exchanges. 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. 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. 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.
